With the traditional, waterfall software development model testing is the last thing that’s done before deployment and it’s rarely paid any attention until the last minute. Even with an agile approach there needs to be some final testing prior to deployment; but it’s important to take advantage of the iterative cycles to do as much testing as possible as early as possible and to ensure that the tests are in fact valid against the requirements as early as possible. In order to do this it helps to think of testing as something that is more than "just testing the code"; the concept of testing should be opened up to encompass all aspects the development process.

For example - the requirements can be tested by an approach such as Card Conversation Confirmation – the product owner makes a statement about a requirement and the development team starts asking questions for clarification and detail. Traditionally this is known as ‘requirements gathering’ which is what it is undeniably. However, if the team can think of it more as 'testing their understanding of the user’s requirements' it becomes immediately associated with testing rather than a distinct step in the process. This process needs to be represented by all producer types, developers, designers, testers, etc.

With an Agile approach testing becomes a constant activity that is all about asking a whole range of questions and keeping them front of mind at all times:

• are we confident we understand the requirement?
• does the code we produced today work?
• is the process being followed?
• does the software give the user what he wants?
• has the user changed his mind?
• do we need to change the plan?
• is there anything impeding progress?

When considering the traditional testing phases, such as FIT, FAT, SAT, UAT use this wider context of testing to see that these don’t need to be lumped into the end of the project.