How can we know bug is reproduceable or not?

" If the bug is getting simulated in all the environments available with same simulation steps then we can say the bug is reproduceable otherwise not. "

- Vignesh

What are the different types of Bugs we normally see in any of the Project? Include the severity as well. ?

The Life Cycle of a bug in general context is:

Bugs are usually logged by the development team (While Unit Testing) and also by testers (While sytem or other type of testing).

So let me explain in terms of a tester's perspective:

A tester finds a new defect/bug, so using a defect tracking tool logs it.

1. Its status is 'NEW' and assigns to the respective dev team (Team lead or Manager). 2. Th
e team lead assign's it to the team member, so the status is 'ASSIGNED TO'
3. The developer works on the bug fixes it and re-assings to the tester for testing. Now the status is 'RE-ASSIGNED'
4. The tester, check if the defect is fixed, if its fixed he changes the status to 'VERIFIED'
5. If the tester has the autority (depends on the company) he can after verifying change the status to 'FIXED'. If not the test lead can verify it and change the status to 'fixed'.

6. If the defect is not fixed he re-assign's the defect back to the dev team for re-fixing.

This is the life cycle of a bug.

1. User Interface Defects - Low
2. Boundary Related Defects - Medium
3. Error Handling Defects - Medium
4. Calculation Defects - High
5. Improper Service Levels (Control flow defects) - High
6. Interpreting Data Defects - High
7. Race Conditions (Compatibility and Intersystem defects)- High
8. Load Conditions (Memory Leakages under load) - High
9. Hardware Failures:- High


- Vignesh

TrackStudio :

This is a hierarchical issue tracking and bug tracking system. Our customers enjoy five unique benefits that allow them to maximize their developers' productivity, reduce the cost of management, and introduce standardized bug tracking and issue management into their enterprise.
Effective change and issue tracking requires much more than simple bug tracking, it requires the management of all types of issues. TrackStudio allows you to define separate workflows for each type of issue, including bugs, enhancement requests, documentation changes, and more. Effective issue tracking also requires comprehensive reporting, enabling you to improve productivity, accurately predict deployment dates, manage project resources, and analyze what work has been completed and what work remains.

TrackStudio is a powerful and highly flexible issue tracking system. Support for hierarchical structures, project-specific customization, and issue-level security allows users to customize nearly every aspect of the system with a few clicks of the mouse. Automatic and highly customizable e-mail notification ensures that all team members are tied into the issue and change tracking process. As change requests are updated, e-mail messages indicating the changes are sent automatically to the appropriate stakeholders.

TrackStudio is a highly scalable issue tracking solution. Whatever the size of your development team, wherever they are located, and no matter what platform they use, TrackStudio efficiently captures, tracks, and manages any type of change. SOAP API enables you to integrate our issue tracking system with call-center, front-office, and other third-party software. The high performance, scalability, support for nearly all servlet containers and DBMSs, as well as the affordable price, all make the TrackStudio a perfect choice for any company.

- Vignesh

NetResults :

NetResults Tracker can be used by all team members to coordinate their work, and to make sure that reported bugs and enhancement requests won't get forgotten. For example,

QA Engineers, Development Engineers, Customer Support can report bugs. Marketing, Product Managers can file enhancement requests.
The built-in workflow of Tracker would automatically route these issues (bugs and enhancement requests) to the appropriate engineers to get them implemented, and to the QA Engineers for testing.
The engineers can make attachments to the bug records and associate bug records to the files in the source code control system.
Managers can obtain status, reports, charts and graphs showing trends and problem areas. Issues that are not taken care of in time will automatically be escalated.
Everyone involved can obtain status, automatic notification, reports, and charts and graphs; and share knowledge and information.
The clients and partners can report problems directly, and obtain status, notification, etc. in a “self-service” manner.
Tracker thus delivers up-to-the-minute project information and status to team members everywhere to foster better communication and collaboration, and automatically manages these issues to resolution. As a result, it increases productivity, improves the quality of products, and increases customer satisfactions.


- Vignesh

Issue Tracking Management:

All businesses have issues (tasks, activities) that need to be tracked and managed to resolution. Resolution of these issues require the coordination of multiple individuals within and perhaps even outside the company.

NetResults Tracker can be used by all team members to coordinate their work, and to make sure that issues get resolved in a timely manner. The built-in workflow automatically routes these issues to the appropriate individuals. Managers can obtain status, reports, charts and graphs showing trends and problem areas. Issues that are not taken care of in time will automatically be escalated. Everyone involved can obtain status, automatic notification, reports, and charts and graphs; and share knowledge and information. Tracker can be used to discuss and exchange ideas instead of having to get everyone into a meeting at the same time and place.

Tracker thus delivers up-to-the-minute project information and status to team members everywhere to foster better communication and collaboration, and automatically manages these issues to resolution. As a result, it increases productivity, improves the quality of products, and increases customer satisfactions.


- Vignesh

Description of bug state model:


- Submitted
- Assigned
- Opened
- Resolved
- Ready for Test
- Closed
- Resubmitted
- Postponed
- Duplicate


[IMG]C:\Documents and Settings\vigneshanand\Desktop[/IMG]


- Vignesh

Test Lead :

Create the test execution schedule.


Tester :

Execute Test Cases.


Create Defects when defect is encountered using Test Director tool. Follow guidelines for mandatory fields and required test data. (see below for ‘Tester’ role). Assign Owner as Work stream Lead


Development Lead :

Query ‘Submitted’ Defects on a daily basis in preparation for meeting. Also email notification is sent so severity can be assessed.

Review any new defects inputted several times a day for validity and duplication.

Initial assessment of severity and assignment.



Development Lead :

Assess validity of defect.


Valid Defects: Assign to appropriate developer, validate, adjust priority and give a Date of Resolution.


Invalid Defect: Change state to Working as Designed or Enhancement Required, Resolved, Save, Change State to Ready for Test and Assign ownership back to submitter and add a Comment indicating reason. Click on OK.


Developer :

Receive Defect notification email; change State to Open indicating the defect is currently being addressed.

Assess Validity of Defect. (double check point after Work stream lead makes same initial evaluation)

Invalid Defect: Change state to Working as Designed or Enhancement Required, Resolved, Save, Change State to Ready for Test and Assign ownership back to submitter and add a Comment indicating reason. Save.

Valid Defect: Complete fix according to Defect Resolution Timeline (see above). Upon completion, change State to Resolved and assign to Build and Deploy team. Input the resolution details in the Comments entry area. Save the State change.

Build Verification Team :

Finalize scheduled build date/time.

Open all affected defects, input Build Version information, update to resolution of ‘Resolved’, and assign the defect to Ready to Test and assign the tester who originated the defect.

Send Test Lead a list components/defect ID’s modified for the new build version when the build is complete.



Build and Deploy Team :

Deploy new build for system test environment (frequency based on severity of current defects)

Release Notes should include defect ID’s
Email should be sent to all Technical Leads and other appropriate parties indicating completion of build along with release notes.


Tester :

Receive email notification indicating defects ready to Re-test.


For those defects returned from developer as ‘Working as Designed’ or ‘Enhancement Required’, speak to Test Lead and Defect Manager and do not change current state of defect or retest. Final resolution may require reassignment to IBM/ProjectX business analyst.


Re-test associated test case.

Successful retest: Change the Status to ‘Closed’.


Unsuccessful retest: Reassign defect to Developer and Enter Comment indicating reason for reassignment.

Test Lead :

Create Defect Report/Test Results Report(s) including defects resolved as ‘Working as Designed’ or ‘Enhancement Required’


- Vignesh :cool;

What are the different types of Bugs we normally see in any of the Project? Include the severity as well.

The Life Cycle of a bug in general context is:

Bugs are usually logged by the development team (While Unit Testing) and also by testers (While sytem or other type of testing).

So let me explain in terms of a tester's perspective:

A tester finds a new defect/bug, so using a defect tracking tool logs it.

1. Its status is 'NEW' and assigns to the respective dev team (Team lead or Manager). 2. Th
e team lead assign's it to the team member, so the status is 'ASSIGNED TO'
3. The developer works on the bug fixes it and re-assings to the tester for testing. Now the status is 'RE-ASSIGNED'
4. The tester, check if the defect is fixed, if its fixed he changes the status to 'VERIFIED'
5. If the tester has the autority (depends on the company) he can after verifying change the status to 'FIXED'. If not the test lead can verify it and change the status to 'fixed'.

6. If the defect is not fixed he re-assign's the defect back to the dev team for re-fixing.

This is the life cycle of a bug.

1. User Interface Defects - Low
2. Boundary Related Defects - Medium
3. Error Handling Defects - Medium
4. Calculation Defects - High
5. Improper Service Levels (Control flow defects) - High
6. Interpreting Data Defects - High
7. Race Conditions (Compatibility and Intersystem defects)- High
8. Load Conditions (Memory Leakages under load) - High
9. Hardware Failures:- High


- Vignesh