Testing -- especially on agile projects -- has been coming up a lot lately. Jenny and I have have spent a lot of time talking and writing about the basic ideas behind testing. So we were really excited when Abby Fichtner let us know about an upcoming workshop she's doing a 90 minute workshop at the Agile 2009 conference with Nate Oster that explores how developers and testers can work together to "create higher quality software that delights its users and is more enjoyable to work on."
Even better, we've sent Abby autographed copies of Beautiful Teams to give away! Abby will be doing the giveaway at her workshop.
It makes a lot of sense, because when we were putting Beautiful Teams together, we went out of our way to include essays by and do interviews with agile development thought leaders like James Grenning, Scott Ambler and Mike Cohn. So we're really happy to do our part to support Abby and the Agile 2009 conference. Unfortunately, neither Jenny nor I can make it this year (we wish we could go!). But if you're looking forward to it, another Beautiful Teams contributor, Johanna Rothman, has a podcast that gives a great preview of what's going on.
Take a look at what she'll be doing:
Where Does Developer Testing End and Tester Testing Begin?
This is a trick question, right? In agile, everyone works on the same items together, at the same time. Yet, the reality is we're not all interchangeable cogs. Developers and testers each bring their own, unique skills to the table. The key to effective agile is not minimizing our differences, but building upon the strengths each person brings to the team. Join us for this hands-on simulation and retrospective as developers and testers explore how agile teams build quality into their process, how each member contributes to that quality, and how we can avoid traditional testing pitfalls.
One thing I really like is that she's focusing on how testing is everyone's responsibility on an agile team. This is a really important idea, and I think that it extends to more than agile teams. This mirrors something we wrote in our first book:
Quality is everyone's responsibility. Some programmers look at QA as sort of a "quality dumping ground" where all quality tasks can be relegated. Study after study, book after book, and most importantly, practical experience show that this approach fails every time. Software testers just can't tack quality onto a product at the end of the project. Quality must be planned in from the beginning, and every project team member needs to do his or her part to make sure that the defects are caught.
-- Stellman & Greene, Applied Software Project Management, p192
I think it's useful to point out that we took a more process-agnostic approach in that book: our goal was to talk about both agile and traditional development. One of our basic assumptions is that there same ideas that help agile project teams deliver high-quality software don't stop working just because you apply them to a team that hasn't gone agile yet. I've yet to see that be disproved.
Also, I really like something that Mike Cohn said when we talked to him about testing and quality:
I believe there's a direct correlation between a team with a clear, elevating goal and a team that writes high-quality code, lots of tests, and such.
The way I always say it is teams that go well go fast. If you write a bunch of high-quality code, you're going to go fast because there's not a lot of bugs dragging you down.
The teams that I've worked with that have had this type of clear, elevating goal as motivation certainly went fast. So, I'm assuming that we can draw the analogy they also must have been writing high-quality code to be able to do that.
Mike drew a straight line between setting goals for the project and building better software. That's definitely a great lesson to learn.
You can read more of Andrew's posts at Building Better Software.