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.
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.
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.
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.
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.
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 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.
This section discusses the differences between testing in traditional and Agile approaches, the status of testing in Agile projects, and the role and skills of a tester in an Agile team.
A world-leading tech and digital skills organization, we help many of the world’s leading companies to build their tech and digital capabilities via our range of world-class training courses, reskilling bootcamps, work-based learning programs, and apprenticeships. We also create bespoke solutions, blending elements to meet specific client needs.