One of the most common misconceptions we hear about test-driven development (TDD) - and thorough unit testing in general - is that once it is implemented you no longer need to do any quality assurance (QA). We'll explain in this post a few reasons why you definitely still want to do QA and probably some user acceptance testing (UAT) as well.
The primary reason you still want to make sure you're doing QA when you're doing TDD is that TDD focuses on testing the units of code. If you read our guide you may recall that units can be as small as a single method or as large as an entire class (encompassing many methods that work together, but with a single purpose). But even when all of our tests pass and we've tested every possible permutation and combination of variables we still don't know whether our software actually works. All we know is that the individual parts work in isolation from each other.
Think about a few parts of a car that work together: the ignition switch, the starter, and the engine. Our unit tests have verified that the ignition switch engages when the key is in the proper position. They've verified that given an electrical current, our starter engages the flywheel. They've verified that when the flywheel is engaged the engine starts. We know that all of the individual parts of the car are working properly in isolation, so our QA process is to essentially make sure we've assembled those pieces properly. These tests are generally referred to as integration or end-to-end tests.
Thinking in terms of code again our unit tests will verify that a function works as expected with a given set of inputs. An integration test will verify that the button on the user interface actually invokes that function with the expected set of inputs. An end-to-end test will verify that when a user visits the page and provides all of their information and clicks the button, a new login is created and they are able to sign in to the application.
A secondary benefit of formal QA is simply getting a "second set of eyes" on the functionality. When we use TDD to write our tests and our code, it is most often the same person doing both. So when the developer delivers that software she is the only person who has really looked at what it does and how (and whether) it works. Having a QA team review it is a good safety check to make sure the developer didn't miss anything.
Although the use of TDD will significantly reduce the number of bugs, it will very rarely eliminate them completely. Having a QA person or team review the delivered software against the acceptance criteria is a really important step to make sure the maximum amount of bugs has been discovered prior to a demo.
Finally, in Agile (Scrum in particular) it is important to remember that the development team is responsible for delivering the code, it is up to the product owner (and stakeholders) to decide when to release that code for consumption. It is highly recommended that at least some testing is performed by at least a small subset of end users (this could mean stakeholders or a limited beta release or even using feature flags to enable the new features for a very small subset of users) before the product is made widely available. Just as QA looks for different things than unit tests, end users will look for different things than QA. Ideally, by the time our product goes to demo at the end of our sprint we will have identified and resolved technical bugs ("I clicked the button and nothing happened"). But the UAT process will help us identify whether we had some unknown issues in our requirements or somewhere else along the way ("Why can I choose to withdraw pennies from an ATM that only has $20 bills in it?").
Although TDD is a wonderful tool to reduce defects, it is only one tool in the overall testing belt. Just like the hammer is good for hammering in nails, we need to use other tools for other parts of the job.
No comments:
Post a Comment