Let the Agile Manifesto Guide Your Software Testing

[article]
Summary:
Although its values are commonly associated with agile software development, the Agile Manifesto applies to all people and teams following the agile mindset, including testers. This article examines the four main values of the Agile Manifesto and reveals how they can bring agility to test efforts—improving quality for your team and your customers.

The Agile Manifesto is the basis of the agile process framework for software development. It sums up the thought process of the agile mindset over the traditional waterfall methodology, and it’s the first thing we learn about when we set out to embrace an agile transition.

The Agile Manifesto applies to all things agile: Different frameworks like Scrum, DAD (Disciplined Agile Delivery), SAFe (Scaled Agile Framework), and Crystal all stem from the same principles.

Although its values are commonly associated with agile development, they apply to all people and teams following the agile mindset, including testers. Let’s examine the four main values of the Agile Manifesto and find out how they can bring agility to teams’ test efforts.

Individuals and Interactions over Processes and Tools

Agile as a development process values the team members and their interactions more than elaborate processes and tools.

This value also applies to testers. Agile testing bases itself in testers’ continuous interaction and communication with the rest of the team throughout the software lifecycle, instead of a one-way flow of information from the developers or business analysts on specific milestones on the project. Agile testers are involved in the requirements, design, and development of the project and have constant interaction with the entire team. They are co-owners of the user stories, and their input helps build quality into the product instead of checking for quality in the end. Tools are used on a necessary basis to help support the cause and the processes.

For example, like most test teams, a team I worked on had a test management system in place, and testers added their test cases to the central repository for each user story. But it was left up to the team when in the sprint they wanted testers to do that. While some teams added and wrote their test scenarios directly on the portal, other teams found it easier to write and consolidate test cases in a shared sheet, get them reviewed, and then add them all to the repository portal all at one go.

While we did have a process and a tool in place to have all test cases in a common repository for each sprint, we relied on the team to decide what the best way for them was to do that. All processes and tools are only used to help make life easier for the agile team, rather than to complicate or overformalize the process.

Working Software over Comprehensive Documentation

With this value, the Agile Manifesto states the importance of having functioning software over exhaustively thorough documents for the project.

Similarly, agile testers embrace the importance of spending more time actually testing the system and finding new ways to exercise it, rather than documenting test cases in a detailed fashion.

Different test teams will use different techniques to achieve a balance between testing and documentation, such as using one-liner scenarios, exploratory testing sessions, risk-based testing, or error checklists instead of test cases to cover testing, while creating and working with “just enough” documentation in the project, be it through requirements, designs, or testing-related documents.

User Comments

4 comments
Hemang Rindani's picture

Nicely scripted description.

Agile manifesto is a formal proclamation of key values and principles to guide an iterative and people-centric approach to software development. Agile software development focuses on keeping code simple, testing often and delivering functional bits of the application as soon as they're ready. 4 Key values explained in the article are enough to explain agile manifesto. It simply tells you to keep the client on the top and make an individual sense the responsibility he / her has to contribute to software product's success.

April 17, 2017 - 5:53am
Tim Thompson's picture

So far all agile projects I was involved in at least one of the leads interpreted "Working Software over Comprehensive Documentation" as cram in as many features and possible and document nothing. There are stories, but they often consist only of a title or have at best one and a half bullet points as acceptence criteria.

That is not as bad as I may make it sound (still, it is bad), but that makes detailed test cases to be the only documentation of features and functions the teams have to fall back on. The longer the project runs the more often team members ask QA to check the tests to determine how something was supposed to work as well as check test results to find out if something ever worked, when it broke, and when it was tested last. "Just enough" documentation in regards to test cases is often not enough at all when everyone else on the team falsely interprets this item of the manifesto as "no documentation".

In agile exploratory testing becomes more important, but is effective only when developers react quickly to issues found. After that test phase is over there is still need to do detailed and in depth systematic testing. These detailed tests are also a precursor for deciding which tests to include as regression tests. The more explicit and verbose such regression tests are the easier they can be automated. Even after automation is complete, these test cases are still needed. Test automation is nothing else than code, a change to the underlying framework can cause tests to behave differently and the "manual test cases" for lack of a better term become important again because they are the only artifacts available that properly describe function.

As far as "just enough" and less "comprehensive documentation" goes, it needs to be seen across the entire project. If every team and group within a team cuts back a lot on docs the team will be in a lot of hurt later.

April 30, 2017 - 8:15am
Nishi Grover Garg's picture

Thanks a lot Tim for sharing your thoughts.

I totally agree with you about the "comprehensive documentation" part as we have seen people, teams and managers assume that Agile means "no documentation", hence leading to a lot of hurt later. That is why we try to suggest teams to ensure documentation, ensure that it happens regularly and ensure that it is lean and 'just enough' for sustaining and maintaining the project.

Regards

Nishi

May 21, 2017 - 4:59am

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.