Testers keep telling me that testing is not just about breaking things. They also tell me that they are there to help the team think rather than just point out the dumb things they have done in the last sprint.
That’s probably all true. But I have been asked by someone to give them a mechanical set of steps to do when you are an agile tester. That way they have a starting point when they join an agile project.
So here are the 8 steps to follow:
1 – Find out what people think you are doing there
You can start with these ideas on what I think an agile tester is there for. But check them against what the crew think too.
2 – Facilitate a test strategy
The team should create a test strategy and it helps if someone coordinates this for them. But the test strategy does not need to be a big lengthy document. Here is what you can do:
Create a test strategy with the team
This strategy should be owned by the team but you can run with it if you want to. You should be able to find a wiki, confluence page, share drive etc to store things in.
You can also consult the wider organisation about what evidence they need that testing was done. This might involve an audited record of the experiments conducted or just a meeting with the support manager.
Some organisations may well be focused on “documentation produced in IT” rather than evidence of successful testing. You should resist this as much as possible but you should also find out if there is a valid need for your team to produce something for governance purposes.
With respect to governance, you are within your rights to both question the value of what is asked for AND to push back on the team to get more time to produce required artifacts at the expense of other work. If you need to produce documentation for the organisation then you need to be given time to do that.
3 – Get involved with elaborating stories
You should be involved in the planning and collaborating parts of the project. For example estimating, prioritising, grooming stories and so forth.
The product owner is generally thought to be the one elaborating and explaining stories, but they are often inexperienced at doing this. Testers, on the other hand do this all the time, even if it is after the developers created something.
So this is an area where a tester can give a lot of guidance. Of course a BA or a technical writer can do this too. The important point is that the tester should be involved and CAN facilitate this for the team if the BA is willing to let them pretend to be in the “BA union”
But just in case you are not sure what to say, here are some guidelines on how to do it:
Approaches to elaborating stories
4 – Tell people to automate everything
Automation is great but robots (and automated tests) are still fairly dumb. So someone has to think through what and how an automated test should test. Sit with a developer and act as the navigator while they build the logic into the robot.
If you can learn to build automated tests or get your own test data with SQL or twitter or something then also do this. You will find that one of the best, highest paid jobs in the future will be the automated testing guru. In fact when robots run the world it might be the only real job left.
But you should also spend some time testing what the automated tests will miss. Remember that if they are testing the same thing every day, then they are missing (not testing) the same things every day.
If you are not sure what to test for then here are some hints
What mistakes will people typically make, which the system won’t anticipate?
5 – Consider becoming a tool-smith
There are lots of tools out there for testing things and for tracking testing (for example Jira, Quality Centre, bugzilla). Consider picking up one of these tools and becoming the local guru.
Even if you don’t become a guru then you should find out what tool the team are using to track bugs and record tests. You should then use this and even potentially be the one who advises everyone else in its use.
But don’t get obsessed with recording defects. It is better if you can get people to fix defects than to record them.
Advanced tip – if the team is a bit dodgy and won’t fix defects then consider putting them into a “known issues” or “release notes” document rather than a database of bugs. So hire an intern or a grad and get them to document “knowledge articles” to hand over.
6 – Go to some meetings
You should be invited to the planning meetings and you should be invited to the showcase and the retrospective. You should also be in a stand-up and you should be invited whenever there are muffins, cheesecake or coffees on offer.
7 – Do a lot of testing coordinate others doing it
The bulk of the time on an agile project, the tester is testing things. Hopefully you can also coordinate others doing it too.
But you won’t have time to prepare and you wont have decent requirements documents to test against.
People will want you to test the stories as they are built. But in fact as the project evolves you want them to test their own stories while you then focus on regression testing. So in the first sprint you will be trying to work out what is going on. Then in sprints 2-5 you will be doing lots of new stories, but by the end of sprint 5 you will probably be 60% testing that things are not broken in areas nobody else thought to test.
So you want to help others understand what stories are (elaborating stories) and then help them learn how to test their own work. Then you will be doing lots of regression testing.
This is what I mean by regression testing
But you have to start at ground zero (ie there is nothing to regression test, nobody knows what to do and there is no requirements document).
In fact in an immature team, people might not even have their act together in the first sprint to give you a finished story to test. And even after a couple of sprints they will potentially spend half the sprint building things before they give you anything.
So just follow these day by day guides:
Do this on day three until the end of the sprint
If you prefer you can slow down and repeat days one or two.
8 – Use the showcase and the retrospective
There are lots of books on doing good testing. There are also good approaches to reporting. But the agile process is supposed to help too.
People will often record the velocity without reporting the changes in defects. This causes them to start thinking they have to go faster by not fixing bugs. So fight to have the current defect number or trend reported next the the velocity anywhere you see it.
People will also be tempted to only demo working software in the showcase. This sounds reasonable but it is meant to mean “demonstrate whether the software works”. It is not mean to mean “hide the bits that don’t work”. So teams will often start to show the front end working when the back end is not, or they will carefully craft a demo to avoid the terrible bug they haven’t yet fixed.
But the showcase is there to help the team and the stakeholders understand the real status of how the product is working. It is more another testing session than a sales demo. So your job is to remind the team that they should be honest about the areas that don’t work so the stakeholders and the team can make better decisions about what to do in the next sprint.
Similarly, people often spend a week and a half developing in the sprint and then a few days panicking and testing. Raise this in the retrospective to force people to realise that they can be more effective if they are both building and testing all sprint.
This means breaking things down more and stopping to check more often. Unfortunately people will feel like they are slowing down when they do this. But it is better to be sure of your footing when you want to run – most people know it is hard to run in the dark on rough slippery ground. You just need to remind them. Put up pictures of the hare and the tortoise and things like that. Be a real pain on this point.
If people are really resistant then try to elaborate stories and do regression testing in the first week of the sprint. Then focus the second week on “first-past testing”. But make sure you always leave 1 or more stories untested at the end of the sprint so it can’t be included in velocity. Also make sure that you keep finding things the following sprint. You probably think I am joking on this point, but you will learn that people frequently start feeling rushed and panicked and then don’t have time to slow down and make sure they are doing good work.
But in agile the processes and the tools are supposed to support the people and their interaction. The people are not meant to become a bunch of tools to make the velocity chart look good or the showcase (demo) run successfully in spite of the fact the product could never work in the real world.
That is about it really. You can make your own rules up when you get your momentum and change anything. But for now just try these steps and you should be good to go.
James King 
2 thoughts on “A mechanical guide to testing on agile projects”