ample bug reports for web and product applications

On request from may readers I am updating sample bug report on separate page. Here are couple of sample bug reports and treat them as samples only. You can always make the changes in bug report format as per your requirements. Its not mandatory to use same fields in same sequence as specified below. You can find out your own working template. Read below articles on more guide on writing good bug report:

How to write a good bug report Bug Life Cycle

Bug report sample 1: Web Project bug report Summary: In CTR (Click through ratio) Total row calculation is wrong Product: Example product Version: 1.0 Platform: PC URL: (Provide url of page where bug occurs) OS/Version: Windows 2000 Status: NEW Severity: Major Priority: P1 Component: Publisher stats Assigned To: developer@example.com Reported By: tester@example.com CC: manager@example.com Bug Description: Reproduce steps: 1) Go to page: (Provide URL of page where bug occurs) 2) Click on Publisher stats link to view publishers revenue detail stats date wise. 3) On page (Provide URL of page where bug occurs) check CTR value in Total row of CTR stats table. Actual result: Calculation of Total row in CTR table is wrong. Also Individual row CTR for each publisher is not truncated to 2 digits after decimal point. Its showing CTR like 0.042556767. Expected result: Total CTR= (Total clicks/Total searches)*100

[Attach bug screenshot if any] Please fix the bug. ************************************ Sample bug report 2: Application product Bug report sample Application testing scenario: Lets assume in your application you want to create a new user with his/her 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 need to click on SAVE button in order to save the user and you can see a success message saying, New User has been created successfully. Now you entered into your application by logging in and navigate to USERS menu > New user, entered all the information and clicked on SAVE button and now the application crashed and you can see one error page on the screen, now you would like to report this BUG. Now here is how we can report bug for above scenario: Bug Name: Application crash on clicking the SAVE button while creating a new user. Bug ID: The BUG Tracking tool will automatically create it once you save this. Area Path: USERS menu > New Users Build Number:/Version Number 5.0.1 Severity: HIGH (High/Medium/Low) Priority: HIGH (High/Medium/Low) Assigned to: Developer-X Created By: Your Name Created On: Date Reason: Defect Status: 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 new user, 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 fields 4) Clicked on Save button 5) Seen an error page ORA1090 Exception: Insert values Error 6) See the attached logs for more information 7) And also see the attached screenshot of the error page.

Expected: On clicking SAVE button should be prompted to a success message New User has been created successfully. Save the defect/bug in the BUG TRACKING TOOL. //>

How to write a good bug report? Tips and Tricks

Posted In | Bug Defect tracking, How to be a good tester, Software Testing Templates Why good Bug report? If your bug report is effective, chances are higher that it will get fixed. So fixing a bug depends on how effectively you report it. Reporting a bug is nothing but a skill and I will tell you how to achieve this skill. The point of writing problem report(bug report) is to get bugs fixed By Cem Kaner. If tester is not reporting bug correctly, programmer will most likely reject this bug stating as irreproducible. This can hurt testers moral and some time ego also. (I suggest do not keep any type of ego. Egos like I have reported bug correctly, I can reproduce it, Why he/she has rejected the bug?, Its not my fault etc etc..) What are the qualities of a good software bug report? Anyone can write a bug report. But not everyone can write a effective bug report. You should be able to distinguish between average bug report and a good bug report. How to distinguish a good or bad bug report? Its simple, apply following characteristics and techniques to report a bug. 1) Having clearly specified bug number: Always assign a unique number to each bug report. This will help to identify the bug record. If you are using any automated bug-reporting tool then this unique number will be generated automatically each time you report the bug. Note the number and brief description of each bug you reported. 2) Reproducible: If your bug is not reproducible it will never get fixed. You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step. Step by step described bug problem is easy to reproduce and fix. 3) Be Specific: Do not write a essay about the problem. Be Specific and to the point. Try to summarize the problem in minimum words yet in effective way. Do not combine multiple problems even they seem to be similar. Write different reports for each problem.

How to Report a Bug? Use following simple Bug report template: This is a simple bug report format. It may vary on the bug report tool you are using. If you are writing bug report manually then some fields need to specifically mention like Bug number which should be assigned manually. Reporter: Your name and email address. Product: In which product you found this bug. Version: The product version if any. Component: These are the major sub modules of the product. Platform: Mention the hardware platform where you found this bug. The various platforms like PC, MAC, HP, Sun etc. Operating system: Mention all operating systems where you found the bug. Operating systems like Windows, Linux, Unix, SunOS, Mac OS. Mention the different OS versions also if applicable like Windows NT, Windows 2000, Windows XP etc. Priority: When bug should be fixed? Priority is generally set from P1 to P5. P1 as fix the bug with highest priority and P5 as Fix when time permits. Severity: This describes the impact of the bug. Types of Severity:

