Something that has always bothered the development team is how big a piece of cake should the QA team get when a project hits successfully? But project failures are often blindly taken as a QA failure. Something very common that all generalized testing related articles talk about is that a person associated with anything that has something to do with quality is always dragged in to justify and explain the importance of his work. That always leaves me to wonder why no project managers or developers are ever asked this question. Maybe they are the ones who constantly bother us to prove ourselves.
Something that has always bothered the development team is how big a piece of cake should the QA team get when a project hits successfully? But project failures are often blindly taken as a QA’s failure. Something very common that all generalized testing related articles talk about is that a person associated with anything that has something to do with quality is always dragged to justify and explain the importance of his work. That always leaves me to wonder, why no project managers or developers are asked this question ever. May be, they are the ones who constantly bother us to prove ourselves.
Few weeks back, I attended a formal discussion, where we all met to decide upon the benefits of a parallel QA over what we have been practicing in the past, i.e. QA comes into picture when the project is half way through. And one of my fellow project leader argued that if QA lead gets the same importance and involvement as a project lead, would he share the same percentage of blame when a project fails? What was actually worrying the gentleman at that point of time that the QA lead will half the credit he deserved for a success. Whereas he should be thinking about the pluses his project will get under such circumstances.
Anyhow, lets think a little unbiased this time. What bothered my friend may be bothering other project leads too under similar threats (As they often think QA to be)
Let's make it clear–QA won’t share your blame
Development and QA are two different and independent entities, each being responsible for their contributions to a project’s success or failure. When a project fails, there is always more than one reason to jot down. Some may show the QA’s failure, others point out developer’s faults. Some may even explain equal lessons to both.
If the very first day, the software encounters an installation crash, the management can go forward straight to question the QA. If software was shipped without the QA pass and the users detect some critical bugs, it’s the project manager’s throat to be caught for making release decisions. If all went well but still you managed to slip the ship date, then none but the project lead is answerable. So are we all matured enough to realize and accept our mistakes or we are still indulged in a child’s play and blame each other for a failure?
If the QA lead has done a sincere job throughout, he will have nothing to share from you in case of a failure. In the other hand, he should accept his mistakes if his team failed to do what they are there for.
He won't take away your credits either
Likewise, the QA leads and project leads have different success stories to say in case a project clicks. The development team will be congratulated for writing a great piece of software whereas the QA team gets a pat for making it bug-free.
QA is not success-hungry. In most cases, a QA lead actually heads different test teams on different projects whereas a project lead concentrates on one or maximum of two at a time. They have better things to do than stealing away your victory.
An interesting point another friend added here was, the QA lead will be over-burdened if they are forced to enter a project from day one. As they will be working on few more projects that have reached a stage where actual testing has started and the newest project will not have much work for QA in the beginning. He made a mistake here by assuming that QA has no work on day one of the project. Where most project leaders shout about a proper planning phase before actual work starts, they fail to acknowledge that testing also needs some real planning in the beginning.
I may be sounding off-track here but I would like to put across a point that inception of QA from day one is neither meant to divide your importance with the QA nor to give them a psychological assurance of involvement. It is rather intended to make the QA plan for your success in advance. Did I make myself heard clear? The QA is there to ensure your success, and not to steal away your glory.