design via a developer test using a tool such as JUnit, and then write just enough production code to fulfill that test. Responsibility for achieving required quality levels is shared with the development and quality management teams. The majority of testing is done by the development team, testing that is the agile equivalent of confirmatory testing (validation against the specification) because the tests written via TDD reflect your current understanding of what your stakeholders want. This reduces the overall work load on the quality management team, freeing them to invest time in higher value investigative tests. Developers are in the best position to efficiently and effectively perform confirmatory tests on their own work, particularly when they are collaborating closely with their stakeholders.
With this strategy, depicted in Figure 2, the development team produces working software after each iteration taking a TDD-based approach. At the end of the iteration, it deploys the new version of the system into the test environment. A combination of virtualization and deployment solutions can be used to control the change and service management overhead. A greater degree of automation is introduced into this approach for cohesive global change management. For example, a standardized, auto-generated bill of materials report may be created with the iteration release summarizing the changes implemented in that iteration.
Once the quality team has access to the latest version, it begins performing investigative tests on it; these tests are often more complex and more valuable than confirmatory testing. Investigative testing explores issues such as system integration testing, exploratory testing, usability testing, security testing, and so on, that are typically not the development team's primary focus. As the quality team finds potential problems such as missing functionality, misalignment with business requirements, or outright defects, it reports them back to the development team in the form of "change stories." These change stories are treated just like other requirements - they are estimated, prioritized, and put on the work item stack. As the change stories are addressed, the tests which address them are added into the regression test suite run by the developers: once the change is identified via investigative testing, it becomes a known requirement and therefore is validated regressively via the confirmatory approach of TDD. This allows the quality team to continually focus on higher value quality management activities.
There are several reasons why an independent quality management team is beneficial. First, it increases the chance that you'll find unanticipated defects. Although TDD is a very effective technique, it can be fragile in practice because it relies on the ability of your stakeholders to exercise full application coverage rather than just the parts of the application that they are directly invested in. [iii] Second, the integrity of your quality management process is at a reduced risk of compromise when a professional, independent quality team has validated it. Third, investigative testing is an exploratory technique usually requiring more sophisticated tools and methods than those commonly used for TDD by developers. The cost/value ratio for investigative testing methods and tools becomes diluted when they are put to general use. For example, it's not cost effective for cross-functional development teams to conduct investigative testing because the tools and techniques are rarely applied in practice to a depth that delivers significant value. Fourth, because the interface between the teams is very simple and the change management complexity is abstracted and automated properly, it is easy to leverage different teams wherever you need to. This increases your global reach and flexibility.
Continuous Agile Testing
In a fully agile approach the quality management team's
