#11-TDD Enhances QA But Does Not Replace it

Test-Driven Development (TDD) is not really a testing activity per-se, but an analysis process that drives product design.  That said, although it does not eliminate the need for after-development testing (QA/QC), it does contribute to that process.  This episode will show why this is.

Transcript

TDD Enhances QA But Does Not Replace it

TDD is a system development process.  It is a way to create highly valuable behavior while minimizing risk and waste.  However, it does not replace the need for the traditional testing that follows development.

Organizations that believe that QA is no longer needed once the development team adopts TDD as their way of working are making a massive mistake.  TDD will provide the tests needed to create the system, but no more.  Other aspects will still need to be tested.

Useability is a good example.  Is the system logical, easy and/or pleasant to use?  Also, how will the system perform under various usage loads?  What about security against malicious attacks?  I could go on. There are many important factors that TDD will not, cannot really address unless specific requirements are given to the team.  

Much as requirements cannot account for everything that can happen, neither can the TDD process that responds to them.  Every test written in TDD reflects the question “how will I know if I’ve failed?” and this question is not always clearly defined by the business.  When this is true, then exploratory testing is needed and that is the domain and expertise of QA.

Also, testing and development are different skill sets.  Knowing how to create a system does not mean you know how to test it, and vice versa.  Experienced testers will bring their skills to the table in ways that developers are unlikely to.

This is not to say that TDD does not have value to traditional testing.

In most organizations QA lags behind development, sometimes massively so.  This means that testing is almost always less rigorous than we would like, and often some of the more interesting tests are never conducted due to lack of time.  QA will inherit the tests that TDD created, and this will reduce their workload, freeing them to conduct those additional tests that might otherwise never happen.  Often, they will enhance those TDD-style tests in various ways.

Furthermore, when developers are using tests to dive their decisions those tests also drive the design of the product, increasing its testability as a natural consequence.  So, when QA comes to retrofit additional tests onto the system, they will find this much easier to do, which will also save time.

Also, when developers are writing tests they gain a better understanding of the value of those tests, and a greater appreciation of the work of QA.  At the same time QA, which previously may have viewed development as a source of difficult work, now sees the development team as a source of useful tests.  Overall, this promotes a healthier corporate culture.

TDD synergizes powerfully with QA but does not replace it.