In our last article, we looked at where the term Agile Development comes from and how methods such as Scrum and Kanban have developed. It also became clear that the claim of agile development can only be fulfilled if testers are integrated into the process from the beginning.
The standard for testing
The International Software Testing Qualifications Board (ISTQB (ISTQB) sets the standard for testing in their tester certificate and also teaches the basics for implementing testers in the agile development process.
This is called the whole-team approach: All people involved in a development, i.e. stakeholders, developers, the departments and, of course, the testers, are integrated into the planning and development process from the very beginning. Accordingly, testers, like the rest of the team, should be present at the daily meetings, communicate their progress, inform themselves about the progress of the development and take on clear tasks in the sprints.
Note: A DevOps without testers may claim to be Agile, but for true Agile development a tester is essential. Without this role in the team, the tests are not given enough time and importance. If, in the classic Scrum setting, everyone is also responsible for testing, then experience shows that it is prioritised less and placed at the back. Only in this way can emerging needs be considered in real time during development.
Test strategy - the stages of agile testing
The main task of an agile tester is to plan tests along the development process, taking into account the actual status. Depending on the test level, there are different types of tests that have to be carried out either automatically or manually. If it is a matter of pure functionalities such as connectivity, the scaling of apps to different device formats or the running through of certain processes (e.g. a shopping basket process), quantitative methods are suitable, in which test devices are emulated by a computer.
At Appmatics, however, we are convinced that automation only makes sense on real devices; certain errors cannot even be detected on virtual devices due to their lack of materiality. And ultimately, the emulation of devices represents exactly 0% of the actual users. Manual tests are necessary to test the various possible applications, design and user experience. In order to find usage scenarios that have not been considered, guided testing based on test cases must be supplemented by explorative testing. The individual types of tests, whether manual or automated, go hand in hand. The further development progresses and the closer one gets to a release-ready app, the more necessary manual tests become.
Determining test status - reacting and acting in a dynamic test environment
Agile teams use task boards or burndown charts to record a status. The task boards are modelled on the Scrum board: All tasks and the story cards (i.e. the functions for the end user) are recorded here and assigned to their status in columns. A burndown chart, on the other hand, shows the tasks still to be processed in relation to the time available.
In view of numerous different factors, this reduction of complexity is an essential task of testers who have to ensure the test progress. Within this realisation of the status of a development is the management of regression risk. Simply put, testers have to keep an eye on whether already functional parts of an application still work after a new development step, whether identified errors have been fixed or made worse.
For this very purpose, testers in Agile Development must be able to formalise the parameters of a test in such a way that they can be automated in the next phases or make an assessment of which regression tests are to be carried out manually.
Quality assurance and effort
As should be clear from the paragraphs that emerge: As testers:in, we often estimate which efforts are realistic. The further a development progresses, the better we know a product and also know which testing makes sense at which point.
The big goal and task is, of course, to ensure quality in the sense of the user stories. With a view to the big picture, testers gain the ability to assess risks and initiate necessary developments or bug fixes in time to save time and resources.
Conclusion: testers represent the stakeholders
Ten years ago, this distinctive role of testers could not have been foreseen. But since then, the professionalisation of testers has developed rapidly: as agile testers we, represent the customers
and the end users of a development. In this way, we take on an important perspective on the development process, which on the one hand leads to prioritisation and focusing of the work, results in efficiency gains and resource savings, and on the other hand always takes the stakeholder demands into account.
