Agile Principle 9: Agile Testing Is Not For Dummies!

In agile development, testing is integrated throughout the lifecycle; testing the software continuously throughout its development.

Agile development does not have a separate test phase as such. Developers are much more heavily engaged in testing, writing automated repeatable unit tests to validate their code.

Apart from being geared towards better quality software, this is also important to support the principle of small, iterative, incremental releases.

With automated repeatable unit tests, testing can be done as part of the build, ensuring that all features are working correctly each time the build is produced. And builds should be regular, at least daily, so integration is done as you go too.

The purpose of these principles is to keep the software in releasable condition throughout the development, so it can be shipped whenever it’s appropriate.

The XP (Extreme Programming) agile methodology goes further still. XP recommends test driven development, writing tests before writing the software.

But testing shouldn’t only be done by developers throughout the development. There is still a very important role for professional testers, as we all know “developers can’t test for toffee!” :)

The role of a tester can change considerably in agile development, into a role more akin to quality assurance than purely testing. There are considerable advantages having testers involved from the outset.

This is compounded further by the lightweight approach to requirements in agile development, and the emphasis on conversation and collaboration to clarify requirements more than the traditional approach of specifications and documentation.

Although requirements can be clarified in some detail in agile development (as long as they are done just-in-time and not all up-front), it is quite possible for this to result in some ambiguity and/or some cases where not all team members have the same understanding of the requirements.

So what does this mean for an agile tester? A common concern from testers moving to an agile development approach – particularly from those moving from a much more formal environment – is that they don’t know precisely what they’re testing for. They don’t have a detailed spec to test against, so how can they possibly test it?

Even in a more traditional development environment, I always argued that testers could test that software meets a spec, and yet the product could still be poor quality, maybe because the requirement was poorly specified or because it was clearly written but just not a very good idea in the first place! A spec does not necessarily make the product good!

In agile development, there’s a belief that sometimes – maybe even often – these things are only really evident when the software can be seen running. By delivering small incremental releases and by measuring progress only by working software, the acid test is seeing the software and only then can you really judge for sure whether or not it’s good quality.

Agile testing therefore calls for more judgement from a tester, the application of more expertise about what’s good and what’s not, the ability to be more flexible and having the confidence to work more from your own knowledge of what good looks like. It’s certainly not just a case of following a test script, making sure the software does what it says in the spec.

And for these reasons, agile testing is not for dummies!


For further reading about agile principles, see 10 Key Principles of Agile Software Development.

10 Responses to “Agile Principle 9: Agile Testing Is Not For Dummies!”

  1. Piersj says:

    I came across this netcase on agile testing which might be of interest?

  2. Paul Littlebury says:

    Agile a good methodology, but hardly re-invents any testing rules. Testing should always be involved from the outset, any software development manual from 1980’s onwards will say that. Developers seem to have forgotten their own training.

    Modern software development happens in tighter more rapid cycles – its that simple. What is generally missed out from Agile, which is the the whole point – is involvement by the client, or the end-user is no such client exists. Making software quickly is not the focus of Agile, it’s retaining control and ensuring that what a client wants is what they get, and that changes can be made mid-stream with minimal impact.

    Have a look at, as it contains some good reality-checks for developers. Not Agile specific, but succinctly summarises to crisis in modern development. Development has become far too smug and self-congratulatory to the point of dictating to users what they want, instead of LISTENING.

  3. Steve Watson says:

    I must admit that after 18 years in a waterfall approach, it would be astruggle to change to an Agile approach. However I can see the benefits of throwing off the shackles that bind us as testers and starting to have more impact on what is produced.
    We have come a long way from throwing code at testers at the end of the dev cycle, and testers only being used to match results versus spec. I enjoy being involved in decision making, helping to shape how a product looks and works, and it makes it more of a collaborative effort, encouraging team building.
    You can use bits of Agile even in a waterfall project, by being proactive as a tester, challenging the spec (nicely!), making comments on design and usability etc.
    In some ways the thought of changing my whole approach to Agile scares me but in another way I’d love to give it a go!

  4. Anonymous says:

    I think the QA/risk mitigation aspect of testing becomes overstated as you use richer web frameworks with less custom code. For example, CI is clearly a necessity for developing reliable and secure banking systems in Java/C++, but for lightweight modular web development (e.g. customisation of typical web publishing apps) mandatory CI is a victory of process over end product. This is a clear case of the tail wagging the dog and violates the first principle of the agile manifesto. Over-adherence to process in the name of ‘agile’ can easily become a kind of techno-beaurocracy that should be seen to fly against the spirit of agile/lean.

    That’s not to say that developers shouldn’t use tests or automate them where convenient. The big value is in TDD _as a coding technique_ to keep developers focused on features (also helping achieve the 80/20), and dev assurance that encourages refactoring.

  5. Cheap Domain Names says:

    Brilliant stuff, man! What you have to say is really important and I am glad you took the time to share it. I hope that I can learn more about testing. According to me Software testing is provides an objective, self-sufficient view of the software to allow the business to value and understand the risks of software implementation. Thanks for sharing your opinion. I am yet to find anything as enlightening as this on the web.

  6. In Agile, I prefer the tester takes two roles, Tester and Business Analyst. The tester communicates with a product owner to get requirements, write the test cases, and present requirements to coders. The test cases should be finished before the coder implements, the coder can review and also use the test cases during the implementation time. The tester still report bugs and inform coders to fix them. The product owner will do UAT after the tester complete testing.
    How do you think?

  7. Steve Shields says:

    If we are incorporating Agile into Project/Programme IT delivery would you still advocate UAT as a necessary and very important final piece of the delivery jigsaw?

  8. Kelly Waters says:

    Hi Steve,

    I would advocate that UAT is something that’s completed for each and every piece of work (ideally user stories) as they are delivered throughout each iteration. I would also advocate one final UAT check before releasing the software into production, but the nature of that would be more generalised than the individual story UAT’s and would also be a lot shorter than a full UAT in one big block.


  9. Douglas Nickerson says:

    Does seem true small icrements in development keep the testing at the “ground” level. i do notice, however, the notion of , writing test cases b4 or ‘during’ development, pre-dates agile

Leave a Reply

What is 3 + 2 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”