In another article on agile we discussed, at a high level, the role of QA in Agile. We concluded that much of what QA teams do in Agile is not significantly different from more traditional methodologies; the difference lies within how the QA teams accomplish their responsibilities. We focused on how QA teams need to be focused on lean, flexible process, tools, and documentation, a collaborative working environment, and determining what value each work task provides. In this blog, we’ll explore an Agile technique called Test Driven Development (TDD) at a high level and explore the role of QA in this technique. TDD originated out of the Extreme Programming (XP) technique started in 1999. In 2003, Kent Beck helped launch TDD with the goal of encouraging developers to use simple designs to build better software.

There are essentially 5 steps in TDD:

1. add a test
2. run the test
3. write some code
4. run tests
5. refactor code (as necessary)

In the first step of adding a test, the developer must clearly understand the feature’s specifications and requirements through use cases or user stories. It is this first step which differentiates TDD from most other development techniques. Before any code is written, the developer must focus on the requirements and understand how to test the feature. Understanding the feature allows the developer to focus on design and not implementation, resulting in building code that’s easy to use. Once the test has been added, it is run with the rest of the test within the test harness to make sure it has not broken the test suite. If the new test passes, then the developer will write the feature/production code. After completing the feature/production code, the test suite is executed against the feature. If all of the tests pass, then the developer moves onto the next feature. If the tests fail, then the developer refactors the code and starts the process over again. Since TDD focuses on small, simple code integration, when tests fail, it is simpler to revert back to the last known operational point and start over then trying to spend hours debugging. It is this idea of reverting to past builds that allows TDD to make use of the Continuous Integration (CI) process to great effect.

At this point, a natural question might be: if testing is being completed at this level during the development process, where does the QA team come into play in TDD? First, we must understand that the test being written by developers are unit tests, meaning they are focused only on the feature being created. While stringing the unit tests together might help test a large portion of the code, it does not get into more traditional tests like integration testing, performance testing, compatibility testing, etc. We must also remember that having one person write both the code and the test will result in “build spots” in the software. For instance, developers typically may not consider the entire set of boundary inputs for a feature which would lead to break downs in the feature once a wider range of tests are executed against it. As in other process methodologies, the QA team will review the feature set once it is completed and has been added to the CI build. One of the major benefits of TDD is the obvious focus on testing up front. The testing up front should not take away from the testing that needs to occur on the software as a whole. Like all forms of Agile, TDD is focused on lean, efficient software development with an emphasis on speed.

So, how does the QA team achieve being able to balance speed with thoroughness in a TDD world? Test Automation is an important key to the balancing act. Since developers are constantly turning out automated unit tests, it’s imperative that the QA team leverage the unit tests and expand on them through test automation. The focus of the testing, not only for automated tests but manual tests as well, should be on adding boundary conditions and negative tests. Ultimately, the goal of the QA team in TDD is to establish a strong automated regression test that can continuously run in the backdrop of the feature testing going on for the new feature development. Since TDD focuses on delivering quality by focusing on test iteration during the development phase, it’s incumbent on the QA team to follow suite with high numbers of iterations throughout the testing cycle.

We’ve learned that a test first approach like TDD can add valuable benefits to your development process. However, along with the benefits, there are some quality gaps that need to be addressed by a QA team in order to make sure the software delivery is of the highest order. When using TDD, QA teams should focus on leveraging unit tests for building a comprehensive automated regression suite that is running all the time. QA teams should also focus on testing boundary conditions, negative tests, and including different types of tests like integration testing, compatibility testing, and more. By utilizing an effective automated test strategy with focused manual testing, the QA team can help ensure a high quality delivery in a TDD world.