MY WORDS FOR TYPES OF BUG REPORTING TOOLS

1. Types Of Test Management tools

1. TET (Test Environment Toolkit)
2. TET ware
3. Test Manager 
4. RTH - Requirements and Testing Hub
5. HP Quality Center/ALM
6. QA Complete
7. T-Plan Professional
8. Automated Test Designer (ATD)
9. Testuff
10. SMARTS
11. QAS.TCS (Test Case Studio)
12. PractiTest
13. Test Manager Adaptors
14. SpiraTest
15. TestLog
16. ApTest Manager
17. DevTest 

2. Types Of Functional Testing Tools

1. Selenium
2. Soapui
3. Watir
4. HTTP::Recorder
5. WatiN
6. Canoo WebTest
7. Webcorder
8. Solex
9. Imprimatur
10. SAMIE
11. Swete
12. ITP
13. WET
14. WebInject
15. QuickTest Pro
16. Rational Robot
17. Sahi
18. SoapTest
19. Badboy
20. Test Complete
21. QA Wizard
22. Netvantage Functional Tester
23. PesterCat
24. AppsWatch
25. Squish
26. actiWATE
27. liSA
28. vTest
29. Internet Macros
30. Ranorex

3. Types Of  Load Testing Tools

1. J-meter
2. FunkLoad
3. HP LoadRunner
4. LoadStorm
5. NeoLoad
6. Loadtracer
7. WebLOAD Professional
8. Forecast
9. ANTS – Advanced .NET Testing System
10. vPerformer
11. Webserver Stress Tool
12. preVue-ASCII
13. Load Impact

MY WORDS FOR ISSUE TRACKING AND BUG REPORTING TOOLS

Big IT projects needs a bug tracker ( issue tracker, or defect tracker) Tools.

For reporting BUG  we need a bug tracker Tools for a software development and testing projects. But, about a admin team, database team, network analysis team? They all want some help to track their work documents, fixes, and issues of their applications system, database and network. In the Software Development Life Cycle tracking bug is the most important step and without this step software cannot be complete.But choosing a correct bug tracking system which suits your needs is not a simple deal. But here I am trying to make it easy for you, in this article I am presenting a 10 free and open source Bug Tracking Tools with full list features & where to get this bugtracker tool for a better development process. It is a big time-saver to add & manage bugs is in the Bug Tracking system. Few of the bug tracker are not only tracking the bug but also the managing full software based project & can be used for many other tasks.

1. BUGZILLA - BUG TRACKER

Bugzill’s is web-based project management software that is being published as Open source software. Bugzill’s is used to manage software development and help you get a handle on the software development process. Bugzill’s can Successful projects often are the result of successful organization and communication. Bugzill’s is powerful & commanding tool that will allow your team to get organized and communicate effectively. It is allow tracking the bugs & code changes efficiently. This is developed by the Mozilla foundation. This Bug Tracking Tool is used many of top rated organizations like Mozilla, Facebook, NASA, Open Office, RedHat etc. Bugzill’s is written in Perl, and works on various databases including MySQL and Oracle. This is used by various big open source projects to track their bugs. For example, Linux kernel development team, Apache development team, GNOME development team uses Bugzill’s. Red Hat also uses Bugzill’s to track the issues found in Red Hat Distribution system. Benefits of Bugzill’s: Help to increase product quality, get better communication with team members, Using Bugzill’s helps to improve customer satisfaction, Bugzill’s can increase the productivity of software development process. Are you looking for a stable, actively maintained, widely adapted bug tracking system? Look no further. Bugzill’s is for you.

2. MANTIS - BUG TRACKER

Mantis’s issue tracking system is written in PHP, and works on various databases including MySQL, MS SQL, PostgreSQL. Mantis’s’’s Bug Tracker is a open source web-based Bug Tracking System. It is written in PHP and works with multiple databases like MS SQL, MySQL, and PostgreSQL. Mantis’s has multiple items & dived into multi-level hierarchy as follows:
Projects -> Sub Projects -> Categories -> Bugs
Source code integration,Time tracking, Issue relationship graph,Custom fields and workflow ,Anonymous access
Based on user and Client User access & permission rights user can contribute to each item. Mantis’s is powerful tool integrated with few applications like time tracking, chat, wiki, RSS feeds & many more.

3. TRAC - BUG TRACKER

