Test-driven development (TDD) is a practice associated with a number of Agile flavors. It has become an increasingly popular method for integrating quality into software development at an early stage of the project lifecycle. In this article John Reber asks the question, Which members of the project team should own the tools that are driving the automated testing process within TDD? Are they now solely developer tools or should the testers be the owners?
Agile, TDD and the tester
Testers have always advocated early involvement in the lifecycle of a project through the likes of the V model. However, the V model cannot be successfully applied without buy-in from the entire project team - invariably this just isn't the case. Ask the average developer or project manager what the V model recommends and you are likely to be left with a number of quizzical looks.
The Agile approach on the other hand can be viewed as an answer to a QA analysts long held dream of being involved in the project at an early stage - the methodology is practically demanding it. Testers can benefit from the fact that Agile is a widely supported method which actively promotes involvement from all project members at most stages of the iterative process whether it is at project planning, estimating, participating in story huddles or attending retrospectives.
Testers not only attend these sessions but they are expected to actively contribute. In an Agile environment the tester is fully expected to utilize all the skills they have traditionally performed in testing plus a whole lot more. Not only does the tester have to rise to the challenge of these additional demands but the collaborative nature of Agile means that roles on the project can blur.
Nowhere is this truer than in the case of Test Driven Development (TDD), a method of development practiced in a number of Agile flavours such as eXtreme Programming (XP). TDD gives the programming team and the tester the assurance that potentially all written code is covered by a test, many defects are caught early and by extension a greater level of confidence in the code that is being delivered.
Increasingly TDD is being extended to the point that not only are programmers writing unit tests prior to the coding effort but functional acceptance tests are also being integrated into the process. This has been termed Acceptance Test Driven Development (ATDD). For some projects this additional effort is crucial to truly satisfying the requirements specified by the customer.
TDD and specifically ATDD raise a number of questions for the tester. At what point should the tester be involved in creating the automated tests for the story in play? Whose responsibility is it to code the automated functional tests? And who owns the test tools that drive the process?
TDD and the test tools
Whilst Agile often maintains there are no specialists, in the traditional waterfall approach the project roles tend to be clearly defined. In the case of test automation members of the QA team use tools, usually of the record and playback variety, to replace copious time consuming manual regression test suites. Because of the test effort required to create and maintain these suites the automated testing process and its respective tools are almost exclusively owned by the test team. Developers generally have minimal input into the process.
On Agile projects the approach to testing and test tools differs. There are a plethora of open source tools that support the TDD process. Programmers have the xUnit family to create unit tests aswell as a multitude of tools to create mocks and stubs for integration tests. Business analysts and even Product Owners may be involved in creating functional tests using tools such as Fitnesse. Then there are those tools used by both testers and developers, such as Selenium and Webdriver, which add further sophistication to the creation of automated functional tests.
The increasingly common use of these open source automated testing frameworks has added new complexities for testers. Testers have to consider some of