Agile software development and the testing manifesto

Agile is one of the most popular methodologies applied in managing software development. Instead of the term representing a single way of working. There are instead several frameworks which all fit into the umbrella term that agile represents.

From Scrum, Kanban, and one of my favourites, Scrumban. Agile is well suited to modern-day software engineering in which the requirements and plans can constantly change. It is a methodology that can adapt to the projects ongoing needs. And not be rigid and stuck in the ways of only doing things a single way.

One of its main advantages over other methodologies like the traditional waterfall approach. Is that it minimizes risk advocating the use of using time-restricted iterations called sprints.

Each sprint lasts anywhere from one – four weeks and is essentially its own mini software development project. In which all the development activities occur. So the engineering of individual features, the testing activities, not to mention the documentation. Are all completed in isolated events throughout the project’s lifecycle.

The use of agile has many advantages. From teams being more organised, higher levels of collaboration. As well as increased customer satisfaction with the final product.

But that’s not all that agile offers us.

Agile is a mindset

One of the definitions of agile (according to DuckDuckGo), is “Mentally quick or alert.” Without being heavily tied to the requirements (which inevitably change as we get closer to release). The Agile Manifesto instead states that we should, instead of avoiding change, embrace it. After all, if a change is made in the middle of one sprint. It can be delivered in the next.

There are other principles in agile that promote more valuable interactions across teams, the idea that quality isn’t just a thing for testers to worry about. And that everyone has a stake in the software’s success.

Criticisms of Agile

That’s not to say agile is totally perfect. From the lack of understanding about the need for an agile process to the structural change required to enable project success. There are a few properties of agile which may seem to be deal-breakers from some. However, if you have a committed team and agile is applied in the right circumstances. Then I believe the advantages outweigh the disadvantages.

I found this quote on Wikipedia which apart from being humorous. Sums things up quite well and makes an illustrative comparison that we can all relate to:

The agile movement is in some ways a bit like a teenager: very self-conscious, checking constantly its appearance in a mirror, accepting few criticisms, only interested in being with its peers, rejecting en bloc all wisdom from the past, just because it is from the past, adopting fads and new jargon, at times cocky and arrogant. But I have no doubts that it will mature further, become more open to the outside world, more reflective, and therefore, more effective.

Wikipedia/Phillip Kruchten

How is testing different in an Agile project?

In order to help guide testers and their activities in an agile project over a more traditional project approach. Karen & Sam who run GrowingAgile, an agile coaching service who produce some great books and courses. Came out with the Agile testing manifesto which apart from being visually appealing. Describes the mindset that testers should be adopting to make agile projects a success.

Testing Manifesto

Let’s take an in-depth look at these five pillars and expand on the principles that they set out.

Testing throughout over testing at the end

Testing in an Agile project needs to be thought of as a phase which is integral to a quality software product. And not just something that is a todo item on a checklist.

Instead of thinking that testing is an activity. And it can not be done before development has fully completed. It is instead an activity that can be continually done through the sprint. Especially if you are doing TDD, BDD etc.

Preventing bugs over finding bugs

The goal for testers is not to directly find bugs (although that does happen as a by-product). But instead, the need to focus on preventing bugs from occurring in the first place.

This is done by:

  • Understanding the goal of the project.
  • Asking appropriate questions.
  • Realising the needs of a user.

Testers essentially need to put themselves in the role of the end-user. Perform research to understand what they need, and use that knowledge to guide their testing and bug prevention.

Testing understanding over checking functionality

Checking is an activity in testing software. But testing isn’t just limited to checking.

Also, anyone can check. Not everyone has the desire, willingness, or the skills to perform testing. Making things like testing for edge cases, testing our assumptions, and testing our understanding of the software through techniques like exploratory testing. Much more desirable over checking whether something still works.

Machines are great at doing those repeated checks. Agile testing encourages testers to use automated testing techniques to free-up their time to performing testing.

Build the best system over breaking the system

Testers do not break things.

I think I’m going to put that one a t-shirt as it’s one of the most common misconceptions that I hear.

We are all a team in an agile project. Therefore, we all need to be responsible for building a great product, together.

If something doesn’t work. It’s not that a tester broke it. It’s that it was delivered broken in the first instance. Testers are there to highlight the problem to the development team so that we both benefit.

Team responsibility for quality over testers responsibility

Looping back around to the collaborative nature of agile software development. Instead of relying on the testers being the gatekeepers of quality. Instead, we need to think of quality as a thing that the whole team is responsible for.

Software development, when thought of as the collective outputs of several teams combined. Does not always equate to a good end product for users.

Teams might be on different wavelengths, have different speeds of working or completing actions in different ways. Using methodologies like agile enables teams to complete the actions that are required for quality software solutions collaboratively, in the best interests of everyone and most efficiently and effectively.

Is your software development project utilising an agile methodology? Contact me today to add a tester to your team who understands the value of using agile the right way.

Posted by Kevin Tuck

Kevin Tuck is an ISTQB qualified software tester with nearly a decade of professional experience. Well versed in creating versatile and effective testing strategies. He offers a variety of collaborative software testing services. From managing your testing strategy, creating valuable automation assets, or serving as an additional resource.

2 Replies to “Agile software development and the testing manifesto”

  1. Nice article.


Leave a Reply