Too Many Bugs - Part 3

Today is part three in the ongoing Too Many Bugs saga. You might want to check out part one and part two before reading on.

By eliminating the setup/config/curiosity class of bugs you should notice an immediate drop off in the amount of incoming bugs. It’s easy to file bugs on things that aren’t quite clear at first. By helping others get on board with what you’ve produced you’ve started setting expectations on where to test to get the most value out of the process. This isn’t to say that you as a software developer tell QE what to test and how to test it. That would defeat the purpose of having QE. They know how to test software and they’re good at it. Rather, during your ongoing dialogue with QE (it is ongoing, right?) there should be a discussion where you provide them with a list of the implementation topics that you’re most concerned about. You should address both business concerns and technical concerns.

The business concern is directly traceable to the business requirement. This is really just asking the question, “does this software fulfill this requirement?”. The answer should be fairly obvious but sometimes the requirement a software deliverable fulfills is not immediately apparent. Sometimes the software address multiple business requirements and there should be a discussion as to how they depend on each other and just as importantly how they do not depend on each other. Functionality of one requirement should not interfere with the functionality of a different requirement. It’s important that QE have some idea about the desired dependent and independent behavior in order to write tests to prove the software is correct.

The technical concerns you discuss arise from how you feel about the way you implemented the business requirement. Pointing out areas where the software is very flexible is always a good idea. This gives QE the hint that the software accepts a wide range of input and they should spend a little more time in validating what constitutes “correct input” and that the software only operates on correct input. If there is a point of extensibility in the software QE should take that as a directive to test that part as a high-risk to software security.

You shouldn’t limit yourself to talking about just flexibility or extensibility, these are just examples of the topics you should bring to QE. Remember, you’re taking the initiative to put a stop to brutal bug triage meetings and if the quality of your software improves as a result then just accept it as a positive side effect. Discussing these concerns with QE is a sure way to get some high-quality bugs out of them by allowing them to focus on areas of high-risk and core features. If you ever want to stop dealing with junk bugs then you have to do this. If there is ever a question on whether or not to talk to QE then always err on the side of over communicating. Too much is never enough.

Check back tomorrow for part four and the conclusion on Wednesday. Until then please forward this on to anyone that would find it interesting or helpful. And of course, please click the Digg This button below!