Bug Report Writing

Do you think, a bug found you or you found a bug? Who wants to know about this bug? How you are about to tell this? Whats next?
Make the bug report sellable!
Ravisuriya

Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Bug Report Writing

1. This is not the Introduction. Its an Education!

You might be curious to read particular authors books or articles by looking for it anywhere asking, Elsewhere I see them? Similarly you might see particular telecast of programs on television when it is hosted by particular person or team. Likewise you might be more interested in hearing news from a news reader of a television channel. If you observed all these instances, it has one thing in common. That is, the person who wrote, who hosted and who read the news was able to reach you with what they wanted to tell and probably you got what you wanted. Software test bug reporting is no different from the above instances. It happens most times, people crib their scalp to read the bug reports written. On next scene people would no more be interested in reading the bug reports. Dont you think a credibility of tester is gained by the bug reports she or he writes? It is simple as this -- you have a piece of paper and partial or incorrect or couple of words saying the address of a person whom you want to catch up in the metro city. Will you remain motivated to continue the hunt of address with these words on a piece of paper having no better help to locate it? OK, it depends on the context in which one is. Same happens with programmers, managers and stakeholders of a project. This group will not be interested further to read a bug report when it is bugging them more than the bug you have described. People will not read the bug report in complete for time they have or given or left in the project schedule. Yet, they want the application to be better. How can this happen? What can we do as a tester? Start practicing to write a bug and test report in the influencing style to describe the problems and information you have found along with what was asked by stakeholder(s). Doing so, you help them in making a better decision; testers dont make a decision. This fetches you the credibility. Oh! Wait before you are lost in this thinking, I will take you ahead in your thinking. On the start off flying notes, probably, no writer became incredible in first writing; no outstanding sports men became world record star in just first practice; no musician gave humming tune of yours in first music node note of them; no vehicle riders/drivers/flyers took off and landed without jerks in first go. All these brains does practice consistently & strive better each time to make their work useful and of service. In contrast, software testing is a service which you provide to your clients. Make it useful for them. As a tester you cannot change fate of software users but you can influence fate of software project to be healthy, if stakeholders make use of your useful testing provided if it is effective. And it is not too late yet; anyways dont make it still late.

Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Bug Report Writing

2. Bashes of the Bash!

Before going into grinning read, see few bashes. Dont be surprised by what you see. These are few bug reports in public web by testers. If you unlearn and learn anything seeing below snaps, make note of them. Ask to self does it makes any sense to you and team of testers with whom you work. How different the bug report you write is?

2.1 Bug Report Title

2.2 Detail Description of Bug

Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Bug Report Writing

3. What is the purpose of writing a bug report?

To help stakeholders for taking suitable decision in context of your project so all are benefited. To get the problem fixed that you inferred and have reported. To make stakeholders see what trouble they can face with the problems that are obvious and not very obvious. To describe the probable impact of problem or bug if it is not considered for fix. To describe your observations which you feel can be risk and of cost in (any) context of time.

3.1 What I should be doing?

Know the people who use your bug reports. Know do they understand the details what you write. If they dont follow, make sure the problem described is understood by them though it contains technical details. Hence they can take better decision on the bug or problem you are telling. Do the programmers understand what I have written? Do I know what they need from me while I report a bug? Collect these details, it helps! Does the way of reporting the bug and its contents helps the programmer to see o What the problem is? o Where it is from? o Does it related to any bugs we have fixed or reported earlier? o If Im (a tester who reported a bug) unavailable, will my tester friends in team can take this bug for reproducing by reading it? Can they understand what I have written? Will they be able to test and update the bug by working with stakeholders?

Now you see the importance of a bug report. Yet we see: Information needed for stakeholders and programmers not provided to a level where they are confident in making application better. On not finding required information to write in bug report, it is not communicated to stakeholders and in the bug report. Why so? Writing a bug report in one line having 6 or 10 words which intensifies problem much more. Just screen shot attached with confusing seven or ten words saying it is a bug. No steps to reproduce for programmers and other testers, though it is reproducible. Copy paste of test case and its expected result; then say reported a bug. Necessary details or attachment not included in bug report.

Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Bug Report Writing

Fighting for priority and severity of a bug written while not sure about the impact of the problem. Fighting to show duplicate bugs reported without knowing the context behind each bug. Incomplete writing of a reported bug. People finding it hard and time consuming to understand what is said in bug report. Bug report not describing what the problem is and what the given fix is by people who addresses the bug. So regression tests will not be that effective for limited details known to testing team and tester reported. When asked about it, most in team would not know what the problem is; what the fix was and finally unable to reason how it got closed with such uncertainties.

Question to ask is who all are impacted for this way of writing, handling a bug and encouraging doing it so? Whom all are you seeing now? Do you see yourself who is in impacted list? If not, impact analysis is not very right to the context youre in now.

4. Bug Report Writing

