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...."

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.

Thanks for that comment, Kelly. I'm going to reference that as I spread a similar message in my organization.

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.

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.

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

I vote for independent thinkers :)<br><br>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.<br><br>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?

Hi Lisa,<br><br>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.<br><br>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.<br><br>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. <br><br>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.<br><br>Rob..

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

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