Bug Life Cycle:

In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. The life cycle of the bug can be shown diagrammatically as follows: 

The different states of a bug can be summarized as follows:

1. New
2. Open
3. Assign
4. Test
5. Verified
6. Deferred
7. Reopened
8. Duplicate
9. Rejected and
10. Closed

Description of Various Stages:

1. New: When the bug is posted for the first time, its state will be "NEW". This means that the bug is not yet approved.

2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as "OPEN".

3. Assign: Once the lead changes the state as "OPEN", he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to "ASSIGN".

4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to "TEST". It specifies that the bug has been fixed and is released to testing team.

5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.

6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to "REJECTED".

7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to "DUPLICATE".

8. Verified: Once the bug is fixed and the status is changed to "TEST", the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to "VERIFIED".

9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to "REOPENED". The bug traverses the life cycle once again.

10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to "CLOSED". This state means that the bug is fixed, tested and approved.

While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal. Discovering and removing defects is an expensive and inefficient process. It is much more efficient for an organization to conduct activities that prevent defects.

Guidelines on deciding the Severity of Bug:

Indicate the impact each defect has on testing efforts or users and administrators of the application under test. This information is used by developers and management as the basis for assigning priority of work on defects.

A sample guideline for assignment of Priority Levels during the product test phase includes:

1.      Critical / Show Stopper — An item that prevents further testing of the product or function under test can be classified as Critical Bug. No workaround is possible for such bugs. Examples of this include a missing menu option or security permission required to access a function under test.
.

2.      Major / High — A defect that does not function as expected/designed or cause other functionality to fail to meet requirements can be classified as Major Bug. The workaround can be provided for such bugs. Examples of this include inaccurate calculations; the wrong field being updated, etc.
.

3.      Average / Medium — The defects which do not conform to standards and conventions can be classified as Medium Bugs. Easy workarounds exists to achieve functionality objectives. Examples include matching visual and text links which lead to different end points.
.

4.      Minor / Low — Cosmetic defects which does not affect the functionality of the system can be classified as Minor Bugs.

Guidelines on writing Bug Description:

Bug can be expressed as "Result followed by the action". That means, the unexpected behavior occurring when a particular action takes place can be given as bug description.

1.      Be specific. State the expected behavior which did not occur – such as after pop-up did not appear and the behavior which occurred instead.

2.      Use present tense.

3.      Don't use unnecessary words.

4.      Don't add exclamation points. End sentences with a period.

5.      DON'T USE ALL CAPS. Format words in upper and lower case (mixed case).

6.      Mention steps to reproduce the bug compulsorily.

 

Ref:
http://softwaretestinginterviewfaqs.wordpress.com

 

WHAT IS SOFTWARE FAILURE?

As software dominates most discussions in the information technology business, one need to examine carefully where we are headed in software reliability. It is reasonable to ask about the nature of software faults and the remedy for them, either from a fault-tolerance perspective or, more generally, on a software dependability front. There are conferences on this topic and over 300 technical papers that discuss some of its aspects. However, as many industry specialists agree, software is one area in the information technology industry which continues to baffle the scientist from a dependability perspective. While hardware & technology have seen four orders of magnitude improvement in the past decade, software has probably marginally improved or, some will argue, gotten worse. One then wonders if research in this area is headed in the right directions.

Thus, it is vital to examine some of the fundamentals, e.g., "What is a software failure?" This question is usually assumed to be well understood. However, when one examines it closely, it is startling how little is truly understood regarding those faults that matter. This problem is appreciably better understood in hardware systems, or systems, have been better tracked over the years and there is a larger body of experience in failure modes & effects analysis. However, the counterpart in software is far less understood. It is further complicated by a lack of clarity as to what is a software failure.

Ref:
Ram Chillarege
IEEE Transactions on Reliability, Vol. 45, No. 3, September, 1996.

Debugging removes defects

