There was a piece of feedback from a testing conference: "There's all these great ideas about testing in agile. We still live in the world of waterfall. Is there nothing other for us in testing than to move to agile?"
It's been a while since I've used my time to actively think about waterfall projects, other than for the fact that I feel so blessed not to work on those anymore. I wanted to write this post thinking of the colleagues fortunate in different ways than I am, with the ideas of what is there for you on the current themes of testing.
1. Testing is testing, agile is a context
This phrase was going around some years back, and it's never been more true. Testing, as in looking at a product with most recent changes available to use and find information on, is very much the same with agile.
Agile as a context suggests some ideas that work just as well in waterfall environment:
It's been a while since I've used my time to actively think about waterfall projects, other than for the fact that I feel so blessed not to work on those anymore. I wanted to write this post thinking of the colleagues fortunate in different ways than I am, with the ideas of what is there for you on the current themes of testing.
1. Testing is testing, agile is a context
This phrase was going around some years back, and it's never been more true. Testing, as in looking at a product with most recent changes available to use and find information on, is very much the same with agile.
Agile as a context suggests some ideas that work just as well in waterfall environment:
- If we shared the ideas of what and how we're testing, we'd get more done and better - think testing over testers
- If someone is a specialist in testing, they will have a chance of bringing in diversity of viewpoints (testers and programmers focus their thinking differently!) and find problems the non-specialists struggle with. It's not magic, it's time and focus combined with continuously improving skills.
- A professional, self-organized team that works on learning does better in delivering.
In waterfall, it's still a day after the other. Every day is a chance of learning. The feedback cycles are different (slower, requiring different effort) but none of that stops you.
2. A lot of it starts with understanding value
In the world of waterfall, we used to talk a lot about requirements. But they are really our interpretations of what would be of value.
Why would anyone want to use your product? What are the core functionalities? What are the core risks, with regards to quality? What do you need to know and is it you who will be delivering that information?
You can work out the core risks just in time. For some of them, the right time is to talk about your concerns before implementation. For others, the right time is to talk about them sneakily while implementation is ongoing, without overloading the stressed developers. And for others, the right time is to find the problems before production, in whatever testing phases you have scheduled.
3. Buffer and protect the timeframe
With waterfall, people will still end up using the testing phases (that are really fixing phases!) as buffer. You need to make room for enough rounds of testing to happen, for this to not ruin all your plans and commitments on testing. And whatever time you have available, the best you can do is to find bad bugs early. Bad bugs will buy you more time. Bad bugs will need the time to get fixed.
But be careful. In protecting the timeframe, you might have to make choices of how you do that best. You might use your time on talking with people, when actually a better strategy could be to just test some more. Empirical evidence trumps the speculation.
4. Types of testing and tools
The new and cool stuff applies to you just as much as your more agile counterparts. Need more hands on (shallow) testing? Consider crowdsourcing. Need a tool to help out automating with a specific technology? Follow what new comes in and try not to drown in the overflow of options.
Do you still write test cases? Have you already considered moving towards session-based test management or some lighter-weight exploratory testing management frame? Or making your test cases, if you must have them, at least some of them, into BDD/SBE-style automation of executable specifications?
You know, it's not that different after all. Other than the waiting. The powerlessness of introducing change without added politics. The inherent blaming of missing things because you're asked to do things at times you knew the least.
In waterfall projects, your bug reports are against a fixed deadline. Choose wisely and work to help in any way you can to make sure there's not too much options for you to choose from. The dynamics are different if you release once a year and if you release once a month.
