Role of dedicated QA in the new age dev

T Ashok @ash_thiru on Twitter

Summary

In current times with rapid dev driven by Agile, with testing done by dev folks, is there a need for dedicated QA?  What is dedicated QA really? What  should be the value adding dedicated QA be in the new age dev?

I had an interesting discussion with an engineering director of a product company on the subject – “dedicated QA or non-dedicated QA”. He was keen on a strong development QA as part of engineering team with an additional dedicated(small) QA team, and was seeking opinions. That triggered the thought for “role of dedicated QA in the new age” .

Once upon a time software engineers developed code and also tested them. Then, dedicated QA teams became the norm of day and testing was ‘owned’ by these teams. In current times with rapid dev driven by Agile, it is kinda merging back into dev, with dedicated QA becoming thinner.  

A recent article in SD times “The software industry can’t agree on who owns QA, and that’s okay”  talked out “who owns QA” – Is it dev org or a dedicated org? So what is the right fit?

What is dedicated QA really? Is it a set of folks, a QA group vertical that works with various product/dev teams? Is it specific QA skills aggregated and nurtured in a team to provide specialised testing ?

What ‘dedicated QA’ really means is – a focus on QA/testing in an org. In a software org we need specialists, be it analysts, architects, developers, support and testing too. Dedicated QA does not mean reporting only into dedicated QA leadership position, it just means that we have QA specialists who have deep knowledge to systems/solution validation.

So what may be a right fit for doing smart QA in an organisation? In current times where it requires close collaboration with engineering, it is necessary to have dev QA as part of engineering. The dev QA may be largely focused on ensuring components and that features that are built are good enough to be integrated, which is really “testing-in-the-small”.  In addition to this, we need to validate the whole app/product from end users and deployment view – “testing-in-the-large”. This is where a System QA can come in handy.  Specialist QA folks who may be organised as a QA team vertical.  

Now if the product needs customisation to suit the needs of specific enterprises or if the product/application integrates/interfaces with may external applications, then it may be valuable to have a specific “Solution QA” kinda like ‘testing-the-whole’.

So think of QA function as a mixture of Dev QA, System QA and Solution QA each with a different objective of validation. Dev QA is about focusing on issues related to basic behavior and robustness of building blocks (components/technical features), while System QA is about validation of  system behavior and also attributes, whilst Solution QA may largely be business-value focussed/system-integration-oriented.

So dedicated QA is best suited for System and Solution QA, a set of specialists for large systems validation. Well this is what should have been in the first place, but guess over the years it has been corrupted with QA function more abused to look for all kinds of issues destroying the efficacy of the team. With adoption of Agile, we are back to basics, of good dev testing and then complementing with system and System Integration (SI)  testing.

In addition to validation, a dedicated QA (System/Solution QA) is best suited well to provide enablement & governance.  This implies test infrastructure setup, tooling frameworks, setting up process, metrics, identifying aids, doing reviews and improving the system. 

A smart QA setup is really about three things : (1) Enablement of good QA via setting up tools, process and infrastructure that can be leveraged by all (2) Validation – a clear validation focus in terms of specific issues at different stages by different folks – Dev QA, System QA and Solution QA  and (3) Governance to ensure that stuff is implemented well and is indeed working well. (1) and (3)  are probably best done by a Dedicated QA org in addition to the System/Solution QA. The picture below characterises this. The yellow boxes on the extreme left in the picture outlines a clear scope in terms of A-D)  as test-what, test-for-what, test-which and test-where.

Truly dedicated QA is about delivering value to the engineering and business and this is where we are headed. Of being faster and doing better from an engineering perspective, of ensuring great customer experience and delivering value, that is the role of dedicated QA in the new age dev.