“It’s a Bug!” Part 2 : Be The Diplomat – How to drop the news to the development team.

Previously in “It’s a bug!” we met Ali – a software tester working on an Agile software project. Ali had just begun testing a new deployment and had found a pretty major bug. Moral was high amongst the project team and Ali knew that dropping the news of a big bug which would probably take some time to fix would not go down well with the development team. Nevertheless, due to the severity of the issue it was critical to the project that the information about the bug be passed on quickly. Ali, being the conscientious type wondered what would be the best way to tell a sensitive developer who was very proud of his work, that his code wasn’t perfect. There are a number of approaches to informing the development team about bugs, I however would recommend the “Face to Face” First approach. The Face to Face First approach involves discussing the defect with the person who was responsible for the development of the code where the bug was found before formally logging it in a defect tracking tool such as Quality Center or BugZilla. Getting into dialogue with developers throughout a project always helps to build strong relationships amongst team members and is by far the best way to disclose defects after your tests have revealed them. It is important however to use tact in order to avoid the “Ugly Baby” effect (We’ll get on to that a little later). So what are the guidelines for informing a developer about a major bug.

Small talk first. Don’t just run up to the developer screaming “I found a bug, I found a bug!” As with any conversation try to break the ice a little first. I’m not suggesting you kick off a lengthy debate about how the global economy can be fully recovered, maybe just comment on the weather, ask how the kids are doing or find out whether he thinks the new Microsoft Xbox One will be better than the Sony PS4.
Ask the developer to watch. After a bit of small talk or even while you’re still chatting, ask the developer to have a look at your screen. Go through the steps to recreate the bug, making references to the related business requirements as you go to demonstrate your understanding. Try to keep the developer engaged by getting agreement as you go that the actions being carried out are valid test steps. Just before you reach the step that manifests the defect ask the developer what should happen next. If the answer is not what is about to happen then you’ve got agreement that there is a bug before it even happens.
Let the developer point out the defect. You must then execute the bug inducing step to allow the developer to call out the bug without having to do so yourself.
Offer to file the defect report. Agree on the severity and priority of the defect. Discuss possibilities of what the root cause might be and other areas of the application to test which may be affected by the same bug. Note as much information as possible and let the developer know that the report will be in the defect tracker promptly.

There will be occasions where things won’t fall in line with the script.

During step 2), where you ask the developer what should happen next, the developer’s response differs from the expectation you have based on your understanding of the requirement. This means that either the developer’s or your interpretation of the requirement is wrong and you need to agree on the correct understanding.
During step 3), where you run the step to reveal the defect, it is possible that the defect may not occur. To avoid this embarrassing situation

reproduce the defect a few times before sharing it with the developer.
ensure that all environmental test conditions are unchanged from when the defect occurred.

In later posts we may discuss other techniques for defect disclosure to avoid. These include.