How to Make a Developer Fix Your Bug

How to Make a Developer Fix Your Bug?

How to Make a Developer Fix Your BugThere are a lot of testers complaining that though they catch enormous number of bugs developers quite often don’t take them into considerations. One can probably say it’s not tester’s job to get the bugs fixed. But agree that it is anyway frustrating when somebody does not take seriously your efforts.

So the better you will sell your bug the more attention the developers will pay to it. One of the ways to get hold of developers’ time and attention is to write an enticing bug report working as your bug’s advertisement. If you follow the tips below your bug report will definitely stand out in the crowd.

  1. Your bug report should be as simple and straightforward as possible. If a 12-year-old child can repeat your bug in accordance with your report then you can consider your report well-written.
  2. Write realistic reports. If the bug has nothing to do with real life then the developer will most likely ignore it.
  3. The more required set ups needed the bug report c
    ontains, the easier it will be for a developer to reproduce it. This is all the more important when the detected bug proves to be configuration dependent.
  4. Your main task is to get to the root of the bug. Sometimes a bug has more than one symptom of the problem. In this case you should mention the most serious one for example data corruption and include its description in your report.
  5. You should always make your bug report inviting enough to capture the developer’s attention. The tip “You should make it inviting” does not actually mean “You should make it exaggerated” if you don’t want to risk your tester’s credibility. In other words your bug report must describe well the importance and possible consequences of the bug.
  6. Well-written report also includes the description how it affects users, what distress a similar software bug had run to before and how the competitors had suffered because of it.

A properly written report is a successful sales ad for your bug. Consider that you are selling your bugs to developers. Once you become a good marketer for your bugs you will watch them being fixed quicker and quicker.


About helenbeck


6 comments

  1. May 9, 2013 @ 2:41 pm Darren

    Though this report idea is excellent, there is a better way to commuicate to the development teams bugs impacting testig and code quality. With the umber of bugs found during any one testing cycle, writing a report of this magitude can eventually have a negative impact on testing. With tight windows to tesr in the schedule (QA very rarely has enough time to exercise all test cases), defect communication must be streamlined.
    Using a defect management tool like JIra, Quality Center, etc., developers can be informed realtime.
    The following attributes should be tied to each defect within the defect management tool:
    Defect Name — utilize a nomenclature that includes the system impacted and issue.
    Severity – Based on how many test cases are blocked
    Priority – Based on type of issue, a font inconsistency is not as high a priority as a potential API problem impactig data movement across an interface.
    Issue Reproduction Steps – Concise and remedial accompanied by a screen shots.
    Developer: Assure the defect is fixed by the developer who wrote the code,
    Add any other attributes like, Environment, Data Used, etc., that fit your business needs.
    You can then export reports for Defect, PMO, Staff Meetings, etc., to review and and assure visibilty to the business and management.

  2. May 9, 2013 @ 4:35 pm Rick Martin

    When I saw the topic I was fired-up and ready to rumble but when I read the post I agreed with it… just not the title. This is about writing a good bug report. It is “mom and apple pie”. My initial reaction was (and still is) with the title. It is not, never has been and never should be the tester’s responsibility to “Make a Developer Fix Your Bug”. By the way, it is not “you bug”, putting the tester / QA engineer in this position is counter-productive.

  3. May 9, 2013 @ 4:43 pm Marton Meszaros

    Or you could ask them to pair up with you and let you fix it.
    That way you learn how to code and what to do, and the programmer learns your way of thinking. 🙂

  4. May 9, 2013 @ 5:50 pm Richard Alexander Green

    – All defects should go into the backlog and prioritized by the stakeholders (not testers or developers) during release and iteration planning. Your audience is not the developer, it is the affected stakeholder.
    Questions about how a requirement is implemented should be sorted out with an acceptance test or requirements review – in either case with the affected stakeholder in attendance.

    – If your tests are properly automated, there should be rarely any question of how to reproduce a defect. The failed test will continue to show up in every run unless the test is suppressed or the requirement changed.

    – However, some problems may be sporadic. In that case, the logging system may need to be improved to discover the context where the bug appears. Alternatively, some program bugs only show up when the system is run under load with concurrent activities. A load testing simulator may be needed to surface the bug.

    – True “bugs,” defects that prevent a feature from fulfilling its business function, should be fixed before release. Defects that are a matter of aesthetics, interpretation, or compliance with standards are “quality” defects and might be given a lower priority and fixed when it is convenient.

    – Developers have additional issues that may also enter prioritization. For example, there may be code quality issues from code reviews and refactoring needs involving technical debt. Each of these issues that may make it more difficult to evolve the product in the future.

    – Ideally, all such defects and issues are recorded in your backlog and sorted out by the planning process.

  5. May 14, 2013 @ 2:06 pm Larry Smith

    It is NOT the testers job to make the developer fix a bug, but it IS the testers job to be thorough informing the developer (and team) of the repeatability, severity, possible impact upon the customer and to provide detailed steps describing all known ways to reproduce the bug.

    As far as sitting down with the developer and going through the code, I’ve only had that happen with a few of whom I was in good repoire and have had mixed results, never negative, but sometimes I felt they were dragging me through their code and could have possibly gotten to the root cause quicker without the time spent getting me up to speed (and I’ve been writing test code for over 20 years). I have had other instances where we found fixes as we talked through the code and their methodology and the other set of eyes was helpful. I do not think it is the developers job to teach testers how to code. This is typically not time well spent, unless it’s nuances and some best practices, which are sometimes local. Core coding standards can be self-taught or be acquired at nearly any local Community College or University in a semester or two.

    I think Darren nailed it with just a few mods:

    Defect Naming and ID Number
    Date and code/hardware Revision where detected
    Repeatability * Severity = Weighted severity
    Reproduction Steps
    Useful Comments

    As far as automation, some tests do not get it (some warranted, some not). Short development cycles often limit test automation development time (fixturing and software), and some testing gets pushed to manual tests, requiring more knowledgeable testers. I’m not saying that this is always a best scenario, but I see it happen more than I would prefer and practicality has to be considered.

  6. May 21, 2013 @ 3:45 pm Anthony Griffiths

    During the development of the test code, the developer/s should be designing and executing test cases for each routine within each section of the code simultaneously, such that at completion, at least 98% of potential bugs are eliminated. The remaining 2% should be caught when all parts of the program is assembled and tested, base on the requirement and real world scenarios. The delivery process to the customer, internal or external, should include verification of the test code requirement specifications, demonstration of test cases include potential failure modes, evaluation time period to allow the user/s to make assessment and provide feedback to the developer. Without a commitment from the developer to provide ongoing support, the customer may be left with the responsibility for making bug fixes. If the developer is a contract professional and there is no potential repeat work or business, after the sell-off of the test code, the customer may be on their own.


Would you like to share your thoughts?

Software testing & QA blog by TestFort © 2017

×