Independent Testers? Or Independent Thinkers?

Summary:

In this article, Lisa Crispin recalls a time when testers alone were solely responsible for software quality, and compares that to more modern thinking where collaboration between developers and testers is king. Software quality is everyone's job, sometimes it takes independence to get there.

Some leaders in the testing industry continue to maintain that test teams are "gatekeepers," the watchguards for quality. This makes me sad. I've spent many years now in development organizations where everyone-programmers, architects, DBAs, system administrators, analysts, customers as well as testers-takes responsibility for quality. These teams have delivered software whose quality is many levels of magnitude beyond teams where the testers were the quality gatekeepers.

One argument I hear from people who advocate separate, "independent" test teams is that testers who work together with developers (especially those who report to the same manager as the programmers) are vulnerable to a programmer suggesting that their "minor" change ("It was just one line of code") doesn't warrant any testing. This implies that the programmers don't care if they introduce defects into the software.

Crummy programmers influencing gullible testers isn't an issue to be solved by separating them into different, siloed teams. What we need to do is: 1) hire people who care about doing a good job, and 2) give them the time and training they need to do a good job. It's not an organizational issue, it's a management issue.

All the good testers I know are independent thinkers. If a programmer tells them, "I only changed one line of code, you don't need to test anything," they'll analyze the situation and decide for themselves what testing is warranted. If there's a time crunch, they'll provide the customer with information about the risk of not doing all the testing they think is needed, and let the customer make the decision.

My independent streak doesn't change when I report to the development manager instead of to the QA manager. There was a time when I was proud to be the "Quality Boss" and hold the keys to production. Back when I did that, the quality of the software we released was average at best, and our product wasn't competitive. Seeing the results of the "whole team" approach to quality has convinced me that more collaboration and communication, not less, is the way to go.

Don't worry about whether your test team is separate or not. If you're a tester, get up now and go start talking to the programmers. See how you can help them. See how they can help you. If you're a manager, start hiring the best people you possibly can, and start training the people you have to care about quality and learn how to deliver high-quality software.

User Comments

19 comments

Making it somebody else's problem doesn't solve it. Kinda wish I could forward this to every company where I've worked previously.

My boss told me I had been appointed the 'gatekeeper of quality' in my last job. Developers hated dealing with me, I hated reviewing their code. Good post. We need more thinking like this in the industry.

Hi Lisa, I love your writings about QA, any more blogs? I will definitely re-post this!

Rabby, I have a blog on my website, lisacrispin.com, also some articles posted there, hope you find them helpful.

Hi Lisa, Really great article. This is why I thoroughly enjoyed the move from traditional methodologies to agile because agile placed the emphasis on quality on the whole team and not just the tester. This isn't to say team quality is not suitable for traditional, because it is, but the long dev cycle and then drop to test at the end doesn't encourage team quality at its core. It works so much better when the whole team have quality buy in. It also frees up the tester somewhat to perform more testing rather than firefighting niggly 'shouldn't be present' defects. Like you say, a good software tester is capable of making their own mind up and still offering the same critical thinking no matter who they report to. I'm actually a huge advocate of collaboration and communication being the most successful factors for delivering great products. Get the right team, with the right team motivation and quality goal with willingness and ability to communicate and it doesn't matter what methodology they work in - they will succeed. Rob..

Hi All, Nice writing,i.ve also faced that developer always think wrong about testers. byeee

I vote for independent thinkers :) I think the problem is that even if people move to a more agile process, they continue to make decisions based on waterfall premises that simply no longer hold true. The only person who's "independent" validation really matters is the customer's... and even then, the more closely we can work with the customer the better we'll be able to understand what they need. So how does it make any sense that developers and testers will do better if they're working AGAINST one another then they'd do if they were able to collaborate, pool their skills & strengths, and work TOGETHER towards the same goal of building a quality product?

I'm encouraged to see that there are a lot of you out there who think along the same lines. We can transform software testing, and get better software products out there!

Thanks for the article Lisa!
My comment is a question to you. Looking back to my experience in IT career path I can see somewhat more beneficial having solid QA department rather than testers spread around development teams, especially in a big company. Even a _ mature _ QA professional who is feeling comfortable working independently would benefit from working in collaboration with other testers on a big product, for example, sharing business-specific knowledge, configuration tricks, and fresh workarounds. As for a junior person, the supportive influence of senior testers could be crucial! And it's not only technical or methodology coaching but more motivation and communication methodology.

So don't you think that spreading testers around development teams and making them reporting to different managers isolates them with the all consequent impacts, like cross-training, coaching and knowledge transfer problems, and lack of standards in test documentation?
Thanks

Albert, you make an excellent point. I've talked to a lot of people who work on large organizations that transitioned to agile and have testers integrated into the dev teams. What seems to work best is to have a QA/Test "Practice Manager"; who provides leadership and support to the testing community, gets them the training they need, gets them together to share ideas and practices. That way you get the benefits of testers and developers (and other dev team members) collaborating, as well as testers expanding their professional skills by working with other testers - skills they can pass along to their developer teams.

We don't have this at my company, so I have started an informal testing community. Different people volunteer to do testing-oriented presentations once or twice a month, and we have a testing wiki space where people can ask questions and share experiences. We'll see how well this works!

Also, due to the size of our products and the fact that there is still a lot of legacy code, we do have a team of testers dedicated to system testing, and we still have a "regression" sprint before each quarterly release. That's not ideal, but you have to do the accommodations that work, while continually looking for ways to improve upon them.

Lisa Crispin

Lisa Crispin is co-author of Agile Testing: A Practical Guide for Testers and Agile Teams and Extreme Testing and a contributor to Beautiful Testing. Lisa has worked as a tester on agile teams for the past ten years and enjoys sharing her experiences via writing, presenting, teaching, and participating in agile testing communities around the world. Visit www.lisacrispin.com.

You can also find me on Google+