The Agile Manifesto
  • Author:Tom du Pré
  • Comments:10

The Agile Manifesto & testing

I hear a lot of testers telling each other that the testing activities they are doing “aren’t Agile”. So what is Agile testing? Turns out it’s testing, that’s done in an Agile way! Who’d have thought!

Recently I’ve heard or read that manual testing isn’t agile, that test plans aren’t agile, that test management isn’t agile and that defect tracking tools aren’t agile. But if you ask, well then, what is Agile? you get the answer “Erm… automating everything!” So as long as we’re writing automated tests, we must be Agile, and Agile is good, so we’re doing good testing, right? Wrong. This is like saying that “All dogs have four legs, therefore everything that has four legs must be a dog.”

Let’s take a step back away from the self appointed Agile evangelists and look at the Agile Manifesto and see what it actually advises us about how we should be testing. Remember, while there is value in the items on the right, we value the items on the left more.

Individuals and interactions over processes and tools

Think of all the time you’ve spent over the last year discussing or complaining about whether you’re using Watir or Cucumber, Selenium or Fit, Bugzilla or Quality Centre. Do you think that time would have been more productively spent actually testing software, or spent talking with your team about ways of improving your testing? Tool choice is important, but discussions about it seem to go on for ever and generate almost religious levels of fervour. Remember that tools are a means, not an end and that they work for us. We don’t work for the tools.

Processes must work for us,
not against us

The methodologies endorsed by Scrum and Kanban and other Agile techniques are themselves processes, so Agile doesn’t mean no processes! Lots of organisations are hamstrung by their own bureaucracy, but a business without any process would quickly result in anarchy. We need the right amount of the right processes that help us do our jobs most effectively. Agile gives us the opportunity to look at these processes and refine and optimise them to make our testing the best it can be. Let’s compare two defect life-cycles: See if you can guess which one the Agile Manifest would endorse.

Defect Lifecycle A Defect Lifecycle B
  1. Tester finds a bug
  2. Tester spends half an hour filling in a defect report
  3. Tester assigns the defect report to a manager
  4. A day later, the manager prioritises the defect report and assigns to a development manager.
  5. A day later the development manager assigns the defect to a developer
  6. A day later the developer picks up the defect and fixes it in 5 minutes.
  7. The developer submits the code back to the tester
  8. The tester retests the defect, finds that it’s fixed and closes the defect report.
  1. Tester finds a bug
  2. Tester immediately walks over to the developer and shows him how to reproduce the defect.
  3. The developer fixes the defect in 5 minutes.
  4. The developer submits the code back to the tester
  5. The tester retests the defect, finds that it’s fixed

Working software over comprehensive documentation

This doesn’t mean no documentation! If you feel writing a test approach (for example) will be a helpful thing that people will read and use and discuss, then by all means write one. Consider trying to keep it to one side of a piece of paper though, rather than the 60 page template your PM keeps forwarding you. If no-one’s going to read your test approach, maybe write one anyway for your own benefit but do it on a post-it and stick on your monitor where you’ll see it. Writing a test approach or any document in itself is not an Agile or a non-Agile thing to do.

Writing a document that no-one will ever read is pointless in any methodology, including, but not specific to Agile.

If we value working software, then we must place great value on testing that software. If you don’t test it well you don’t know whether it’s working or not. So we can also say we value working tests over comprehensive test documentation. Having lots of manual test scripts that are sitting there not being run is not as valuable as having some automated tests scripts that are being run. It also tells that automated tests that aren’t being run, or aren’t reliable or useful aren’t as valuable as manual tests that are being usefully run.

Customer collaboration over contract negotiation

This is a very useful one for testers. We are often asked to “sign off” code. When someone asks us to sign something off they are asking us to sign a contract that makes testers and testers alone responsible for every aspect of that code being perfect and bug free, despite the fact that scarce time and resources prevent testing from being exhaustive. This forces us to caveat our sign offs heavily which makes us look like we’re trying to make excuses for our future failures. It’s an unpleasant situation to be put in, especially when no other skill sets in the scrum are required to sign such contracts.

Agile gives us a great opportunity to say hang on, it’s all of our responsibility to make sure this code release is good, not just the testers’. Sure, we’ll do our testing, but we need everyone else in the team, whether they be product owners, analysts, devs, sys admins, DBAs or UATers to share that responsibility and make sure they are delivering the highest quality work they can and prove that with their own tests. Everyone should have a shared understanding of and accountability for the quality of software and the risks throughout the project. If we do this, we can avoid the typical rubbish situation where testing activity gets squeezed and squeezed to the very end of the cycle, but testers are still expected to to be held accountable for the overall quality of the release.

So Agile testing is getting everyone else involved in testing. We can only do this by positively engaging with all the different people around us. Try getting out of your bull-pen every now and again and spend some time with the product owners and stakeholders and if you can, the actual users and customers. I guarantee that what you can learn from them over the course of a lunch break will be more useful than yet another lunchtime moaning session with your fellow testers and devs about how out of touch the business are. Be pro-active and reach out!

Responding to change over following a plan

This doesn’t mean no planning! Yes it’s ok to write a test plan if it will be useful. Sometimes it might be a really good idea. Again, just make a sensible decision whether to do it on a post-it, whiteboard or sixty four page document. If you have a plan, even if it’s just in your head, you can consider the consequence of changes and adjust your plan. If you have no plan at all, you’re just winging it and you will be taken advantage of.

Responding to change also means to expect it and be prepared for it. So don’t go hard coding things into your test cases that will change every month!

If you want to be able to respond to change, you need to make sure your tech-debt doesn’t build up. Tech-debt, (or test-debt in this case) is all the work you need to do at some point to un-cut all the corners you have previously cut. It’s all the tests you never got round to automating before you moved on to a different project. These are the things that slow us down and make it hard for us to respond positively or even embrace change. So don’t allow them to build up in the first place. The rate of interest you pay on tech debt is enormously high. Remember the old proverb “a stitch in time saves nine?” That’s your grandmother teaching you about tech-debt.

So to conclude, don’t throw away everything you’ve learnt about how to test just because you’re working in an Agile environment. Remember that Agile is just something that some guys made up. Agile doesn’t give people who know less about testing than you any authority to tell you that your hard won bug hunting skills no longer have a value. Embrace the flexibility Agile gives you to spend your day working collaboratively with all sorts of people on the things that contribute most to a good product.
