Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
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.
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?
Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
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.
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.
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.
Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
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.
Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
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.
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!
Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
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.
Copyrights reserved by author. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
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.