Agile Testing. Plan, Perform and Control your Tests the Agile Way.
How does agile testing differ from classic test management and how do you test agilely?
Agile testing combines development with testing. This is why the team itself defines at least one team member as tester or developer with focus on testing.
A lot of agile projects have made a positive experience with testing during the whole iteration. It is also possible to only test on the last days of the iteration. You often have a sprint 0 to plan your tests in the project.
Read here to learn more about classic and agile project management »
Short and sweet definition of agile testing:
Agile testing combines developing with testing.
Instead of planning a test activity at the end of the project,
you already test within your iterations.
Differences between Classic Test Management and Agile Testing
What Is Classic Test Management?
In classic test management, you find the infamous V-model, also known as waterfall model. It starts with the requirements analysis, which is followed by the system design, then comes the architecture design and finally the module design. That is the left side of the model. To test the system within this different phases, there are the validation phases on the right side:
- Unit testing: Functionality of individual modules is tested.
- Integration testing: Coexisting and communication between the modules is tested.
- System testing: Functionality, interdependency and communication of the system is tested in the organization.
- User acceptance testing: System is tested against requirements of a specification or contract in an environment that resembles the production environment.
All phases are completed step by step. Focus is on controlling and monitoring the tests. Thus, you create lots of documents such as test concepts, test plans or test protocols. Additionally, the roles of test manager, tester or quality manager are clearly separated from development as well as are the tasks.
What Is Agile Testing?
An agile team such as a Scrum team is self-organized. Ideally, there is no external project manager and certainly no test manager. The team itself takes these roles. Nevertheless, agile testing has to master the same tasks as classic test management:
- planning tests
- estimating and organizing tests
- creating tests and testing
- controlling, monitoring and documenting tests
These tasks are done in parallel within an iteration and not in activities that follow each other such as in classic test management. Agile testing does, however, take the classic validation phases into account. This is because these phases define different test types that require specific test methods and tools. Both classic and agile projects use these methods and tools. For instance, unit tests are code-related so you can to them automated; and system tests are mostly done manually. But agile testing organizes theses phases in a different system because – as mentioned before – it doesn’t complete them one after the other. It uses, for example, the concept of test quadrants to classify tests.
Read here to learn more about the concept of test quadrants »
Agile testing means:
You rather build the right product incompletely than the wrong product completely.
Testing the Traditional Way
Separation of development and test
External tester, test manager and quality manager
Test is its own activity
Four defined validation phases
Validation phases follow one after the other
More manual tests because development and test are separated
Extensive documentation
Testing the Agile Way
Development and test are combined
Tester, test manager and quality manager within the team
Test is part of every iteration
Validation phases are taken into account but put in a different system
Validation phases run in parallel
More automated tests because development and test are combined
Documentation in headwords
Automated or Manual Testing?
You can do automated tests within a test environment that is tailored to the programming language you use; or you test manually “by hand”. If you take the traditional validation phases as an example, automated tests are mostly performed in module and unit tests. Agile testing that is done, for instance, in Scrum projects also aims to automate system tests. Their motto is: The more automated tests, the better – because automation offers a lot of advantages: Every test can be planned, repeated and traced accurately. Questions such as “What exactly did you do there?” do not exist.
Nevertheless, manual tests are also essential in the field of agile testing. You can test the usability, for instance, only through people. The same applies for user acceptance tests. This is why manual tests present a challenge because people are involved and you must ensure that you can plan, repeat and trace your tests accurately.
Tasks of Agile Testing
The following tasks mainly concern manual tests.
Planning Tests
You already plan tests when creating your requirements or user stories because in this step, you must ensure that you can test your user stories later. This is why you define test cases that are linked to the requirements and become more and more detailed during the project.
Often, you also plan your tests in a sprint 0. In such a sprint, you define prerequisites such as the test environments and test tools. But you also create a test concept describing the organization’s goals and the planned test procedure. Additionally, you define the tester(s) within your team and agree on how you want to work together. For example, you agree on how you want to communicate bugs.
Estimating and Organizing Tests
Estimating the testing effort already poses a challenge in classic test management since at the project beginning, you often have little information or information with little significance. Agile testing also faces this challenge when estimating the effort for their user stories. This is why you will often work with a reference story: You select an easy user story and estimate its testing effort. Based on this estimation, you can then calculate the effort for your other stories. During the sprint planning or the Backlog Groomings you can, of course, specify this estimation.
To organize a test, you select the testers within your team. Some tests such as load tests, however, might require experts who are not always part of the team. For these special cases, you can ask external testers for help.
Creating Tests and Testing
As mentioned above, you create test cases when defining requirements. But agile testing can – in contrast to classic test management – also do without detailed test cases if they bring no value to them. Apart from this, agile teams often use the method of exploratory testing and therefore don’t create test cases at all. Instead, this method is based on the experience of the testers and their intrinsic motivation to follow what-if paths.
Agile testing also builds on extensive communication during test creation and the testing itself; and this mainly from face to face.
Monitoring, Controlling and Documenting Tests
Agile testing reduces the amount of monitoring and controlling compared to classic test management. The tasks of measuring, evaluating and defining counter strategies are verbally communicated most of the time. However, agile teams often find themselves in a classic project management environment: As a team, they are agile. But within the organization, they work in defined processes and must produce documented key figures. Such a hybrid project structure doesn’t allow verbal communication alone if you want to monitor and control your projects. You must certainly use appropriate software that produces such key figures. In this environment, the team also has to create more detailed documentation.
Agile Testing Methods – Two Examples
Both classic test management and agile testing use these methods.
Risk-Based and Value-Driven Testing
The tester only focuses on areas that show the highest risks and bring the most value at the same time. The Product Owner is responsible to gather the most important information with the items in the Product Backlog. The team (with its testers) analyzes the risks together based on this information. Multiply the impact with the probability of the risk and you have your test priority.
Exploratory Testing
The tester is driven by their intuition and experience when testing the system. They follow different paths until they find a bug. For example, they only test features that bring the most value to the stakeholders. Or they deliberately behave destructively and only test areas that are prone to bugs. They derive test cases after finding errors.
Knowledge to go
All about project planning and control in agile and hybrid projects