We have a competence centre QA. Why? Because we are seeing compelling evidence that this aspect of the development process is underused.

QA brings significant value in a number of ways. We have been monitoring its increased use into our teams. This is what we found.

What are we talking about?

For us, QA is not only about the hunt for bugs before deployment, but rather an integral and critical part of the entire process. It begins with requirements verification right through customer issues and doesn’t end. A good QA brings not only specific skills and experience, but just as importantly, a different approach and mentality to the process. This should not be underestimated.

Where to Begin?

At the start. Our more progressive clients are bringing QAs into discussions on product vision along with developers and product owners. Documentation is also analysed by the testers. What they find is that both disciplines can visualise up to 80% of the requirements, but most often we’re not talking about the same 80%s. What doesn’t overlap is extremely useful in getting clarity and moving forward.

Roles:

It is illogical and counterproductive to ask a developer to test his own coding to the full.
1.    Firstly, they’re not qualified to do this.
2.    Secondly, whilst they’re spending time doing a job for which they’re not qualified, they’re not coding.
3.    Thirdly, they most likely don’t have the motivation necessary to excel at this task.
4.    …..and this doesn’t even touch the question about who gets paid more.

The Upside:

According to our clients who have rigorously implemented a holistic approach to QA, the investment in time and resources pays off many times. What I mean is that it pays off in financial terms. The earlier a bug is found, the cheaper it is to rectify. The more time coders spend coding, the more code they produce. The costs of poor and buggy coding are long reaching and hard to quantify. Apart from the direct costs resulting from redoing properly what could have been done properly in the first place, there are reputation costs.

Conclusions?

Paradoxical though it may sound, the goal is not to eliminate bugs.

This is not an option. The goal is to create a durable system: one that will produce the highest possible quality of coding on a daily basis, and work relentlessly on improving this. This is what good QA is for. Use a holistic approach. Test right from the conceptual stage. Run testing parallel to coding. By breaking down the process into micro steps, you always have clarity. A bug in one week old coding that is still fresh in the memory is a doddle to fix compared to something buried six months back. The more deliberate your decisions during the process, the higher the likelihood that the result will correspond to the requirements. This is Quality.

It’s not about finding bugs. It’s about creating a process. Good results have no long-term value if they cannot be reliably reproduced.

Conscensia is a nearshoring company with 11 years of experience providing agile, stable development teams. One of our competence centres is on QA. If you’re interested in the subject and want to find out more, let me know. You can find my cell phone and email here.

Vincent Pearson
About Vincent Pearson

Consultant, Germany and UK, vpe@conscensia.com