Don't Push Aside Your QA Team

Like other engineering principles, software engineers should be responsible for delivering high quality, bug free products that work under all conditions. I wholeheartedly agree that developers (and the whole team) should be accountable for product quality and there needs to be a mind, and culture, shift so that the responsibility of quality control is not abdicated to the testing team.

In my experience, good unit testing and employing an approach such as TDD, is a great way to build good quality products. Taking this a step further, there are certain organisations that advocate a reduction in software testers and the traditional QA role in favour of developer-based testing. I see this most commonly in agile teams and those moving towards DevOps. This approach forces the issue and expedites the transition of accountability however I’m not convinced it’s the best way to deliver high quality products. In most walks of life, I tend to believe that “two heads are better than one” and a team effort offers a much better chance of success. Allowing each individual to play to their strengths and thrive in an area of specialisation that their personality type and thinking style is the key. A good tester thinks and behaves in a completely different way to a good developer. Not always, but often these strengths are mutually exclusive. The neuroscience of this is interesting and compelling. Dr Katherine Benziger explains this in a much more accurate and intelligent way than I ever could, and I recommend her book, Thriving In Mind to everyone. The conclusions she has drawn from her studies of the brain have helped me understand myself, my loved ones and my colleagues, what motivates them and what their inherent strengths are. That’s not to say that a developer can’t learn testing skills - and vice versa. Skill acquisition is only part of the story because application of skill leads to art. I know how to paint. I know how to dip my brush in the paint, I know how to make marks on a canvas and control my brush - but I don’t think my attempts at painting are particularly good art. Good testers have the ability to ‘smell’ a bug and know when to dig a bit deeper, when to test around a feature and what kind of negative tests produce bugs. I’m sure there are some developers out there that can do the same – though I’ve not seen many and those I have seen aren’t great developers.

A term I often hear, but I don’t like, is that developers testing their own features is akin to “developers marking their own homework” and therefore is not good practice. The reason I don’t like this term is I think a person marking their own homework is essentially a good thing. A child can learn a lot by comparing their work to a model answer. However, the benefit and feasibility is reduced when there isn’t a model answer to compare and contrast against. Too often in software development, we don’t have a well maintained, up to date specification, set of requirements or acceptance criteria that, in our analogy, are the equivalent of a model answer. Software specifications and requirements are therefore open to interpretation by the developer. If requirements are misinterpreted then no matter how thoroughly a feature set is tested by the developer, it will represent to him/her as correct functionality.

For a host of reasons, software engineering is somewhat different to other, more mature, engineering disciplines in that the standards are less controlled and less stringently applied. Furthermore, regardless of better standards, in these other engineering disciplines, whether it be civil, mechanical, chemical, electrical or electronic there is always an independent Quality Control process. So, I think the line needs to be drawn in software engineering so that developers (and the whole team) takes responsibility for quality which includes thorough unit level testing but there is an independent test of the delivered products. This should be planned and executed by a seasoned, professional tester that enjoys their job and gets a kick out of finding bugs.