The Agile Testing Values | David Tzemach

Think about software testers in your organization before the transition to Agile. Those testers used to work in dedicated testing departments and act as the control gate for quality. Now that the organization has started the Agile transition, those testers are integrated into small teams and in many cases have the feeling that they are less important to the overall process.

An Agile transition will affect almost all aspects of the organization, such as mindset, culture and development practices. A vast impact on such important aspects has a direct influence on how the organization will conduct its testing, which is of course, a major part of the development process.

Agile teams must adopt a new way of thinking when it comes to software testing. This is the only way to adapt to the nature of Agile development. A good start is to examine the four values of the Agile Manifesto, which provide all the answers we need in order to enter a new era of testing.

Individuals and interactions over processes and tools

This value expresses the human factor over any processes and tools common in traditional software development. We can see it in how Agile teams are built as cross-functional, with both developers and testers. The main idea of integrating software testers with other roles within the same team is explained by two main points.

First, at the center of Agile software development is a team can produce an incremental working product at the end of each sprint to increase value for the customer. Can they do it without testing it? No, because each story must be developed and tested within the same sprint as part of the definition of done (DoD).

The second reason is that there are many pitfalls and delays that are related to the lack of synchronization between departments that have a direct impact on the quality of the testing effort. In Agile, we build small integrated teams that help the organization prevent many of these impediments.

One important clarification about ignoring processes and tools. Agile testing does not ignore them. Actually, Agile testing uses different tools at all levels of the testing process (automation tools, automated frameworks, etc.) as much as possible. This is really the only way to do it effectively.

Working software over comprehensive documentation

This value suggests that an Agile organization should be able to provide working software at any time (in more restricted scenarios even from sprint 1). In traditional software development, there is a strict separation between the different project phases and explicitly between development and testing (the testing phase can only start once the previous development phase is completed).

This approach is ineffective as the majority of the tests are conducted at the end of the development process, which increases the risk to the entire release process as quality issues found at this stage will have a major impact on the release timeline.

In the Agile development process, testing starts right from the beginning as part of any new development as part of the Definition of Done of each user story. This way, the team can release working software that is fully developed and tested.

One of the main activities of traditional testing is comprehensive test documentation that is a mandatory part of any testing project. Agile testing leaves little room for documentation. An Agile team will have to adopt new practices based on light test design and specification processes to allow maximum time for test exploration.

The focus of testing now shifts to focus on the things that really matter, there is no time to create detailed STDs that include precise steps or results. Agile teams must rely on advanced techniques like checklists, exploratory testing, error guessing and mind maps.

Customer collaboration over contract negotiation

The third value refers to customers. In Agile, collaboration with the customer is one of the most important things, as user satisfaction takes precedence over everything else. The collaboration starts at the beginning of the project in creating the project backlog, which contains the customer wish-list. Agile teams use the same approach for their test practices, by constantly looking out for the customer’s best interests and needs.

From a testing perspective, the product backlog can be seen as the skeleton of the test plan. The team’s target is to develop a quality product that meets the customer demands. Therefore, it is important that testers become involved at the very beginning of the project.

Responding to change over following a plan

The ability of the business to adapt during a project is very important in the Agile perception. We live in a dynamic environment, which makes it almost impossible to design one plan to follow throughout the entire project. To remain relevant, organizations must gain the ability to absorb change (customer demands, new technology, etc.) that will likely happen during the project’s life cycle.

The key to this perception is that the organization must understand that changes are part of any project and be ready to handle them. Testing is a great example. In the past, test teams created a full test plan for the entire project, which reduces their ability to absorb changes (each change added more risk and more tests had to be done).

In an Agile environment, tests are written for limited features and stories, there is no need to design full comprehensive test plans for the entire project, allowing the team to adjust their test plan at the lower levels of the project, reduce unwanted risks and increase the effectiveness of the entire development process.