Crisp's Blog

I recently spoke at a conference for testers arranged by SAST (Swedish Association of Software Testers) on the topic of Agile software development. Over 150 testers turned up, breaking all previous records for that association! I’m glad to see that you testers are interested in this stuff!

Anyway, trying to figure out a good opening statement for this conference I found the following angle that I’m pretty happy with afterwards, in a smug sort of way :o)

Don’t remember exactly what I said, but it was something like this:

"Is there anybody here who works with test?"

(Most hands raised. Mock surprised look on my face. "Wow, that many?" Sorry, couldn’t resist)

"Well I have news for you. In a truly agile project there is no role called Tester. There is no team called Test Team. And there is no project phase called Testing"

(A few seconds pause to take in the deathly silence and the look of 150 worried faces)

"Why is this? Is testing not important in agile projects? Have we magically done away with the need for testing?"

"Certainly not. Quite the contrary. In agile projects, testing is considered to be far too important to be confined to a single role, a single team, or a single project phase. Having a role called Tester implies that others don’t need to test. In an agile project almost everyone tests. Having a project phase called Testing implies that testing isn’t in the other phases. In an agile project testing is done almost all the time."

"Now I bet you are thinking but programmers suck at testing! Are there any programmers here?"

(a couple of hands up)

"Are you lousy at testing?"

(He nods and giggles a bit. Sorry, couldn’t resist again.)

"Well, I wouldn’t say programmers are bad at testing. It’s just that they test in a different way. In agile projects they pair program, for one. Yes, contrary to what most people think, pair programming is a testing technique (why would anyone think pair programming is a programming technique? :o). It is code review in real-time, the most efficient way of testing. A bug found while writing code can usually be fixed in a few man-seconds. Compare this to the man-hours or man-days of time needed to fix bugs discovered later on in the project, when you have no idea which part of the code caused the bug."

"The customer tests as well. He tests by trying out the system early and often, giving feedback on things such as usability and business value. Product owners test by helping the team define acceptance test criteria. Developers test by writing automated test code. Code who’s only purpose is to verify the correctness of other code. Not only that, they write the test code first, before they write the code that is to be tested! This is known as TDD, or Test-Driven Development, a tool who’s value is almost impossible to overstate."

"And then, of course, there’s you – the one they used to call The Tester. You are no longer The Tester. You are a fully integrated team member, and will share all of its successes and failures. You will do whatever is most important to your project at any given time – whether it is related to test or not. Welcome in!"

"Testing is your expertise, but on an agile team all of your talents will come to use, even talents nobody knew you had. You might help ensure that requirements (called User Stories) are testable from the very beginning. You might pair-program with developers to help them write better test code. You might define acceptance criteria together with customers. You might serve coffee. You might code. You might set up test environments. And last, but not least, you will test, just like everybody else"

"Since the programmers have automated all the boring, repetetive tests, you are free to focus on the hard stuff. The stuff that is difficult to automate. Exploratory testing. Usability testing. Performance test scripts. Figuring out those tricky test cases that only a veteran like you could come up with. And when you find bugs, you will help developers write code to demonstrate the bug and ensure it never happens again. You will coach the developers, teach them to think about things like boundary value analysis and equivalence partitioning and model-based testing and whatever other tricks you have up your sleeve. Your job is not to find bugs, your job is to help the team prevent them! The team is your team."

"Agile teams are cross functional, they are made up of generalizing specialists. People who are experts at certain areas, but have basic knowledge of a whole bunch of other areas as well. A team of generalizing specialists is extremely fast at learning and adapting."

"If you are a generalizing specialist already, then I congratulate you. If not, I hope you like to learn!"

"All in all, this Agile stuff should be a Good Thing for you guys! Testing is no longer just an afterthought, it is a critical part of the project and everybody is involved with it all the time. Your expertise is finally being given the credit it deserves!".

Then I went on to talk about the history and principles of agile software development, and show how Scrum and XP works in practice. Here are the slides if you are interested.