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
Lisa, as a test manager for a large government project, that is as far from Agile as one could find, I can assure you that the concepts still apply. Part of the standard training provided to our team was how to think about software, and not just how to test. Being part of and talking to development teams (and requirements, design, documentation, CM) allows the test team to speak the same language and learn many details they would never learn by being remote. It is quite common for some to make quality a test issue. Quality is project issue, and only through a project solution can it be delivered. And as you correctly state, hiring quality staff is the first step on that path.
Chris, it's great to hear a success story like that, I hope it will inspire some readers to try the same!<br>-- Lisa
Excellent point, Lisa, and very well said! I work in a large medical device company that is governed by regulatory agencies such as the FDA, a world that puts a lot of (over)emphasis on the "independence" question. In fact, FDA guidance documents (which are interpretations of law, not actual law) discuss this very point, and this rather conservative industry seems to often take the guidance to the bad extremes that it seems you have seen. My organization, and I suspect others in my interest, have long thought that SW designers must be independent of or "separate" from SW testers - separate in thought, seperate in org-structure, separate in objectives, and sometimes even separate in schedule and location. In our 7-year-and-counting journey with Agile, we are breaking down these old beliefs, and in some parts of my organization we now speak of "Aligned Teams" that no longer talk of one another as being designer or tester, but as being team members with varying levels of expertise on various topics. While the "independence" question still causes heartburn for those who aren't part of this transition, for those who are, the independence question has become a non-issue. It is clearly a good thing to align designers and testers together, aligning on common goals and common schedules. A colleague summarized it as, "We are no less independent, what we are is less isolated". ,The vast majority of those who have done this in my world would not want to go back to the old ways of isolated indepedence. And if those of us in the cautious, safety-critical, regulated world can do it, anybody can do it.
Kelly, your teams have accomplished a wonderful transition! I love the term "aligned", and I love that "we are less isolated" quote. Truly inspiring especially in your industry! Thank you for posting this!
Thanks for that comment, Kelly. I'm going to reference that as I spread a similar message in my organization.
I was taken on by my present employer about 18 months ago as a tester. My previous background was a a VB developer and the only reference I had to scrum was on a ruby field. I learned during the interview that the company praticed 'Scrum'! So between interviews 1 & 2 I researched 'Scrum' and I liked what I found and though yes I could work with this. In practice it took me about 3 months to get my head around this new way of working. I am on a team of six, 5 programmers, 1 tester and we are all independent thinkers, but who work as a team. The penny dropped for me one day when I realised that we are a team and when a developer or the developers on my team have a problem it is also my problem. But how do I help when my techincal expertise is so sorely lacking behind my fellow team members. An example of how I can help is that I will go over to the struggling developer and ask him to explain the problem to me. He has maybe sat with the other developers and gone through the code line by line but still it is not resolved, but when they talk me through the problem because I am not as techincally adapt as they are, they tend to explain the problem at a higher level or I will ask questions at the higher level and in my experience this has lead them to see the problem in a new light, that in turn leads to new avenue's being explored and eventual solving of the problem. I am currently reading your book which lead me to this site.
Great post!! If we all think like this we can definitely change software testing. You're right about getting the best people to do the job. There are testers that don't like what they do and therefore end-up doing a crappy job.
Fantastic post! On the dev side of the world, I also encourage developers to involve the testers early in the project, even if it is one line of code to be changed. The mindset that a one line code change implies less testing is simply naive and shows we are thinking very narrowly of the impacts of the change. Getting the full team together to simply have a conversation about it goes a long way.
I would vote for "Independent thinkers". Way back when I entered the IT industry things looked to be exactly the same as we are proposing today. So are we going "back to the basics"?The idea of "independent testers" probably works well in a big organisation who claim to provide a common platform, a career path and knowledge on testing tools etc .. But what I have observed is that under the concept of "Independent testers" the organizations end up doing plain pure resourcing. Out of the resources which they provide some happen to be "Independent thinkers" ( you got to be lucky to have them in your project ). What I would encourage is that irrespective to whether you report to a development manager or the test manager, irrespective of whether you are independent testing team or work alongside with developers - letz not forget something very core to testing - "A analytical mindset, critical approach and a common goal...."
Pages