Classical project management, which thinks in hierarchical models, is becoming an inhibitor in the development process with the high demands on software development. Agile organisational forms have long since taken over at many points in the development process. This also applies to testing, which has gradually been linked to development and roll-out.
It started with the waterfall
The waterfall is probably the best known of all organisational models of processes, even if people are often not aware of it. In waterfall, everything is divided into phases that build on each other. All steps have to be mastered one after the other:
Conception, design, technical implementation, roll-out and support.
This clear definition creates a lot of security: Only when a phase has been completed, when a team has finished working on a phase, does the next team begin its task. In this way, all employees always work with a fait accompli. The task of test teams in this model is therefore merely to check the functions intended by the concept, but not to give new input into the process.
This hierarchical structure has the disadvantage of a lack of flexibility: if a team discovers problems with the concept in the later phases, it can no longer be changed. Especially with application-oriented products like software, which need to be continuously improved and adapted to the needs of your users in order to remain relevant, this rigidity can mean the quick end of a product. Another problem is the long time it takes to bring a product to market (time to market). The return on investment is therefore very late.
Agile development without agile testing
Agile development methods such as Scrum and Kanban have developed to counter these problems of the relatively rigid waterfall. The waterfall is broken up into iterations. In these iterations, the user stories and the associated functions of a software are placed in the centre and thus the most important tasks are processed first. Agile has also become a buzzword in testing, which is often used to sell services and products without actually being followed. Especially in agile development, it is still common practice to place testing at the end, shortly before the release. The reason for this can be found in the team philosophy of agile development.
Team structures
In agile teams, there is also no hierarchical allocation of functions, only specific roles: A Scrum Master makes sure that the Scrum method is permanently implemented as a framework and understood by all participants. Product owners decide which product features should have priority and explain these to the team. They are also the interface to the customers and other stakeholders. Finally, there is the development team, which is always interdisciplinary: team members must be specialists and generalists at the same time in order to be able to fulfil their role in Scrum well.
This means that in the Scrum framework, team members are also responsible for testing, which can become a problem if the responsibility is not taken or the time for thorough testing is not granted.
Agile Testing
Testing is therefore often not sufficiently considered in the outlines of agile development methods. Agile testing tries to solve this gap by integrating a test team into the process from the beginning of the project. In the waterfall method, testing is at the end of the process between development and roll-out. Agile testing, however, already starts after the completion of the first work products. This can already start with user stories and acceptance criteria, designs or the first prototype.
In the next article, we will take a closer look at the advantages and disadvantages of agile testing, when it makes sense and when it does not, and how test plans can be designed accordingly.
