The Agile Manifesto for Testers

It is an old, often repeated story, but one must take the time to appreciate the Agile Manifesto and how it was made back in 2001 in Utah; after all, without it, the world would not be able to come up with multitudes of great products that have been developed using the various Agile frameworks. The aim of those 17 software engineers was simply to come up with ways of building better software, and thus Agile was born.

Testers are an integral part in any software development project – they help their teams build products with quality by lending their insights as well as their time in checking and validating the developed product. Here, we will list what each of those points in the Agile Manifesto mean for application testing and quality assurance.

“Individuals and interactions over processes and tools”

Traditional projects require team members to follow certain steps and have items approved before development is started. This is not a bad thing – going through quality gates and protocols helps to stabilise the process. Tools are necessary for ensuring that the team is assisted in their development needs, such as version control, code compilation, and deployment.

In the context of testing, following the standard steps of filing a bug report in an application management tool helps all the testers in a team have a shared process for managing bugs. A typical procedure may be as follows: take screenshots, supply the reproducible steps, identify the severity, upload the ticket, report to team. However, there will be instances where this process may not work for the testers. For example, they might find that taking screenshots for each bug might not be necessary anymore. Part of being Agile is discussing matters like this with one another to find what will work for the team. The Sprint Retrospective is an excellent time to bring up a process, such as bug reporting, and amend it to be more efficient for the team.

Agile encourages the members in the team to be as collocated or, at the very least, closely connected as possible. With collocation, one could simply walk over and demonstrate a problem. However, for distributed Agile teams, collaboration will pose a bigger challenge, since they are not in the same place. They will need to find the best way to collaborate with one another and decide if they will need messaging apps, video conference tools, and screen sharing applications.

Valuing “individuals and interactions” over “processes and tools” does not mean that processes and tools are no longer needed. It just means that processes and tools should match a team’s needs – and not the other way around.

“Working software over comprehensive documentation”

Project charters, software requirements specifications, user manuals, and test analysis reports are just some of the types of documents required in the different phases of a traditional project. These are needed to comply with standards as well as to serve as thorough guides for users and project teams who will take over the maintenance of the system. However, large upfront specifications may also end up detailing features that might not be brought to development later on, wasting time and effort.

Agile focuses on building the product right over specifying how it would be exactly made. For testers, this means focusing more on actually testing the product and exploring various scenarios, rather than spending time to detail test cases. This does not mean that Agile foregoes documentation altogether. Instead, it keeps it to a bare minimum and encourages Agile teams to have “just enough” documentation for them to work with. For example, writing down user stories in the backlog and listing the acceptance criteria is a form of documentation, and these will guide the teams into developing the product increment for the Sprint.

The key here for testers is to find a good balance between testing and documenting, and they need to explore techniques that will work for them to achieve that. Some testers can opt for checklists, while some can use one-liner test scenarios that are easy to understand by everyone. Some even hold bug bashes and testing workshops with the team and select customers, to be able to have as much coverage as possible.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum: