it takes you to find it after it has been injected.[ii] The implication is that a focus on quality management and testing at the end of the lifecycle is the worst time that you could possibly choose to do so.
The first step is to realize that it's advantageous to focus on quality management and test throughout the lifecycle, so at the conclusion of each iteration the updated specification and the current version of the system is provided to the quality management team as depicted in Figure 1. With this strategy, developers ideally should be unit testing to the best of their ability and then handing off what they have to the quality team, which is invariably responsible for the majority of the testing. Unfortunately, some development teams choose not to test their code and thereby place all the burden of testing on the quality team. We recommend against this but recognize that it may be too radical for some organizations to start with.
This strategy requires your quality team to either have a test environment available all of the time, or be able to easily set up the environment when it's needed and then tear it down quickly to make it available for other teams. With this strategy you may leverage virtualization by taking a snapshot of your configured and integrated development environment at the end of each iteration and sending or making that virtual machine available to your geographically distributed quality management team. The quality team would then test the last iteration while the development team progresses on the current sprint/iteration. Or you may use deployment tools such as BuildForge or InstallAnywhere that automate the movement and promotion of environments in lockstep with iteration releases. As your organization leverages several quality and deployment teams through multi-sourcing, this need becomes more important in order to control change management overhead and remain agile.
This approach is definitely a step in the right direction because it pushes quality management forward in the lifecycle, reducing cost, risk, and potentially the overall schedule. However, this strategy is only one of several steps that should be considered. First, it requires a significant amount of bureaucracy to communicate and coordinate changing requirements and code to the quality management team. Although this strategy introduces quality management early in product development and maintenance, it takes a reactive approach which doesn't keep the dedicated quality team in lockstep with the rest of the group. It creates a temporal distribution between the quality management team and the development team because they are focused on different deltas of changes and requirements.
In GDD, the impact of this distribution is even more pronounced and dulls the focus of the global software delivery team as a whole. Second, the change reports must be described in detail to provide sufficient information to the developers so that they can reproduce the change within their own environments. Once again, your overall cost increases. Third, this approach can be culturally disconcerting for traditional testers who want the entire system in place with the finished specification against which to test. This strategy promotes a "mini-waterfall" mentality within the team instead of a truly iterative one, which motivates long iterations and thereby increases cost and risk.
Incremental Agile Testing
Most organizations will find that the easiest entry point into global agile quality management (GAQM) is to adopt a TDD approach within the development team. With TDD you specify a requirement via a single customer test using a tool such as FIT or FitNesse, or an aspect of the