Bug writing is a skill as other skills you think off and knew. One can write better reports on consistent practice understanding the contexts. What the bug contains varies from project to project and company to company. You can use template of yours to write a bug by practicing to context. In general the bug report contains below section as we know: Description Test Environment Steps to reproduce Expected behavior and Observed behavior Attachments Reproducible Test Investigation Notes Risks, if problem is not addressed: o Impact to customer o Impact to business o Impact to credibility of service provider in business market o Cost of not addressing the problem for customer and service provider o Legal implications and penalties

Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Bug Report Writing

4.1 Description
Often the test objective of a test case is copy pasted for description. It also happens that description contains more than 150 characters and yet not describing what the problem is. This wont make people to be influenced by bug written in first place. Does the description say in which module and area of application where the problem is noticed? People reading the bug report should feel emotions of problem from the description of a bug report one writes. How often we write make others to feel the impact of problem in less than 150 characters? 150 characters because, probably it is readable in one view. Story for a bug is needed; avoid dragging story lines in a description and summary. Note: Summary and description varies from tools or template or format used to report a bug. Description can be better if: Having not more than 150 characters for better reading in preview of one view It contains the area of application and components. Abbreviation of components can be used with common understanding in people using the reports. It tells the problem in simple words which is understood by all and if possible with no technical words. Your customer who is not aware of authorize action in network might not understand if one says preauthorize fails for packet contents and size in description.

Does below written description make sense and give the feel of the problem? 1. PO: AJC Job:- Looks like job is not created as split count is not fired to server though user enter details of it. 2. FB: Tag:- Seems like moving the tag region around the image is annoying. Happens that user has to delete and insert new tag. 3. Bank: Acct. Statement:- Unusual time compared to other bank services in providing internet account statement for supported time range. 4. MI: NewReg:- Need not be lucky having magic hands to login with no valid account. Bypassing server validations makes anyone to login as super user.

4.2 Test Environment

Test environment information not included in the bug report written can make the time miserable to those who look for it. Having details of environment where the problem was noticed, helps people to analyze what the problem actually is and how to proceed in locating to handle it. Know what and how much to include for the context you are in. Anything in excess makes boring though it is useful; unfortunately not all understands this when in need of details.

Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Bug Report Writing

Test environment can include few of these User and type of user using the application; machine hardware and software configuration; browsers and its versions; antivirus; firewall; AUT version being tested; URL hit for testing (with port number); device name and version; device OS and configuration; screen resolution; memory chip used (with space consumed & available); history detail if any change in environment where application is being used, was used or will be used, etc. For example, testing software which interacts with hardware, the room temperature where hardware is operated and since how long it is used, can have influence on behavior of software & hardware.

4.3 Steps to Reproduce

Wont you be glad when you know and simplify the steps to impress the client and getting the new assignments with revenue jumping beyond millions every quarter? OK! Are these steps are reproducible? Relate this to bugs reproducible steps. See who all are benefited now with steps to reproduce which roots down to root problem rather than which just shows glimpse of one of the symptoms of the bug. Having this in report helps and if found more than one way to reproduce write them too. You may not know if those other steps show other symptoms or problems that havent been recorded by tests carried out so far. At times it can be annoying to read more than 6 lines for steps to reproduce for few. But when you think of those extra lines it actually helps others too apart from programmers in reproducing the problem or to come close for it. There is no annoying in writing extra lines. It adds value! Dont make these extra lines as useless lines. If felt difficult to have these steps in written words or not getting exact trace of steps, make use of video to record your actions. Video recording tools such as Windows Media Encoder and brief detailed description of problem should help. Search for more such free tools to record your actions to tell about the problem. Sometimes writing exact steps to reproduce might not be possible. Illustrate the problem with story of what you did and observed. This story telling of you should show the potential impact from the existence of problem.

4.4 Attachments
Ask your stakeholders what kind of files is needed when you report a problem to trace it. This can be of great help if they find needful clues in the attachments for fixing a bug. Know what the limitation in file size and file types for attaching the files. Use the compression tools such as WinRAR, WinZip etc., to compress files and attach if it is of size that matters to viewer and you.

Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Bug Report Writing

Collect log files that system generates for unusual behavior you observe. Also see if OSs log says for the problem you see. Memory consumption details of OSs and application can also be useful in contexts. Make sure that attachment has a naming convention and format which tells its relationship to bug submitted. Ex: 12821_a.jpg, 12822.rar If the attachment has information which provides details or that can lead in the way to collect details of knowing what the problem is, it would be helpful. Further in steps to reproduce you can mention what to refer in attachment for that step. Describe each attachment so that relevancy of it is available to problem you are trying to tell.

4.5 Reproducible
Providing the information whether problem or behavior reported is reproducible consistently or not will provide insight on what steps and traps are to be set by programmers to catch traces of problem. If said occurrence of problem is intermittent, provide details why you feel so and words when you might see. When not sure where about the trigger point of the intermittent problem, providing detailed information of your actions since you started to test can be helpful for other investigators. Do not forget to attach any logs if available in these scenarios. This is where the video recording of application behavior comes handy. Innovate and think of ways how you can handle such scenario to narrow down the patterns to reproduce the problem. It adds value to your credibility!

