dding QA to Scrum (one Company's view)

My current company has been running Scrum for a Development process but as this tends to be a wrapper for Development, at least in my view, its been tough to fit QA into this process.  We do have release iterations where there is a focus on making sure that the code is stable, and we focus specifically on testing and bug fixing, though we do tend to freeze late in the iteration so the final testing gets cut.  What's new about that?

So in trying to decide how we wanted to set up QA the thinking came that QA needs to be more in the Analysis camp and not so much in the Process camp.  This is kind of a switch, at least to those of us who have been squarely in the Process camp, as we have less documentation now to develop test cases and plan out mini-release cycles every Iteration; but is this really much of a change?  The way we are changing to is most of the Release Testing will get backloaded into the Release Iterations, with the preparation of Test Cases and Unit Testing being done ahead of time and increased during the iterations.

With each Iteration QA can analyze the new functionality being developed, discover the Test Cases needed as code is written, generate the Unit Tests necessary to fulfill the Test Cases; QA can pair up with the Developers to check their Unit Tests as well.  We tend to have two levels of Unit Tests, one which we do call Unit Tests that the Developers create and use to test their code and Black Box tests which QA creates and is one step up from the Unit Tests which can start to test the classes as a whole and start Path testing.  Did I mention we are doing a lot of Java and JUnit?  This allows both the Unit and Black Box tests to be run in our Nightly Test Suite, so we have continual coverage once we add a new test.  So we cover method and function testing at the low level, and the Functionality and Use/Test Cases at the high level, providing more coverage as the work progresses.

So if this is followed, we generate new cases each Iteration, adding to our Test Plans, which may or may not be run during pre-Release Iteration, and we increase our Automation.  Not much different really than being in the Process camp, except we are sticking with the Developers to find out what we need to do and test, rather than looking at documentation and understanding the Use and Business Cases.  If that Case information is needed we can get it from the Product Owner, or Product Director depending on your terminology, so the only change here is the information source, rather than written materials its going to be dynamic where we gather the data we need from the flows between the Developers and the rest of the Scrum Team.

Originally we thought this might be difficult, and a tough change, but when we spelled it out then its actually not much different than we do it now, its not the What that has changed but the How.  Of course none of this has been in practice for very long, so it will depend on how its handled over the coming Iterations, it would be interesting to see if it were not for the fact that I am leaving the company this month.