Agile testing - finding the balance

One of the lessons I learned in my last product cycle is that you need the right test for the right task.  Profound, eh?  :)  Don't build a battleship when all you need is a speedboat.  I'll go a step further now and modify this to say "the right tester for the right task."

Related to this, I've been browsing Elisabeth Hendricks' blog lately, and she recently posted on a topic dear to my heart - how testers can be the most productive in a team where devs actually write unit tests.  Now, my team doesn't really practice true agile development, and I can't claim that I've ever worked on a team that does.  But I've seen enough of the basic principles put to work that I feel qualified to comment. 

For a team switching to an agile methodology from a more formal approach, both the dev and QA sides face challenges.  For devs, it might be growing a culture around unit testing.  For QA, one of the challenges is letting go of the unit tests.  As Elisabeth points out, QA's job isn't to implement the unit tests for the developers.  QA's job is to do all the other stuff that developers aren't equipped to do, including integration/system testing, end-to-end scenarios, performance, stress, load, scalability, localization/globalization, deployment, configuration, upgrade, etc. (you get the idea). 

Elisabeth describes how she divides her testing into technology facing and business facing activities (as inspired by Brian Marick).  In both phases, she's working closely with her development team to help them accomplish testing they can't do on their own.  Unit tests are great at finding a certain class of bugs.  But as a collegue of mine recently stated, even developers who write great unit tests aren't likely to think much beyond those unit tests when they're under heavy pressure to reach their milestones.  That's where a tester comes in.

Defining a clear line between what is a unit test and what isn't is the first step in maximizing QA's impact to a project.  This takes careful coordination with the development team and an understanding of the division of roles on both sides. 

Elisabeth hints at another challenge for agile teams - while developers using agile methodologies value testing, they may not value testers.  This leads to trouble for both the developer and the QA org.  Developers may not feel compelled to keep QA in the loop on upcoming design changes, features reaching completion, etc.  And testers can easily tell when developers aren't "bought in," leading to low morale, less incentive to provide great testing, etc.  Worse yet, this can lead to the dreaded "us vs. them" mentality between roles.  Yuck!

So what's a team to do?  Keeping the lines of communication open is the first step.  Make sure both roles have a clear understanding of the delineation of test ownership and have visibility into each others' goals, priorities, and progress.  In a broken model, developers code up the feature while testers independently build a test plan.  In the cooperative world, developers, testers, and designers/analysts/architects/PMs (whatever you want to call them) sit together through the spec phase as well as the test planning phase.  Then testers can go off and build their test infrastructure and perform extended testing as developers build their unit tests and then code their features. 

Will it work?  Check back in a few months and I'll let you know :)