Agile Ali

You’re QA Team is the last line of defense before your software gets to the end-user. They are your last, best hope at finding any bugs that may be detrimental to a successful product. Treat them well and you will be well rewarded in the end with good communication and a successful product.

I’ve worked at places and with developers that see the QA Team as a nuisance. Constantly interrupting with bug issues when you’re just trying to move on to the next step. I mean, you tested it yourself right? What could some QA person have found that you didn’t account for? That’s the point. As the old phrase goes:

“It takes more intelligence to debug code than to write it. Therefore, if you write the most difficult code you can create, you are not smart enough to debug it.”

The other thing to remember is that when you as a developer test code you have the bias of knowing exactly how it works and will test with that in mind, there’s no escaping it. The QA Team is there to not only test it to see if it works, but to try the most asinine tests that end-users will do and see if it breaks. No matter how well you design your software the end-user will use it in ways you never thought possible, the QA Team is there to help you in these cases by testing obscure scenarios and reporting what they’ve found.

There’s more to it than understanding QA’s role and respecting them and relying on them. We as Developers need to be engaging them. When I turn over my software to QA, if I don’t hear anything within a few days I go bug them. My ultimate goal as should be the goal of all developers is customer satisfaction, if the customer isn’t happy you’re not going to be doing much development for them. We should be asking QA what we can provide so they can better test the code. Maybe creating a tool that will allow them to automate certain interactions or giving them DB access to see what’s getting stored. In any case we also need to be sitting down with them and making sure they understand exactly how the software works. Sit down and explain the DB table structure with them, make sure they understand the process flow. The more they understand of it the more they will know how to test it. Also keep in mind that a good rule of thumb to follow is however long it took you to develop it, it may take twice as long for QA to debug it. Your QA Team is your friend, not your enemy. QA is the body armor to failure. The more you help QA the better your chances of success.

So, Bottom Line : LOVE YOUR QA TEAM !