Agile testing: Importance of a testing strategy

As you know from our history we didn't have much (if any) systematic testing going on, when we decided to introduce Scrum back in 2009.

A history of no testing equates to several challenges:

• The system is (was) not very well tested
• The codebase and architecture is (was) not very testable (it hasn't been written to be tested)
• The developers are (were) not used to having to care much about "testing"

It was important for our success that the strategy was clear from the beginning, from a management perspective. Testing had to be made important, it needed to be lifted up from the bottom to the top of the priority list. And, as they say, the proof is in the pudding. From a management perspective such as strategy has to be backed up by the attitude of allowing quality assurance to take time.

Our aim from the beginning was the following:

• We should introduce the Tester role in the team and clearly define its responsibilities (certainly harder than it sounds, more on this topic later).
• We should immediately stop taking new shortcuts (i.e. stop increasing our Technical debt)
• Test early and test often. All functionality implemented during a sprint should be tested and, if needed, corrected during the same sprint; while still having a reasonably short sprint length (i.e. two weeks maximum)
• Every user story that we implemented and delivered in every sprint had to be tested
• Create a minimal set of test cases that we could start using to verify the fundamental functionality of the system
• Be pragmatic and realize that we can't go the entire distance in the first sprint. We had to accept that despite our intentions we wouldn't have a truly releaseable product increment after every iteration. There would be critical bugs that we wouldn't have time to fix, there would be too few test cases to cover all functionality, etc. But striving towards the goal was a great start, and it meant we got better and better with every sprint.

Since we wanted to include testing in every sprint (and each sprint was just 1-2 weeks long) we had to figure out a way to expand test coverage without spending unreasonable amounts of effort. The solution (of course) was to automate testing. More on that in coming articles... :-)