31 Days of Testing - Day 3: More Collaboration, Not Less

Updated: Index to all posts in this series is here! Also fixed some formatting problems.

So many problems in our software industry have poor communication at their root. The technology’s not the hardest part of our job, it’s getting clarity of expectations, dealing with roadblocks around effective understanding, and all the other human factors.

This isn’t news. We’ve known this for years. With that in mind, why would anyone think less collaboration between testers and other members of the team could ever be a recipe for a successful project?

In an earlier post the awesome Lisa Crispin said in a comment “I’d go further and say, testing is part of development, not a separate thing.”

I agree. Completely.

I firmly believe that we deliver the best possible product when testing is an integral part of the process, not a separate team, or some black hole of activity that comes after everything else is done. We want to deliver great software, and we want to deliver it rapidly to our customers with as little wasted time during that process.

Separate development and testing teams mean a lot of wasted effort around handoffs, and a tremendous amount of friction around the mechanics of that handoff. The old school mindset of “Build it and pitch it over the wall to QA” has to be avoided at all costs. Can you deliver great software that way? Possibly, but it’s at the cost of huge amounts of wasted time creating ponderous specs detailing every testing action in minutia. It’s at the cost of unnecessary, repeated cycles building software that’s handed off to QA only to be kicked back because there were misunderstandings about what was to be built, or what was to be tested.

I’ve seen this waste personally in environments I used to work in. I see this waste when I talk with folks in the community who still work in or around such environments. I see this waste when I talk with customers during demos, site visits, and training.

You can NOT convince me you can do a better job delivering the best possible software as quickly as possible at the lowest cost possible if you’re working with separate testing and development teams. Go ahead and try. I’ll plug my ears and yell “LA LA LA LA LA I CAN’T HEAR YOU!”

Without exception, the smoothest, fastest, best releases I’ve seen have been where testing is an integral part of the development process. There are no separate QA and dev teams. It’s one team—or at least as close to one team as possible.

Goals of Collaboration

Why do we care about good collaboration on our teams? It’s not a specious question, honest! Ask what the goals of your collaboration are. It’s a good exercise.

Here are some of the things I’ve learned over a few years in the workforce.

Build better stuff!

I care about building great software. I care about helping others build great software. Great software helps our clients solve real world problems and in some cases even save lives! In my previous job at Telligent I was part of a team that built software used by aid agencies rolling in to Haiti and other natural disaster sites. Our platform was helping those agencies coordinate emergency aid to help folks wiped out by earthquakes, tsunamis, etc. Wow.

Other testers help teams deliver software running medical devices. I’m a diabetic and my life is in the hands several times a day of the folks who built and tested the equipment I use to test my blood sugar and dispense the insulin I need. If either of those are off then I can drop in to a diabetic coma and die.

On a less dramatic scale, software we build and test helps move millions of people around the world through travel systems. Software we build and test enables my son to play Angry Birds during really boring long car rides.

The chance of creating wonderful systems is dramatically improved if we can boost our collaboration and increase effective communication among our team members. That may sound like marketing hyperbole, but it’s not.

Waste, in the Lean sense, happens when we spend too much time repeating work because goals weren’t clear. More collaboration, especially early in the game, lets our teams have a better understanding of what it is we’re trying to build, and how the testers are going to bash it around.

Less waste is a Good Thing.

Reduce handoffs

Along the same line, more collaboration can reduce waste incurred during handoffs. Every handoff incurs some waste since there’s context switching and ramping up involved. There’s increase in miscommunication. Contrast that with effective flow of work items through your chain with good discussion at all points.

Handoffs equal waste and opportunities for miscommunication. Reduce those handoffs as much as possible.

Reduce stress

Great collaboration and communication reduce stress, pure and simple. Less miscommunication, greater clarity of purpose. Smooth running teams have less stress, and if that’s not a great goal then I don’t know what is.

Developers and testers learn more about their domains

Improving your teams’ skills ought to be one of your prime goals. More collaboration means your developers start to pick up on more on handling things testers will be bashing up. Your testers learn more about how the system’s actually working. All this knowledge transfer is a beautiful thing.

What to Collaborate On?

If you weren’t already a believer, hopefully I’m swaying you to my view that more collaboration is better. So now what do we start to collaborate on as we move to a more integrated team? This list could be really huge, but I’m focusing on two items.

Acceptance criteria!

Target number one: Get your PMs/stakeholders, developers, and testers sitting down at the same table (virtual or otherwise) and get them discussing what great acceptance criteria are for each work item. Do this as early in the cycle as possible. The acceptance criteria shouldn’t be a huge dramatic spec, but your team does need to figure out what works for them. I always try to keep to the metaphor of bullets on a 3”x5” card, regardless of whether we’re using TFS, Unfuddle, or some other system.

Testabilty

Target number two for close collaboration: Testability of the system. Lots of conversations can help ensure the UI is being appropriately built to help support automation through functional tests. Lots of element IDs at appropriate spots, less convoluted DOM structures, less “clever” but messy Javascript that can potentially cause problems.

Close collaboration at this area can also help with developers starting to build up supporting frameworks for automation – service layers to help do basic CRUD operations to help set up prerequisites for tests, for examples.

Evolve a process and environment that promotes collaboration

Work hard to get your team collaborating, and build an environment that empowers them to do so.

Get your team as close together as possible, physically in the same room as possible. Look to creative ways to bring virtual members as close together. (Lisa Crispin’s team has one remote worker. They use a rolling desk with a monitor, speakers, microphone, and webcam to get that worker involved in nearly every aspect of their team’s work.) If you aren’t already, get your team using daily standups to help boost communication between your entire team. Get retrospectives going so everyone can help tweak things to create a better process and environments.

By all means, get your developers and testers pairing on a regular basis. The pairing doesn’t need (necessarily) to be all day every day, but it needs to be frequent and regular. That’s where you’ll find the best gains in how your developers are looking at the system they’re building, and how your testers see the overall system.

At the end of the day, the best single action you can do to boost collaboration is to stop referring to testing as a separate action. You don’t have a development team and a testing team. You have one team  that’s building great software to help your customers do great things.