Practice: Concurrent Testing
This practice describes how to fold testing into agile development.
Purpose
This practice adopts testing throughout an iteration, concurrent with development. This prevents teams from compressing testing into a separate activity at the end of an iteration or release. Concurrent testing reinforces the concept of feature teams working in parallel.
Main Description

This practice requires a high degree of integration and high-bandwidth communication between developers and testers. Given these requirements, the following are the main conditions for applying this practice:

  • Coverage: Component, feature, and subsystem (or system) testing
  • Team considerations: Small team with embedded tester or testers
How to read this practice

Use a multi-prong approach when you review this practice. You can start by focusing on the work products that will be produced or used during testing and then shift to the tasks involved in processing those artifacts. You might play different roles within your team. If you are a tester, then you will need to get a very good understanding of the artifacts, the tasks, and the guidelines supporting them. For a developer, the main points of interest are the artifacts used within this practice.

Start with the Test artifacts, read their description, and understand when they are used (produced or used), by whom, and which roles are mainly responsible:

Switch the focus to tasks and, depending on your main role within the team, review the associated guidelines, concepts and, if applicable, the tool-related guidance:

Additional Information
For more information on this practice,  see the practice resource page on IBM® DeveloperWorks®.
Relationships