Talkie Walkie Trustie

Recently I read through the notes from Brett Pettichord's workshop on Homebrew Test Automation. It's a great overview of available test automation techniques, although it is old enough that he doesn't mention UIAutomation (the Longhorn replacement for MSAA), which has some nice features for UI testing.

What I noticed the most, though, was several comments regarding the vast gulf that often separates developers and testers. Eradicating this gap is one of my Prime Objectives.

You've likely heard all those "truths" about testing: Test is a holding pen where developers-to-be prove their worth. Test is keeping us from shipping. Test is just a bunch of people poking buttons. Testers can't code. Testers are worth less than developers. Bah!

Unfortunately many of these beliefs are based on truths. Not too long ago, many applications were in fact tested largely by scads of people following scripts that told them which bits of UI to poke in what order and what should result thereupon. You didn't need to be a programmer in order to do this and so coding abilities weren't considered when making hiring decisions.

Note that this is an artifact of the way teams were built. Most of the other stigmata around testing have similar origins. It didn't have to be that way then, and it doesn't have to be that way now. That more and more people are realizing this and improving the situation makes me no end of happy. Microsoft, I am sad to say, must be included in the "used to do things that way" camp; but I am most happy that it must also be included in the "making things better" set. We aren't perfect yet, but we are much better than we were five years ago and we are actively continuing to improve.

Even when both Deva and Test are staffed with equally smart and capable people, however, the distance between the two groups is often all too real. The key here - for both sides - is to realize that the adversarial relationship that often holds between the two teams is all wrong. Developers usually don't miss bugs intentionally but rather simply don't know all the techniques that we do for finding bugs. Testers usually don't hold bugs back until their developer is having a bad day and then hit them with everything they've got; testing is simply a non-deterministic task the outcome of which is somewhat unpredictable.

Good developers are embarassed when their tester finds a bug they missed. Test's job today is indeed to find all those bugs that developers put into their code, but we would much rather help our developers learn to catch those bugs themselves so that we can focus on harder and more complex problems like the weird things that tend to happen when Feature A and Feature B are put into proximity with each other.

Good testers don't castigate their developer for missing bugs (although some good natured ribbing is always in order <g/>) but rather help them identify why they missed the bugs and figure out ways to not miss them next time. Good developers don't view this as testers trying to tell them how to do their job but rather jump at the opportunity to learn how to do their job better.

The best way to remove that wall between Dev and Test is for both sides to actively tear it down. Have both teams use the same test harness. Show your developers how to use your test helpers and other infrastructure to write tests. Help your developers learn basic testing techniques. Help your developers identify test cases they need to cover before declaring the code is ready for you to test. Have your developers code review your checkins and ask to review their checkins. (If they balk at this latter, start by reviewing their checkins on your own and then go to them with questions: "I'm trying to understand this bit of code. Why did you choose to do it this way rather than that way?" Once you show that you can have a coherent and intelligent conversation about design and coding your devs will welcome another pair of eyes looking at their code.)

Every relationship is founded on trust - or the lack thereof - and this one is no different. Remember that you're not just fighting stereotypes about testers ("Testers can't code." "How hard can it be to find bugs?") but also about developers ("Developers write bugs into their code just to make my life miserable!" "How hard can it be to write bug-free software?"). The only way to disprove these stereotypes and strengthen this relationship is to build up that missing trust. This may not be an easy process but you will be directly rewarded for your efforts.

Oh, the best way to start? Just start talking with each other!

*** Comments, questions, feedback? Want a fun job on a great team? I need a tester! 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. Great coding skills required.

Comments (4)
  1. I’m not sure I agree with what the paper says. The author advocates using all kind of languages "that suits best the situations". In theory this is very nice and powerfull, scripting languages are nicer for certain situation, etc… The problem of this model is versioning and maintinability: what will happen in the future ?

    Imagine that you arrive in a project that used 5 different scripting languages and harnesses to test it’s product. You will have to learn/analyse/run/debug/maintain all the tests in 5 languages. Meaning you have to learn those, even if they are deprecated at that time. This definitely sucks.

  2. Mark Eichin says:

    So how *do* you find tester-developers? Certainly a job description that says "QA" seems to be an invitation for lots of resumes from script-followers. I want people who think repetetive tasks are what computers are for, not people, and that "poking at the interface" is exploration to help identify test automation to write.

  3. AdamU says:

    How do you find them? It’s not easy, but hiring never is. I talk to potential candidates about the strong technical challenges associated with the SDET position. I also frame the conversation on the differences between SDE and SDET (because it always comes up) in terms of problem spaces, breadth for SDET and depth for SDE.

  4. The Braidy Tester says:

    We find tester-developers in lots of places. See for the full skinny!

Comments are closed.

Skip to main content