Agile software development projects are on the upswing. Even the most conservative organizations are now developing their software agile. Where documentation and milestone planning used to be the top priority, value has shifted in the direction of deliverable software and flexibility.
From a software tester's point of view, this raises the question of how agile projects change one's own work.
To be precise: Not as much as one might think!
The methods to create test cases, that means the toolbox of every tester, remains the same. So you can continue to use all the techniques you have learned over the years to systematically derive test cases.
Also different test levels, e.g. unit, integration, system and acceptance test, are also run through in agile projects. But no longer sequentially, but, depending on the progress of the user story, all at the same time.
The main change compared to traditional software development lifecycle models is that you do not plan, develop and test the whole system from the beginning, but always only, more or less, small parts.
Therefore, in agile projects one also works with relatively short iterations of a few weeks, after which potentially deliverable software is developed, which also includes complete testing, including regression testing.
It is obvious that a complete test of a system in development, especially with frequent changes to already existing code, is challenging.
Nevertheless, getting this done within one iteration is not a hopeless endeavor.
The good news first: In agile projects, the whole team is responsible for quality, not like in classic projects where quality is gladly shifted entirely to the responsibility of the testers. For this reason, on the one hand, the initial quality of the software-under-test is already significantly higher, and on the other hand, all team members participate in testing.
In addition, the work can be minimized by the appropriate choice of the test strategy and the test techniques used. And by consistent prioritization, because this way the risk associated with tests that are not carried out or carried out late can also be minimized.
Another factor that contributes to the success of the project is a high degree of automation of the tests. This is particularly important because the software in agile projects is subject to constant change and therefore regression tests are gaining in importance.
An agile test strategy, like in fact any test strategy, should prioritize the planned tests and define the depth of testing for the test conditions.
Probably the most widely used approach to this is risk-based testing. This paradigm is as applicable in the agile environment as it is in the traditional one, since testing is a risk-mitigating method for quality risks.
For this reason, when prioritizing and elaborating user stories, the risk should be estimated as well as the effort.
This little extra work helps us focus the limited testing time within an iteration perfectly on the "important" aspects of the system.
After the usual agile planning rounds, such as backlog refinement or sprint planning, we thus know what we want to test and what of it is important and how.
Regarding the "how", we can rely on a frequently used thought model: the agile testing quadrants.
These visualize common test types according to their purpose based on two dimensions. On the one hand, whether the tests have a technical or a business-oriented focus, and whether they are used to guide and support development or to put the system to the test.
A balanced test strategy takes all four quadrants into account, with tests on the left usually implemented in the form of (acceptance) test-driven development with a high degree of automation, and tests on the right designed to uncover weaknesses in the system at the business oriented (e.g., exploratory testing) or technical (non-functional quality attributes) level.
When you start your product development from scratch, the test automation topic is relatively easy to handle. You should consider automation from the very beginning. And if you rely on TDD, you already have a solid base of automated unit tests for the entire code.
The concept of TDD can also be extended to the business domain oriented tests by automating at least the acceptance tests of the user stories in the context of ATDD from the beginning. Unfortunately, domain-oriented tests are relatively unstable and susceptible to change, especially if they are automated via the user interface.
A second prominent model of agile testing can provide orientation here: the test automation pyramid.
The idea behind this model is simple - automated tests become more complex, more expensive and have a longer runtime the closer they are automated to the user. Therefore, automated tests should be automated at the lowest possible level of the pyramid.
For functional tests, this means checking whether they can be automated against APIs or directly against services.
This blog post is intended to help you get started with agile testing in your project.
What is the best way to proceed? The best thing is to start and try out how a test strategy can look like in your agile project.
You should not be afraid of experimenting, because the iterative approach of agile methods gives you the possibility to adapt and improve this test strategy again and again.
I wish you a lot of success in experimenting and implementing.
trendig