Trac’s is written in Python. Trac’s system is developed by Edgewall Software. It supports multiple platforms like Linux, Unix, Mac OS X, Windows. Apart from issue Trac’sking, it also provides wiki, and integration to subversion. The web interface is very simplistic and easy to use. This also provides project management features including roadmap and milestone Trac’sking. The Trac’s is web based, open source software. Trac’s allows wiki markup as issue descriptions and commit messages, creating links and seamless references between bugs, tasks, changesets, files and wiki pages. Trac’s is the superior version of wiki & use as the issue Trac’sking system for software development projects. A timeline shows all current and past project events in order, making the acquisition of an overview of the project and defect Trac’sking software progress very easy. The roadmap shows the road ahead, listing the upcoming milestones.

4. REDMINE - BUG TRACKER

Redmine’s is written in Ruby on Rails. Redmine’s is a web based most commonly used project management tool. The Redmine’s is written in Ruby on Rails. Apart from tracking issues, it provides a full project management features. It supports multiple platforms with multiple databases. The feature of Gantt charts and calendar helps to supports the illustration of projects and their deadlines. In this issue tracking system you can create Task & subtask which helps to categorize the issues in the project management.Project management including Gantt chart, Project Wiki , Time Tracking, Authentication.

MY WORDS FOR DIFFERENCE BETWEEN BLACK, WHITE AND GRAY BOX TESTING

Black Box Testing (MANUAL TESTING)

The Code Access not required. Clearly separates user's perspective from the developer's perspective through visibly defined roles. The technique of testing without having any knowledge of the interior workings of the application is Black Box testing. Large numbers of moderately skilled testers can test the application with no knowledge of implementation, programming language or operating systems.Limited Coverage since only a selected number of test scenarios are actually performed. The tester is oblivious to the system architecture and does not have access to the source code. Blind Coverage, since the tester cannot target specific code segments or error prone areas. Typically, when performing a black box test, a tester will interact with the system's user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.Well suited and efficient for large code segments.The test cases are difficult to design. Inefficient testing, due to the fact that the tester only has limited knowledge about an application. 

White Box Testing (AUTOMATION TESTING)

It helps in optimizing the code and database. White box testing  techniques is the detailed investigation of internal logic and structure of the code. White box testing is also called glass testing or open box testing. White Box (or glass box) testing is the process of giving i/p to the system and checking how the system processes i/p to generate o/p. The tester needs to have a look inside the source code and find out which unit/chunk of the code is behaving inappropriately. Extra lines of code can be removed which can bring in hidden defects. Due to the tester's knowledge about the code, maximum coverage is attained during test scenario writing.Sometimes it is impossible to look into every nook and corner to find out hidden errors that may create problems as many paths will go untested. It is difficult to maintain white box testing as the use of specialized tools like code analyzers and debugging tools are required. Due to the fact that a skilled tester is needed to perform white box testing, the costs are increased. In order to perform white box testing on an application, the tester needs to possess knowledge of the internal working of the code.As the tester has knowledge of the source code, it becomes very easy to find out which type of data can help in testing the application effectively. 

Grey Box Testing (COMBINATION)

Grey box testers don't rely on the source code; instead they rely on interface definition and functional specifications. Grey Box testing is a technique to test the application with limited knowledge of the internal workings of an application. In software testing, the term the more you know the better carries a lot of weight when testing an application. Gray Box testing is a combination of White Box and Glass Box Testing. Testing every possible input stream is unrealistic because it would take an unreasonable amount of time; therefore, many program paths will go untested. In this, the tester has little knowledge about the internal working of the s/w; so he tests the o/p as well as process carried out to generate the o/p. There is one more type of testing called gray box testing. In this we look into the “box” being tested just long enough to understand how it has been implemented. Then we close up the box and use our knowledge to choose more effective black box tests. The test is done from the point of view of the user and not the designer.Since the access to source code is not available, the ability to go over the code and test coverage is limited. 

Mastering the domain of a system always gives the tester an edge over someone with limited domain knowledge. Based on the limited information available, a grey box tester can design excellent test scenarios especially around communication protocols and data type handling. Unlike black box testing, where the tester only tests the application's user interface, in grey box testing, the tester has access to design documents and the database. Having this knowledge, the tester is able to better prepare test data and test scenarios when making the test plan.Offers combined benefits of black box and white box testing wherever possible. The tests can be redundant if the software designer has already run a test case.

MY WORDS FOR AUTOMATION (WHITE BOX) TESTING

AUTOMATION (WHITE BOX) TESTING

