Testing is not a phase
Every time someone talks about a testing “phase”, a little part of me dies. The worst example I saw recently was a post on an agile group asking “how many days should we allow for testing? If something takes 10 days for development, should we allow 10 days for testing? Or maybe 15?”.
I’m not going to pick on people or name names. Everyone starts from somewhere and makes mistakes. But really, we need to clear this stuff up for good. Testing is not a phase and everyone needs to understand that.
In Waterfall, testing IS a phase
In the bad old Waterfall days, testing was a big phase. Nobody did any testing until all of the development was done. Think about that for a moment: nobody tested ANYTHING until all the development was “finished”. There are of course two huge problems here:
- Why would you not do any testing until all the development was finished? Why not test something as soon as it makes sense to start testing it?
- How do we know when the development is “finished”? Isn’t it really finished once a bunch of testing has been done?
There were huge problems resulting from this phased-based approach: testers doing not much (besides writing big useless documents) until code was “ready for testing”, handovers and phase-gates creating dependencies, work getting tied up and blocked while waiting for everything to be signed off, late testing and “integration hell”, manual instead of automated testing, and a resultant lack of quality and integrity.
So Agile said that testing should not be a phase
So in the 1990s, agile software development came along with some clear answers to these questions.
- We should test as early as we can and as often as we can
- Development is not finished until all the development and testing is finished, because (here’s the clincher): testing is part of development.
Agile borrowed heavily from the ideas of Lean Manufacturing (which borrowed many ideas from D Edwards Deming). In Lean, quality is built into the system, not checked or tacked onto at the end. So agile software development sees testing as being a fundamental and integral part of development, not a quick “check” you do at the last minute.
Testing then stops being a phase, and becomes an activity occurring alongside and intertwined with development.
Test as early as possible
Agile encourages testing as early as possible. If you are doing some form of Test Driven Development (which you probably should be), then testing actually starts even before you start coding. That’s because TDD involves writing and running tests before the code to make the tests pass is written. So testing is one of the very first things you do, not one of the last.
Test as often as possible
Testing should be done very frequently, not once per sprint and definitely not once per release. If you are working in small batch sizes and making many small changes (which you should be), then you should be integrating often. Ideally once or more per day. And if you are integrating often, you will need to be testing often.
Continuous Integration involves making many small changes to a codebase, and for that to happen without risk of breaking things, you will need a lot of automated tests. And you will need to be running a lot of automated tests, very frequently. Unit tests take microseconds to run, so can and should be run hundreds or thousands of times per day. Integration and Acceptance tests are slower and more brittle so will be run less frequently, but should be still run at least once if not a few times per day.
Beware the mini-waterfall!
Some people, especially those new to agile and choosing Scrum, simply copy their big Waterfall phases and squash a mini version of it down into a sprint.
They go from this:
To this:
Don’t do this! This is plagued by the same mistakes of the Waterfall system. Testers would be sitting around waiting for all the stories to be ready for testing, instead of testing from the very beginning. Quality would be left until the last minute, instead of being built in from the very beginning.
Sprints don’t have “phases”
There are no phases inside a sprint. Each day, the team should be focused on doing whatever needs to be done to move small pieces of work through the system. Quality is a fundamental part and parcel of that process, and should never be thought of as a separate phase.
