Search

Management includes the tasks planning, organization, management, and control of an activity. A project manager is someone who plans, organizes, monitors, and controls a project. To be able to do this, they need knowledge, experience, information, and competence. To understand the management of agile testing, we first have to take a careful look at how agile projects work: In most agile process models such as Scrum, Kanban, Extreme Programming and Lean Management, testing is not is explicitly addressed as we know it from traditional models—it is implicitly assumed that this is of course covered by the agile teams. The test is therefore inextricably linked to the development. There may be testers, i.e., specialists with a focus on quality assurance and acceptance testing, but a separate test track does not appear in most process models. Team members with a test focus thus cover several roles: on the one hand that of the tester, on the other hand that of the test manager and finally that of the quality manager.

Centralized quality assurance groups or departments are practically not provided in the agile world. But quality assurance is as important in agile process models as it is in conventional and long-established software development models. The early involvement of the customer in the development process is intended to ensure that the customer’s requirements are implemented as desired. It is also important in this case that the customer does not evaluate or accept the delivered software at the end of a software development project, but continuously during the acceptance of individual and short implementation cycles. In terms of close coordination between the customer and the project team, this basic rule is largely responsible for ensuring that change requests from the customer, as well as clarifications from the customer, can be processed and implemented promptly.

The consistent use of test automation is the only chance to ensure the quality of each potentially deliverable product at the end of each sprint. However, many aspects must be clarified and defined for maintainable and efficient test automation. These include the organizational and technical integration into DevOps environments and processes, the selection of suitable automation tools, the design of an automation framework, and the organization and planning of automation activities and automated test executions within or synchronized with the development sprints. If required, test automation know-how also needs to be established within the team. This is a challenge to most teams, but this investment needs to be considered as there is no successful agile testing without test automation.

With the shift to agile software development, the role and self-image of the tester and test manager have also changed dramatically. While in the past the tester’s job was to control what the development team produced, they are now part of the software development team. Understanding this is not easy for everyone and it is also not explicitly defined by Scrum as the most widely used agile approach with its role definitions (Product Owner, Scrum Master, Development Team). For a long time, this terminology even led to companies being under the misapprehension that they could do without testers altogether in the agile approach. In other situations, testers were formally in development teams but did not participate in all the ceremonies, such as sprint planning meetings. In the meantime, however, developers, product owners, and testers have learned what it means to be agile: to share responsibility for the implementation of an application development in an equal interaction of different competencies.

Documentation has always been a controversial theme in software development. Even the Agile Manifesto positions itself on this topic with the statement “Working software over comprehensive documentation”, which many saw as a license to completely get rid of the often tiresome topic of documentation. This also strikes a chord with those who believe that the only valid documentation for a software application is the program code itself, and in order to describe everything a program does, the additional documentation would have to be as comprehensive as the program itself, i.e. including all conditions and branches and loops. Accordingly, the documentation would be the same as the program code, only in a different language. Contrary to these polarizing views, this chapter takes a more differentiated look at various types of documentation, their different creators, users and their purposes. These aspects and the need to maintain documentation should be considered in advance and in the spirit of Lean Management, a Lean Documentation approach should be defined for each individual project.

This chapter examines multiple approaches, all of which have proven to be useful models in the respective project environment. Thus, the applicability of the traditional test process according to ISTQB in the agile context is considered and the Four Test Quadrants in Agile Testing are discussed. Another important topic for agile companies is scaling - therefore the approaches LeSS and SAFe are briefly presented. Additionally, case studies are outlined to illustrate what an agile test organization can look like.

In order to better understand the cultural change towards agile software development and to understand “Agile Testing” not only as a buzzword, it is important to take a look into the past. Much of what we perceive today as common knowledge has its justification in the methodical and technical progress of software technology in the last 30 years. Experience is an essential element for innovation and improvement. For example, the average age of the signatories of the Agile Manifesto in 2001 was about 47 years and back then, it wasn’t just about doing everything differently, it was about doing it better. This is often overlooked when “agile” is used to simply get rid of unpleasant things or to hide one’s own weaknesses. The approach to develop software in a cooperative, benefit-oriented, and efficient way, is the core of the agile idea.