Practice: Concurrent Testing

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/subsystem (or system) testing
Team considerations: small team with embedded tester(s)

How to read this practice

Use a multi-prong approach when you review this practice: you can start by focusing on the work products which will be produced and/or consumed during testing and then shift to the tasks involved in processing these artifacts. You might play different roles within your team: if you are a tester, then you'll 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 consumed), by whom and who are the main responsible roles:

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: