In the last few years, the advent of technologies like cloud computing, micro services, AI, IoT, among others has made the complexity of software development projects ever more challenging. These challenges affect all aspects of software development, including testing. To meet these challenges, we cannot use the testing approaches of the past; we must evolve to keep up with new development approaches.
Agile testing is an advanced approach based on the values of efficiency, agility, and collective ownership. By following these values, the testing process focuses on testing what is vital for high-quality products rather than investing in the less critical stuff such as comprehensive test documentation, long-term estimations that will likely be changed, etc.
This blog reviews the different aspects of Agile testing, including the different testing activities, principles, and challenges. In addition, it suggests a new way of thinking about testing and contains tips you can use to improve the quality of your products.
You are encouraged to build Agile teams that can solve their problems by promoting the self-organized approach that encourages all team members to decide together on the best way to improve the quality of their products.
To understand the true meaning of Agile testing and to gain the most from this chapter, we must break the glass ceiling in the industry when it comes to the definition of testers and developers.
I use the term “tester” to describe a team member whose main activities revolve around testing and all its supporting activities. I also use the term “programmer” to describe a team member whose main activities revolve around writing code. Using these two terms, I do not intend to narrow their role; I am merely using them for convenience.
Both roles are responsible for more than the narrow definition of tester or programmer. Programmers do much more than just writing code, just as testers do more than just testing.
On an Agile team, there is no one person responsible for coding, just as there is no one person responsible for testing. The true meaning of Agile testing is that each team member is focused on delivering high-quality software that will give the customer real business value.
I think that we should treat Agile team members without any constraints that limit their ability to grow, and as the great master says:
You must be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.
― Bruce Lee
The Origin of Agile Testing
Agile testing is a software testing practice based on the values of Agile software development. It’s a continuous process – where the product is developed and tested through the development life cycle rather than sequential, where testing is a separate phase. As part of the Agile testing process, the entire team is responsible for high product quality through collective ownership of all testing aspects.
Although a review of the history seems a bit too academic, I believe that to understand the true meaning of Agile testing we must know its origin.
“People must know the past to understand the present, and to face the future”
– Nellie L. McClung
Agile testing started in the late 1990s. It was originally introduced in an Extreme Programming (“XP”) project named Chrysler Comprehensive Compensation System, also known as C3. This project was to replace the payroll application with a single system that had no user interface (it uses files to read employee statistics that were analyzed and sent to a print vendor to process deposits).
The C3 project is an important milestone from an Agile perspective as it became famous as the birth project of XP. Under the leadership of Kent Beck (an American software engineer and the creator of extreme programming who took ownership of the project after it failed to reach a stable state), it became the first real project to embrace all the practices that are now known as Extreme Programming.
The C3 project had no separated testing groups. Instead, the testing was conducted by the same group. From the different XP principles, including pair-programming, they created test-driven development (TDD).
To understand why test-driven development worked so well in this project, that had no testing teams, let’s return to the layers of the product that had no user interface. This little detail makes all the difference, as it allows programmers to test their code with a clear definition of the expected results. This is the perfect scenario for programmers who had no test groups to rely on.
As the project became a success (at least relative to its earlier phases), the popularity of Extreme Programming and its principles increased in the industry. By the time the project was canceled (1999), there were many other software projects following XP and replicating C3’s early success.
As the popularity of Extreme Programming continued to grow, it had a great influence on the testing field as it promoted new ideas such as the removal of the testing role and that all tests should be automated.
Agile Testing in Scrum
XP is an Agile framework that has a specific technical guideline for Agile software development. At the beginning of this chapter, we saw how it changed testing in the Agile environment.
However, as the years went by, Scrum won as the leading Agile framework that set the standards for Agile software development. Scrum focuses on the framework of the development process but ignores the “how-to” for handling the practical side of software development and particularly how to conduct tests in this environment.
Furthermore, Scrum does not specify any information about any test role, as it embraces team ownership of the product with the expectation that they should decide how to do the work without external interference. As you can imagine, the lack of a real definition for this topic resulted in many misconceptions, innovations, and experiments. Now, after a few decades, there is still no agreed definition that fully addresses this topic.
The Agile Testing Values
Software testers before the transition to Agile 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 affects 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 conducts 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 to enter a new era of testing.
Individuals and interactions over processes and tools
This value values the human factor over any processes and tools, a standard 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 demonstrated by two main points.
First, at the center 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.
The second reason is that many pitfalls and delays are related to the lack of synchronization between departments which directly impacts the quality of the testing effort. In Agile, we build small integrated teams that help prevent many of these impediments.
A critical clarification about ignoring processes and tools: agile testing uses different tools at all levels of the testing process. This is 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 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 right from the beginning 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 which is a mandatory part of any testing project.
Agile testing leaves little room for documentation. As a result, 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 the things that matter; there is no time to create detailed Software Test Design (STD) that include precise steps or results. Instead, 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 by creating the project backlog, which contains the customer wish list. After that, agile teams use the same approach for their test practices, 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 aims to develop a quality product that meets customer demands. Therefore, testers must become involved at the very beginning of the project.
Responding to change by following a plan
The ability of the business to adapt during a project is critical in Agile perception. We live in a dynamic environment, making it almost impossible to design one plan to follow throughout the project. To remain relevant, organizations must gain the ability to absorb change (customer demands, new technology, etc.) that is likely during the project’s lifecycle.
The key to this perception is that the organization must understand that changes are part of any project and be ready to handle them. Again, testing is a great example. In the past, test teams created a whole 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. As a result, 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 entire development process
Published on Java Code Geeks with permission by David Tzemach, partner at our JCG program. See the original article here: Agile Testing Explained Opinions expressed by Java Code Geeks contributors are their own. |
Great article about software testing in agile