Show Me

Dave Liebreich posted some while back what I presume is a question he asks prospective employers:  "I've seen many organizations that treat the QA or test group as people who will do the 'menial' work that the programmers don't want to, or the people who can be blamed when things don't go right.  Please convince me that you don't treat your QA or test group as grunts or scapegoats."

Ah, yes:  Test, the final frontier for those who can't hack it as a developer.  Or a stepping stone on the way to a real job as a developer.  Or the people holding back the release of a perfectly good product.  Or the group insisting that time needs to be spent on piddly work like accessibility or security rather than the real work of coding new features.

Bah.

Here's how you can convince me:

Show me Test is an important member of your feature teams.  Show me Test is on those teams because you value our opinions and ideas, not just because you've heard that feature teams should have testers.

Show me that testing is an integral part of your product development process, not just tacked onto the end.  Show me that you test your specs.  Show me that your developers unit test their code.  Show me that breaking tests is as bad an offense as breaking the build.  Show me that your developers and PMs and everybody else wants to learn how to test better.

Show me that you've changed features to make them more testable.  Show me that you've dropped features because they weren't testable.  Show me you ship when the team agrees the quality bar has been met, not when you reach the ship date.

Show me that you make at least as much of an investment in your test infrastructure as you do in your product infrastructure.  Show me that test code is as important as production code.  Show me that Test is held to the same quality standard as Dev is.  Show me you don't cut your testers any slack just because "They're testers; what do you expect?"

Show me that Test's opinion counts.  Show me that you're willing to change the way you do things to embed quality more deeply into your product and processes.  Show me that your team gets testing so well that your testers spend their time advising and researching and working on the really gnarly scenarios rather than churning out test cases.  Or show me that you don't get testing but desperately want to learn.

Show me that test is a career path in and of itself, not just a stepping stone to somewhere else or a penalty box.  Show me what you are doing to grow your testers' skills in testing, design, programming, digging requirements out of users.  Show me what you are doing to retain and recruit expert testers.  Show me that expert developers are clamoring to join your Test team.

Show me that Test is just another part of the team, no more or less important than any other part.  Show me that you have a team where everybody talks to everybody else because they value each other's opinions, not just Developers and Testers and PMs and Designers and Admin Staff who happen to be colocated and working on the same project.

Basically, show me that you care, understand, and want to understand better.

(No, I'm not from Missouri.  But my mom is.  <g/>)

 

*** Comments, questions, feedback?  Have a "show me" to add?  Want a fun job on a great team that shows me all this every day?  Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com.  I need a tester and my team needs a data binding developer, program managers, and a product manager.  Great coding skills required for all positions.

Comments

• Anonymous
  August 19, 2004
  I work for a small (about a dozen people total) company that's a heck of a long way from that point - we have one person responsible for QA, and that person isn't a programmer at all (although she is very good at finding ways to make our code fail). Heck, we (the programmers) are lucky if we get specs at all, let alone test them (I don't even understand what it means to test a spec). We have no automated testing whatsoever. Features are tested only after work is done on them - no regression testing is done at all. Furthermore, I don't think anyone in our organization - from programmers to QA to management, has the faintest idea that there's a better way to do QA. The only reason I do is from scanning the test-related entries on blogs.msdn.com and seeing how far away we are.
  
  I guess what I'm getting at here is that I understand there's no way we can jump from where we are now to a point where we'd even be close to passing your "show me" tests, and it's even more certain that I can't produce such a change in the organization myself. I can't change management attitudes, I can't make new hires, I can't magically teach our QA person to program. But I was wondering if your experience led you to suggest any baby steps that I might be able to advocate to improve our QA process - a sort of "Test first steps for dummies" kind of thing. Any suggestions for people in situations like mine?
• Anonymous
  August 25, 2004
  See my post "Baby Steps" (http://blogs.msdn.com/micahel/archive/2004/08/25/220293.aspx) for some easy ways to get started.