Updated: Mar 2
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 vital aspects directly influences how the organization will conduct its testing, which is, of course, a significant part of the development process.
Agile teams must adopt a new way of thinking regarding 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 to enter a new era of testing.
Individuals and interactions over processes and tools
This value expresses the human factor over processes and tools common in traditional software development. We can see 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 centre of Agile software development is a team that 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 many pitfalls and delays are related to the lack of synchronization between departments that directly impact the quality of the testing effort. In Agile, we build small integrated teams that help the organization prevent many of these impediments.
One crucial clarification about ignoring processes and tools. Agile testing does not ignore them. Agile testing uses different tools at all levels of the testing process (automation tools, automated frameworks, etc.) as much as possible. This is the only way to do it effectively.
Working software over comprehensive documentation
This value suggests that an Agile organization should 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 most 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 significantly impact the release timeline.
In the Agile development process, testing starts from the beginning as part of any new development and the Definition of Done of each user story. This way, the team can ensure that each feature is released with high quality covering coding and testing activities.
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 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 customer demands. Therefore, testers must 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 vital in Agile perception. We live in a dynamic environment, making 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 handle them. Testing is a great example. In the past, test teams created a complete test plan for the entire project, which reduced 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 complete 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 whole development process.