4.6 Test Investigation Notes

Can you name any one investigator you know or read about? What makes them different from others when solving a problem? What they use while investigating? If we help our testers to be a Sherlock Holmes or Allan Pinkerton of software testing for finding and investigating problems in application, you would be benefited. And this comes by consistent practice with observational and introspection skills. For a tester, to start off, it might not be possible to investigate and debug as how a programmer does it for fixing a bug. If tester does investigation and gives vital information which helps in fixing a bug quickly, wont it help you all? The other benefit is you can expect the problems where you say it is forbidden area to testers, if you encourage testers to practice testing and investigation. Do you think it helps your business to be better against your competitors? Dont confuse this for automation; it is not the automation. Make note of or have a checklist which asks: What skills do you need for carrying out better investigation? Am I improving in such skills? Know what details you provide from your investigation helps people in making better decision.

Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Bug Report Writing

Know what kind of information people need from your investigation. Try to get them. If needed take help. Do not forget to give the credits for brain(s) and tools which helped you. To what all you have access in application and how to make use of it? What tools (including a human brain) you need to have for investigation. This comes in help when you want to pick suitable tool for the context. Of course, whatever you use, a brain should be used in all cases. Else there would be no difference between the tool and a tester. Know how to make use of internet here. It can help. Internet is a tool, too. Update your armory with skills and tools consistently. No need of expensive tools. Simple tools or with no tools you can solve the problems at times. It is a skill and can be better only if practiced investigation skills like Sherlock Holmes or Allan Pinkerton did. Study the model of application being tested. Gather reasons why it can be, why it cant be etc., and brainstorm. Look outside and learn from other systems (not just computer systems). You will find clues how to investigate and crack the things. You can add on the points here. If I add all my practices, you might end up not starting for yourself in innovating one for you.

Provide the details of tools (with version) you used. This helps people who are fixing the problem. After all, do we know this Software Testing is a technical investigation carried out for providing quality related information for stakeholders to make better informed decision. If you have not educated your testers and not yet started to carry out test investigation, its a right time to do so. It might not be possible to carry your investigation at times; mention it in bug report when you cant do it and why. Bug report with test investigation is key hint to avoid something which you dont want to happen for customers whom we love and for money what we get. Collect such hints from test investigation and build credibility and much more money in business.

4.7 Risks If Problem Not Addressed

It is usual, bug or behavior reported to see them in light weight. Not that it is done on purpose. It is the context which makes to do it so. This is where how influencing your bug report can be is calibrated for its attention grabbing and letting to know the concern. If potential problems are neglected saying it is of low priority at this time, rare scenario, no one does that, duplicate, the other fix we give it fixes this as well etc., this is where the problem displacement will have its birth. It is simple to solve a problem and make life easier we write software which brings in other problems. And when fixing these problems we give rise to other problems. How often, these problems impact are analyzed by testers and programmers? To simplify, todays bug is tomorrows requirement and todays requirement is tomorrows bug.

Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Bug Report Writing

If the bug report is not influential and sensational, we wont grab attention of the stakeholders general aspect of psychology and anthropology. As said, purpose of writing bug report is to get addressed the problem that can actually bother stakeholders. To get addressed, report should call the people into it for feeling the treatment. For this to happen, writing of bug report should be cool! How to do it? There are ways of doing it and you keep finding them once you start doing it. Few kickoffs to start with: Better yourself in writing stories of problems you see in application you test. Reason is, one can think it is not a problem while it can be a problem for her or him. Story you tell should visualize and tell the trouble which stakeholder faces if the problem written is not addressed and as well if it is addressed. Tell how the characters in story go into the whirlpool of anything on incurring the costs of taking no decision or incorrect decision on a bug in stakeholder context by not addressing it. Dont exaggerate! Keep the essence of the problem and know the taste of your stakeholders. Cook stories to their tastes. If you know or study the costs and legal litigations from the problem not addressed, bring that to notice of stakeholders. Bring in the realistic incidents that have happened in history or which you are aware of it but not public keeping it still concealed for having problems unaddressed. Educate yourself about legal litigations, costs and histories of problems in software computing industry. You might have to learn from others cost as well if you dont have to be in the heck cost.

5. Closing Note
Make the bug report influencing to keep it interesting and sellable for getting a fix to problem it describes. Dear programmers, forget and neglect not to write the root cause analysis, whats the problem, whats the fix given, and where the changes have been made in code and programming or/and business logic. All these helps your testers to test the fix better. Dear testers, never neglect to write the detailed details of tests you did while regressing bug(s) that is said as fixed. You know, not all of us try to understand what Regress and Regression mean and relate it to Software Testing. Oh, it is not what you see on web, forum and few testing books.

Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.