Blocker: No further testing work can be done. Critical: Application crash, Loss of data. Major: Major loss of function. Minor: minor loss of function. Trivial: Some UI enhancements. Enhancement: Request for new feature or some enhancement in existing one.

Status: When you are logging the bug in any bug tracking system then by default the bug status is New. Later on bug goes through various stages like Fixed, Verified, Reopen, Wont Fix etc. Click here to read more about detail bug life cycle. Assign To: If you know which developer is responsible for that particular module in which bug occurred, then you can specify email address of that developer. Else keep it blank this will assign bug to module owner or Manger will assign bug to developer. Possibly add the manager email address in CC list.

URL: The page url on which bug occurred.

Summary: A brief summary of the bug mostly in 60 or below words. Make sure your summary is reflecting what the problem is and where it is. Description: A detailed description of bug. Use following fields for description field:

Reproduce steps: Clearly mention the steps to reproduce the bug. Expected result: How application should behave on above mentioned steps. Actual result: What is the actual result on running above steps i.e. the bug behavior.

These are the important steps in bug report. You can also add the Report type as one more field which will describe the bug type. The report types are typically: 1) Coding error 2) Design error 3) New suggestion 4) Documentation issue 5) Hardware problem Some Bonus tips to write a good bug report: 1) Report the problem immediately:If you found any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report. 2) Reproduce the bug three times before writing bug report:Your bug should be reproducible. Make sure your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time you can still file a bug mentioning the periodic nature of the bug. 3) Test the same bug occurrence on other similar module: Sometimes developer use same code for different similar modules. So chances are high that bug in one module can occur in other similar modules as well. Even you can try to find more severe version of the bug you found. 4) Write a good bug summary: Bug summary will help developers to quickly analyze the bug nature. Poor quality report will unnecessarily increase the development and testing time. Communicate well through your bug report summary. Keep in mind bug summary is used as a reference to search the bug in bug inventory.

5) Read bug report before hitting Submit button: Read all sentences, wording, steps used in bug report. See if any sentence is creating ambiguity that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report. 6) Do not use Abusive language: Its nice that you did a good work and found a bug but do not use this credit for criticizing developer or to attack any individual. Conclusion: No doubt that your bug report should be a high quality document. Focus on writing good bug reports, spend some time on this task because this is main communication point between tester, developer and manager. Mangers should make aware to their team that writing a good bug report is primary responsibility of any tester. Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers. For better productivity write a better bug report.

Bug life cycle

Posted In | Bug Defect tracking, Software Testing Templates, Testing Life cycle What is Bug/Defect? Simple Wikipedia definition of Bug is: A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result. Bugs arise from mistakes and errors, made by people, in either a programs source code or its design. Other definitions can be: An unwanted and unintended property of a program or piece of hardware, especially one that causes it to malfunction. or A fault in a program, which causes the program to perform in an unintended or unanticipated manner. Lastly the general definition of bug is: failure to conform to specifications. If you want to detect and resolve the defect in early development stage, defect tracking and software development phases should start simultaneously. We will discuss more on Writing effective bug report in another article. Lets concentrate here on bug/defect life cycle.

Life cycle of Bug: 1) Log new defect When tester logs any new bug the mandatory fields are: Build version, Submit On, Product, Module, Severity, Synopsis and Description to Reproduce In above list you can add some optional fields if you are using manual Bug submission template: These Optional Fields are: Customer name, Browser, Operating system, File Attachments or screenshots. The following fields remain either specified or blank: If you have authority to add bug Status, Priority and Assigned to fields them you can specify these fields. Otherwise Test manager will set status, Bug priority and assign the bug to respective module owner. Look at the following Bug life cycle:

[Click on the image to view full size] Ref: Bugzilla bug life cycle The figure is quite complicated but when you consider the significant steps in bug life cycle you will get quick idea of bug life. On successful logging the bug is reviewed by Development or Test manager. Test manager can set the bug status as Open, can Assign the bug to developer or bug may be deferred until next release. When bug gets assigned to developer and can start working on it. Developer can set bug status as wont fix, Couldnt reproduce, Need more information or Fixed. If the bug status set by developer is either Need more info or Fixed then QA responds with specific action. If bug is fixed then QA verifies the bug and can set the bug status as verified closed or Reopen.

Bug status description: These are various stages of bug life cycle. The status caption may vary depending on the bug tracking system you are using. 1) New: When QA files new bug.

2) Deferred: If the bug is not related to current build or can not be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred. 3) Assigned: Assigned to field is set by project lead or manager and assigns bug to developer. 4) Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as Fixed and the bug is passed to testing team. 5) Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as CNR. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps. 6) Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as Need more information. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix. 7) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as Reopen so that developer can take appropriate action. 8 ) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as Closed. 9) Rejected/Invalid: Some times developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.