How testers can convince developers of software errors

How testers can convince developers of software errors

What should a tester do when he finds an error in software that is developed using a technology he doesn't know well and the developer insists there isn't a solution for the error? How can the tester convince the developer?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

A tester should report errors/bugs even if he doesn't understand the technology particularly well. What is important is that you know the bug well, which means several things including the following:

Bug reporting resources:
Software bugs, errors and defects: What's the difference?

Software testing is improved by good bug reporting

How testers can practice bug advocacy with developers

  • What it is that is not working or working as you believe it should.

  • What do you believe the expected behavior should be? (In some situations, this is less obvious than it may sound.)

  • Under what conditions does the bug occur? This includes identifying the steps to reproduce the bug and can include other factors such as these:
    • Data and whether the particular data used is a variable in reproducing the bug (if data is a factor)
    • Other variables such as operating systems, browsers, service packs installs, timing or race conditions, memory, and caching.

There easily could be a longer list of variables, but the point is know the bug well and don't be intimidated by not knowing the technology well.

You could also view the situation as an opportunity to learn more about the technology, but I can appreciate that this might not be an option due to time restrictions or other factors.

A note about convincing a developer to fix a bug: Being able to show the impact of a bug and the likelihood of a user encountering the bug has always been the combination under which I am more likely to get an issue resolved. The more probable it is that the bug will be experienced and the higher the impact of the bug, the more important (and likely) it is to get the bug fixed.

This was first published in December 2008