Just finished reading a really interesting article on informit.com by Jonathan Kohl, a software testing professional, on his experiences working on several Scrum teams as a conventional tester: Conventional Testing on a Scrum Team  If you are considering using Scrum to manage an upcoming project, Kohl relates some interesting real-world results for testing across product “sprint goals” or release dates.

Kohl reviews his expectations and experiences across three Scrum projects of increasing complexity and competency, with the last staffed by “very experienced agile developers”.  The most interesting take-away is how Kohl describes his incremental approach to getting testing fully-integrated with development in a sprint iterative cycle.

In the beginning, he and his testers attended the brief, 15 minute daily stand-up meetings and made notes about the testing they expected to accomplish for the sprint goal, which they would do after the sprint was completed:

At the end of the first Sprint, we had working software that was ready to demo. As testers, we were part of the demo; we recorded both positive and negative feedback from stakeholders, and continued test planning with this information. Test planning was faster and easier with working software in front of us, rather than trying to visualize the software by using requirements documents.

While successful, there was a need to go further, to close the feedback loop between the testers and developers.  Eventually, by his third project he was fully integrated with the development team.  Instead of testing at the end of the sprint, testing would occur during the sprint, i.e. alongside development.  This is very cool:

Testing in this new way was enjoyable. I was testing on working software sooner and closely collaborating with developers to provide instant feedback on development work or to help with test idea generation. With developers, I was as likely to be working on test problems as design considerations, usability concerns, or tracking down bugs. To facilitate testing quickly, I developed scripts that automated parts of the application that I had already tested thoroughly. I could run these to get to an area in the application very quickly, and then take over and do exploratory testing manually.

This, to me, is agile in motion, and what separates it from the waterfall “assembly line” methodology that is so prevalent in the industry.  Scrum isn't easy, make no mistake.  But it is really hard to argue with the results it can provide by making teams more cross-functional, integrated and enabled to meet deliverable goals.