Testing and development activities

Test activities are related to development activities, and thus testing varies in different lifecycles. 

One of the main differences between traditional lifecycles and Agile lifecycles is the idea of short iterations, each iteration resulting in working software that delivers features of value to business stakeholders. 

The diagram below shows the steps leading to one release of software, based on four iterations. In reality, the backlog might be bigger and several releases would happen. 

Release planning

At the beginning of the project, there is a release planning period. 

Here the development team and the Product will discuss which User Stories are to be included in the next release.

An iteration 

Release planning is followed by a sequence of iterations. 

At the beginning of each iteration, there is an iteration planning period. Once iteration scope is established, the selected user stories are developed, integrated with the system, and tested.  

These iterations are highly dynamic, with development, integration, and testing activities taking place throughout each iteration, and with considerable parallelism and overlap. Testing activities occur throughout the iteration, not as a final activity. Requires careful decisions about test strategies and test documentation.

Core team testing practices 

Testers, developers, and business stakeholders all have a role in testing, as with traditional lifecycles.  

Developers perform unit tests as they develop features from the user stories.  

Testers then test those features.  

Business stakeholders also test the stories during implementation. Business stakeholders might use written test cases, but they also might simply experiment with and use the feature to provide fast feedback to the development team. 

Hardening iterations 

In some cases, hardening or stabilisation iterations occur periodically to resolve any lingering defects and other forms of technical debt. 

However, the best practice is that no feature is considered done until it has been integrated and tested with the system.  

Another good practice is to address defects remaining from the previous iteration at the beginning of the next iteration, as part of the backlog for that iteration (referred to as ‘fix bugs first’).  

However, some complain that this practice results in a situation where the total work to be done in the iteration is unknown and it will be more difficult to estimate when the remaining features can be done. 

Releasing a new version 

At the end of the sequence of iterations, there can be a set of release activities to get the software ready for delivery, though in some cases delivery occurs at the end of each iteration.

Risk-based testing 

When risk-based testing is used as one of the test strategies, a high-level risk analysis occurs during release planning, with testers often driving that analysis. 

However, the specific quality risks associated with each iteration are identified and assessed in iteration planning.  

This risk analysis can influence the sequence of development as well as the priority and depth of testing for the features. It also influences the estimation of the test effort required for each feature.

Pairing 

In some Agile practices (e.g., Extreme Programming), pairing is used. Pairing can involve testers working together in twos to test a feature.  

Pairing can also involve a tester working collaboratively with a developer to develop and test a feature.  

Pairing can be difficult when the test team is distributed, but processes and tools (MS Teams, Zoom) can help enable distributed pairing.

The testing and quality coach 

Testers may also serve as testing and quality coaches within the team, sharing testing knowledge and supporting quality assurance work within the team.  

This promotes a sense of collective ownership of quality of the product.

Test automation 

Test automation at all levels of testing occurs in many Agile teams, and this can mean that testers spend time creating, executing, monitoring, and maintaining automated tests and results.  

Because of the heavy use of test automation, a higher percentage of the manual testing on Agile projects tends to be done using experience-based and defect-based techniques such as software attacks, exploratory testing, and error guessing.  

While developers will focus on creating unit tests, testers should focus on creating automated integration, system, and system integration tests.  

This leads to a tendency for Agile teams to favour testers with a strong technical and test automation background. 

Change is embraced 

One core Agile principle is that change may occur throughout the project. 

Therefore, lightweight work product documentation is favoured in Agile projects. 

Changes to existing features have testing implications, especially regression testing implications. The use of automated testing is one way of managing the amount of test effort associated with change. 

However, it’s important that the rate of change not exceed the project team’s ability to deal with the risks associated with those changes. 

When you are ready, select Next to continue.