When a test finds a defect that must be fixed, a programmer must do some work to locate the defect in the code and make the fix. In this process, called debugging, a programmer will examine the code for the immediate cause of the problem, repair the code and check that the code now executes as expected. The fix is often then tested separately (e.g. by an independent tester) to confirm the fix. Notice that testing and debugging are different activities. Developers may test their own fixes, in which case the very tight cycle of identifying faults, debugging, and retesting is often loosely referred to as debugging. However, often following the debugging cycle the fixed code is tested independently both to retest the fix itself and to apply regression testing to the surrounding unchanged software.

Ref: foundations-of-software-testing-istqb-certification ( Book by Rex Black)

Test Techniques a diagramatic representation:

Test Techniques:

QTP Some IMP questions

Hi all,

Please have a look in the attached file. It contains some IMP questions on QTP based on QTP 8.2 and can also be valid with respect to QTP 9.2.
These are also some commonly asked interview questions.
QTP Question 01: What is QTPro? What is Quick Test Pro? What is Quick Test Professional?
QTP Question 02: What's New in QuickTest Professional 8.2?
QTP Question 03: Explain QTP Testing process?
QTP Question 04: How Does Run time data (Parameterization) is handled in QTP?
QTP Question 05: What is keyword view and Expert view in QTP?
QTP Question 06: Explain about the Test Fusion Report of QTP?
QTP Question 07: To which environments does QTP supports?
QTP Question 08: What is QTP or Quick Test Pro?
QTP Question 09: Explain the QTP Tool interface?
QTP Question 10: How QTP recognizes Objects in AUT?
QTP Question 11: What are the types of Object Repositorys in QTP?
QTP Question 12: Explain the check points in QTP?
QTP Question 13: In how many ways we can add check points to an application using QTP?
QTP Question 14: How does QTP identifies the object in the application?
QTP Question 15: If an application name is changes frequently i.e while recording it has name, in this case how does QTP handles?

Sample bug/defect report will give you exact idea of how to report a bug in bug tracking tool.

Here is the example scenario that caused a bug:
Lets assume in your application under test you want to create a new user with user information, for that you need to logon into the application and navigate to USERS menu > New User, then enter all the details in the ‘User form’ like, First Name, Last Name, Age, Address, Phone etc. Once you enter all these information, you need to click on ‘SAVE’ button in order to save the user. Now you can see a success message saying, “New User has been created successfully”.
But when you entered into your application by logging in and navigated to USERS menu > New user, entered all the required information to create new user and clicked on SAVE button. BANG! The application crashed and you got one error page on screen. (Capture this error message window and save as a Microsoft paint file)
Now this is the bug scenario and you would like to report this as a BUG in your bug-tracking tool.
How will you report this bug effectively?
Here is the sample bug report for above mentioned example:(Note that some ‘bug report’ fields might differ depending on your bug tracking system)
SAMPLE BUG REPORT:
Bug Name: Application crash on clicking the SAVE button while creating a new user.
Bug ID: (It will be automatically created by the BUG Tracking tool once you save this bug)Area Path: USERS menu > New UsersBuild Number: Version Number 5.0.1
Severity: HIGH (High/Medium/Low) or 1Priority: HIGH (High/Medium/Low) or 1
Assigned to: Developer-
XReported By: Your Name, Reported On: DateReason: , DefectStatus: New/Open/Active (Depends on the Tool you are using)Environment: Windows 2003/SQL Server 2005
Description:Application crash on clicking the SAVE button while creating a newuser, hence unable to create a new user in the application.
Steps To Reproduce:
1) Logon into the application
2) Navigate to the Users Menu > New User
3) Filled all the user information fields
4) Clicked on ‘Save’ button
5) Seen an error page “ORA1090 Exception: Insert values Error…”

6) See the attached logs for more information (Attach more logs related to bug..IF any)7) And also see the attached screenshot of the error page.
Expected result: On clicking SAVE button, should be prompted to a success message “New User has been created successfully”.
(Attach ‘application crash’ screen shot.. IF any)
Save the defect/bug in the BUG TRACKING TOOL. You will get a bug id, which you can use for further bug reference.Default ‘New bug’ mail will go to respective developer and the default module owner (Team leader or manager) for further action

Source: This is the guest post from Vijay D, published on http://www.vietnamesetestingboard.org/