Reporting bugs nobody wants to fix

Reporting a Bug Nobody Wants to Fix

Reporting bugs nobody wants to fixIs it worth your time? Why does this happen all the time? What can be done to get it fixed?

Every tester faces this situation and nearly everyone falls for the standard solution: report, forget and do not expect much. Developers are really slow on fixing bugs as it takes a lot of efforts and working hours, prolonging the estimated development and testing term, which is highly undesirable.

Why should a tester report bugs then? Do you need doing a job that is not giving results? Our answer is: Yes… and no.

The main flaw of bug reports is nearly always the same: testers give brief explanations of a single bug in their report, forcing stakeholders to do a big amount of job finding the possible reasons of bug existence and ways of its solution.

To say even more, it is sometimes easier to build another solution, than fixing this bug. If it does not force the app to crash, it can be surpassed. This actually shows the sphere of stakeholders’ interests: they need a working app as fast as possible and fixing bugs is not going to speed up the process; developing alternate solutions might be – and usually is- faster and easier.

The main result is approximately 1 of 10 bugs is fixed. It sometimes gets really frustrating. Is it worth your time and efforts? As long as you are paid for the job, you might say. There are several solutions for this case we want to offer you:

  • Creating clear and understandable reports. Tester usually knows the code nearly as good as the developer and skilled tester might see the solution at once. Showing your stakeholders’ you value their time and efforts by offering the possible bug origin and ways for solution is awesome. This way you might expect 4 or even 5 of each 10 found bugs to be fixed.
  • Creating 1 mega-report instead of several standard ones. Following the first advice is also a must. When your developers see the big volume of data you prepared collected altogether – it seems the app will never work without fixing all of the bugs.
  • Offering your situation vision and possible ways of solution (if any). The more experienced the tester becomes, the easier finding bug fixing solutions becomes for him.

Let us form a conclusion

  1. All of the bugs you encounter must be reported.
  2. The more clear and specific your report is, the better. Even if not all of the bugs are fixed at once, having that report on file could help a lot later.
  3. Do your best and your efforts will be rewarded!

Tagged: ,


TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.


5 comments

  1. August 13, 2013 @ 2:33 pm Ben Reese

    Bugs are a tricky issue, as they range so much in effort required to repair and in severity. Oftentimes, I would think the large report would be best, as not only does it intimidate the developers, as the writer mentioned, but would allow the developers to then attempt a fix at multiple issues at once, perhaps seeing a relationship in the code that may be causing more than one issue. Do you find that bugs tend to be fixed piece mail or in bundles? Does that affect the way you would report the bugs?

  2. August 13, 2013 @ 7:12 pm Dave Aronson

    Overall very good, especially the “take a guess at the origin” part. Sometimes, a tester will get a feeling about what part of the processing is going wrong, from what worked and what didn’t. Best if they also include that, but at the very least, the origin guess is worth something.

    However, I strongly disagree with the “mega-report” approach. At some point, someone will have to separate them out into individual bugs so that they can be handled in a normal sane process with tracking tickets and so forth. What you can do though is prepare an additional “out of band” report about it.

  3. August 13, 2013 @ 10:21 pm Paula Thomsen

    Ultimately a testers job must be to provide a measure of quality BUT we should not stop at just reporting all the defects.

    If a defect is accepted by the empowered customers of the service then we must make sure that user documentation/guidance notes, requirements and service support documentation is updated to reflect the agreed system feature. It will only get duplicated as a service issue later if not. We should ensure that any test completion report reflects the outcome of the defect raised, whilst ensuring an appropriate defect status is set, such as closed and accepted.

    This task can be time consuming especially where multiple stakeholders or service users exist. However it is essential.

    Where I believe that testing can go wrong is either not to report the defect, mark it as closed without saying why and without gaining agreement from relevant stakeholders or just as bad just let it sit there unaddressed for eternity. This either leads to erosion in confidence in testing service or disbelief in statistics.

    The same approach applies for all delivery approaches.

  4. August 14, 2013 @ 2:57 pm Scott Wolf

    I read your blog post and have to disagree with you on a couple of your points.

    First, I would like to know where you arrived at the “1 of 10 bugs is fixed” statistic. That seems awfully low. For most of the projects I have worked on the rate has been 80-85% of defects fixed, retested, and placed into production. If you’re consistently getting fix/closed rates of only 10% the project you are working on has larger issues which need to be addressed.

    Being a part of a project team we want to avoid creating an “us vs. them” atmosphere. As I read your suggestions they sounded like they would create a very divisive environment between QA and Development and I wanted to respond to two points.

    You wrote, “…skilled tester might see the solution at once.” Yes this can be awesome, however we are not a software developers, we’re in quality assurance. I might suspect or have an idea where the defect may be, and in cases where I am 100% positive of the solution I will offer it. In other cases I will write up the defect report with as much information as possible so it can be easily replicated by the software engineer. If you are in QA and you know more about coding, then perhaps you should be a coder?

    You also wrote, “Creating 1 mega-report instead of several standard ones.” In development environments which move quickly and are agile, holding all defects until the very end then showing your team a long list is not a good idea for the following reasons:

    – It’s not only frustrating to the developers, but slows the entire SDLC down.
    – Defects which could be critical are not reported with the correct urgency.
    – You have more of a chance to record a duplicate defect.
    – Defects which address symptoms of a larger issue could deferred or ignored in order to shorten the list.
    – It creates an environment of control and competition and not creativity and collaboration.

    Quality Assurance is about walking the fine line of balancing risk mitigation and project progress. The overall focus of defect writing is and should always be about the quality of the end user experience. Creating an environment where the developers are upset, where they are constantly reminded of the poor quality of their code by long defect lists, or delays in project progress will lower team morale and slow progress.

  5. September 5, 2013 @ 1:13 pm Murali

    Many things here
    1. “approximately 1 of 10 bugs is fixed”–I do not agree to this and something is seriously wrong if this really occurs

    2. “Creating clear and understandable reports”–If the bug is not clear enough, the developer can simply return or mark it as invalid
    So you cannot really call these as not fixed as there are not even bugs
    I suggest here to use a template to raise bugs so all information is provided as required.

    3. Obviously some bugs will not be fixed for various reasons
    a. The development team is not staffed as needed
    b. There might be more customer issues/high priority items for developer to work on rather than fixing a low severity issue
    c. No proper process/guidelines set
    d. As you mentioned earlier, It is not worth fixing a bug (which had low impact) but requires multiple changes/design changes…That is a call product management may need to take.

    What you can do
    –In addition to all what you said, keep sharing the average age of bugs+defect trends
    -Work on setting up a process at the beginning of project which defines what severity level of bugs must be fixed before the project can be approved
    -Defect bar
    if any developer is having more than certain number of defects (say 15) —he cannot take up a new feature/story until he fixes all his bugs. Similarly we can have a limit on the average age of bugs (say 30 days); The same can be applied to QA for defect verifications.
    This will help in ensuring that bugs won’t accumulate.


Would you like to share your thoughts?

Images are for demo purposes only and are properties of their respective owners.
Old Paper by ThunderThemes.net © 2017

×