For AUTOMATION (WHITE BOX) TESTING there is no right tool, there is no tool that does everything And there is no perfect tool. Manual testing is performed as a human sitting in front of a Systems carefully executing the testing steps. Which is why having a team behind you that knows the tools market inside out is essential. Automation Testing means using an automation (white box) testing tool to execute your test case suite. The automation (white box) testing software can also enter test data into the System Under Test , compare  expected and actual  results and generate detailed test  reports. Manual and automation (white box) testing methods go hand-in hand for successful testing. What we have to automate, when we have to automate, or even whether one really what the exact need of automation are crucial decisions which the testing (or development) team must make. Selecting the correct features of the product for automation largely determines the success of the automation. Automation (white box) testing unstable features or features that are undergoing changes should be avoided. Before mentioning the tools lets identify the process which can be used to automate the testing. Tools serve as a driving agent for an automation process. However, an automation framework is not just a tool to perform a specific task, but rather an infrastructure that provides the solution where different tools can do their job in a unified manner. This provides a common platform for the automation engineer.
Test Automation demands considerable investments of money and resources. Right selection of automation tool, testing process and team, are important players for automation to be successful. Successful software development cycles will require execution of same test suite repeatedly. Using a test automation tool it’s possible to record this test suite  and re-play it  as required. Once the  test suite is automated,  no human intervention is required . This improved interest rate of Test Automation. Automation is done by using a supportive computer language like vb scripting and an automated software application. There are number of tools available which can be use to write automation scripts. Tools are specifically designed to target some particular test environment, such as Windows and web based applications.
Automation does not require Human efforts. You can run automated test unattended 
Test Tool selection largely depends on the technology the Application Under Test is built on. 
automation (white box) testing Scripts are executed during this phase. The scripts need input test data before there are set to run. Once executed they provide detailed test reports.  Testing tools can help automate tasks such as product installation, test data creation, GUI interaction, problem detection (consider parsing or polling agents equipped with oracles defect logging, etc.without necessarily automating tests in an end-to-end fashion.
Execution can be performed using the automation tool directly or using some Test Management tool which will involve the automation tools. Goal of automation (white box) testing is to reduce number of users to be run manually and not eliminate manual testing all together.

MY WORDS FOR SDLC MODELS

Software Development LIFE CYCLE Models.

The SDLC models are the methodologies that being selected for the Software development of project depending on the project’s requirements and goals. The selection of model has very high impact on the testing that is carried out. There are many Software development life cycle models that have developed in order to achieve different required objectives.  It will define the what, where and when of our planned testing, influence regression testing and largely determines which test techniques to use. The Software development life cycle models specify the stages of the process  the order in which they are carried out.

Software Development LIFE CYCLE Waterfall Model.

The SDLC Waterfall Model is first Process Model to be introduced. It is also referred to as a Very linear-sequential life cycle model. In a waterfall model, each phase must be completed fully before the next phase can begin. In waterfall model phases do not overlap. At end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project.  It is very simple to understand and use..

Why we use the waterfall model:

Requirements are very well known, clear and fixed. Ample resources with required expertise are available freely. There are no ambiguous requirements . 

Product definition is very stable. Technology is understood.

Advantages of waterfall model:

Works well for smaller projects where requirements are very well understood. Very Easy to manage due to the rigidity of the model – each phase has specific deliverable s and a review process. So 

Simple and easy to understand and use. The 

Phases are processed and completed one at a time.

Disadvantages of waterfall model:

This is Not suitable for the projects where requirements are at a moderate to high risk of changing. As Once an application is in the Software testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Not a good model for complex and object-oriented projects. High amounts of risk and uncertainty. 

No working software is produced until late during the life cycle. 

Poor model for long and ongoing projects.

Software Development LIFE CYCLE V-Model

Verification and Validation model called 

V- model 

. 

Testing of the Application and software is planned in parallel with a corresponding phase of development and maintenance . 

Just like the waterfall model, the V-Model life cycle is a sequential path of execution of processes. Each phase completed at the same time before the next phase begins.  

 Phases of the V-model 

1. Requirements:- Business Requirement Specifications and Software Requirement Specification begin  life cycle model just as same as the waterfall model.

The test plan focuses on meeting the functionality specified in the requirements gathering.

But, in this model before development is started, a system test plan is created and testing done with just built live . 

2. HLD (high-level design) :- This phase focus on systems architectures and designing. It provides overviews of solutions, platforms, systems, products and services/process. An integration test plan is created in this phase in order to test the pieces of the software systems ability to work together in a group as a load testing.

3. LLD (low-level design):- phase is where the actual software components are designed. It defines the actual logic for each and every component of the system. 

Components tests are created in this phase as well.

Class diagrams with all the methods and relations between classes comes under Low L D. 

4. Implementation phase:- That again, where all coding takes place again. Once coding is complete, then path of execution continues up the right side of the V where the test plans developed earlier are now put to use for testing and run application.

5. The Coding Phase:-  Module design is converted into code by developers.

This is bottom of the V-Shape model Validation and Verification.

Advantages of V-model:

Works well for small projects where requirements are easily understood. Simple and easy to use.Avoids the downward flow of the defects.Proactive defect tracking – that is defects are found at early stage.
Testing activities like planning, test designing happens well before coding. This saves a lot of time. Hence higher chance of success over the waterfall model.



Disadvantages of V-model:

If any changes happen in midway, then the test documents along with requirement documents has to be updated. Software is developed during the implementation phase, so no early prototypes of the software are produced.
Very rigid and least flexible.

Software Development LIFE CYCLE Incremental Model.

In incremental model is divided into various builds. Multiple software development cycles take place here, making the life cycle a “multiple-waterfall” cycle.  Cycles are divided up into smaller, more easily managed modules. The incremental Model is an evolution of the waterfall model, where the waterfall model is incrementally applied.

 Each module passes through the requirements, design, implementation and testing phases. 

The incremental build model is a method of software development where the model is designed, implemented and tested incrementally (a little more is added each time) until the product is finished. 

A working version of software is produced during the first module, so you have working software early on during the software life cycle. 

The series of releases is referred to as “increments”, with each increment providing more functionality to the customers. 

Each subsequent release of the module adds function to the previous release. The process continues till the complete system is achieved.

Why we use the Incremental model:

Requirements of the complete system and application are clearly defined and understood already. 

There are some high risk features and goals during there phases. 

There is a need to get a product to the market early as so soon. 

A new technology is being used. 

Major requirements must be defined; however, some details can evolve with time. 

Resources with needed skill set are not required .

Advantages of Incremental (I) model:

Easy to manage risk because risk pieces are identified and handled during iteration. 

More flexible  less costly to change scope and requirements. 

Generate working software and applications quickly and early during the software life cycle running . 

Customer can respond to each built whenever . Very 

Easy to test and debug during a smaller iteration. 

Lowers initial delivery cost.

Disadvantages of Incremental (I) model:

Needs a clear and complete definition of the whole system and applications before it can be broken and built incrementally. 

Needs good planning with design. 

Total cost is higher than waterfall costly so user not prefers.

MY WORDS FOR WHY TO START MANUAL TESTING

START MANUAL TESTING

The Manual Testing is to make sure that the application under test is defect free and software application is working as per the requirement specification document.There are different stages for Manual Testing like Unit testing, Integration testing, System testing and User Acceptance testing.A test plan document is created by test lead which describes the detailed and systematic approach to testing a software application. Basically the test plan typically includes a complete understanding of what the ultimate workflow will be.

This type includes the testing of the Software manually i.e. without using any automated tool or any script. In this type, tester takes over the role of end user and test the Software to identify any un-expected behavior or bug. Once the reported defects are fixed, the testers will retest the defect to make sure that the defects are fixed. The main goal of Software testing is to make software defect free & deliver good quality Product to customer.To ensure the completeness of testing (100% test coverage) test cases or test scenarios are created. Manual Testing Concepts also includes exploratory testing as testers explore the software to identify errors in it.There are different stages for Manual Testing like Unit testing, Integration testing, System testing and User Acceptance testing.

 To ensure the completeness of testing (100% test coverage) test cases or test scenarios are created. Manual Testing Concepts also includes exploratory testing as testers explore the software to identify errors in it.

After the testing is started the designed test cases or test scenarios will be executed & any differences between actual & expected results are reported as defects. 

As discussed previous , automated testing is extremely powerful and cost effective at allowing you to ensure that the system meets customer requirements now and in the future, and ensuring that as the system develops and grows, all the requirements and features are still working as you expect.The aim to decide how you going to use each technique to solve different problems. When you add TDD, the code quality is also increased which will have long-term benefits when it comes to the maintainability of the code base. This is where automated testing is best. However, at the moment automated testing is not very good when it comes to knowing if the application is usable by a human. They can't decide if the text and information provided will be understandable by the end-user. In other ways, it is extremely costly to automate certain parts of the system — for example a jQuery effect which can only really be verified by using the control and ensuring that the effect is as desired. We feel that although this could be automated, it is more effective to manually test the effect, as this will provide you with more confidence that it is working as you expect, and also it is cheaper in terms of time taken. Although we have already discussed at length the advantages of automated testing, there is still a time and place where manual testing is important, in some cases more important than automated testing. Many people have successfully released software and products without having any automated testing in place, instead relying on the manual testing techniques discussed throughout this. Even though this has been successful for many companies, we feel that the best approach to take is a mixture of automated testing, as we have already discussed, and manual testing. Combining the two provides you with a safety net to catch regression bugs, allowing you to push forward with the development and still catch the issues which only manual testing can uncover.