DevelopsenseLogo

Questions from Listeners (1): Handling Inexperienced Testers

On April 19, 2010, I was interviewed by Gil Broza.  In preparation for that interview, we solicited questions from the listeners, and I promised to answer them either in the interview or in my blog.  Here’s the first one.

How to deal with un-experienced testers? is there a test approach that suits better for them?

Here’s what I’d do: I’d train them. I’d pair them up with more experienced testers (typically test leads or coaches). I’d start them with things that are relatively easy to test, gradually increasing the difficulty of the assignments and the responsibilities of the tester. I’d watch closely to make sure that the test leads and the novices were talking to each other a lot during testing sessions.  I’d debrief them both together and individually.  I’d have the novices read books, articles, and blog posts, and ask them for summary reviews, and then we’d talk about them. I’d give them experiential exercises, in in which they and other members of the team would try to solve a testing puzzle, and then we’d talk about it afterwards. I’d reward them for demonstrating increasing skill: participating in Weekend Testing sessions; writing blog posts or articles for internal or external consumption; building tools and contributing to our development group or to the wider community.

Some might object that this approach is time-consuming. It certainly consumes some time, but it’s the fastest way I know to develop skill, and it’s similar in a general way to the training approaches for doctors, pilots, and skilled trades: involve them in the work, supervise them closely, and make them increasingly responsible for increasingly challenging work.

Here’s what I wouldn’t do: I wouldn’t give them a script to follow unsupervised and then presume that they’re going to do or learn the work. Everything that we know about learning and about testing suggests that both will be highly limited with this hands-off approach.  My friend Joey McAllister recently tweeted “The Barista at this Target Starbucks didn’t know if a mocha came with a shot of espresso in it. And she was working alone.” Most of the products that we’re testing aren’t simple cups of mocha. People are likely to suffer loss or harm if we take the approach that someone took with this barista.

6 replies to “Questions from Listeners (1): Handling Inexperienced Testers”

  1. interesting post, I have to train a fresh resource in my team in near future, your post helped me a lot 🙂

    Glad to hear it. Let me know how it goes, and let me know if I can help.

    Reply
  2. I agree with your approach and I would also like ask a follow up question. As I see it there might be different kinds of inexperience when handling a new employee:

    1. Someone who already knows the technical domain but has never worked with testing (e.g. someone who switched job within the company)

    2. Someone who is an experienced tester but never has worked within that technical domain.

    Would your approach differ in any way for those different kinds of inexperience?

    In the overall sense, no, but in the specifics absolutely. The training, exercises, and pairing would be focused in the areas that are new to the employee. I’d try as much as possible to make explicit the similarities and links between the old domain and the new ones. I’d also try to reinforce the idea that the new recruit has much to offer the people who’ve been there for a while. A tech support person turned tester, for example, would tend to have very good product knowledge and ideas about user expectations. I’d point out to her that those are two important classes of oracles—heuristic principles or mechanisms by which we might recognize a problem in the product—and then I’d point to others, like consistency with comparable products, consistency within the product, consistency with standards, and so forth. She’d probably be really good at modelling operations coverage, so I’d focus on teaching ideas about structural, functional, and data-oriented coverage, and so forth.

    This relates to an idea that we teach in the Rapid Software Testing class, the idea of theelliptical team. It’s important to develop skill, but you don’t have to be great at everything. An excellent testing team is a set of diverse skills, knowledge, and temperaments in mutually supportive collaboration. People will always have preferences and strengths in various directions. Let’s embrace that and take advantage of it.

    Thanks for asking, Hannes.

    Reply
  3. Mike, [or do you prefer Michael?]

    Michael. Thank you for asking. 🙂

    I fully support your recommended approach, as that’s the approach I use and advocate for all roles. The essence is that Apprenticeships result in mindful demonstration of proficiency and adaptation in the chosen craft.

    One of the common complaints I’ve experienced, regarding the degree of focus you and I advocate for working with the less-experienced is that “this doesn’t scale.”

    Yeah. Have you ever noticed that airlines don’t say that? “We’d love to have really capable pilots, but it’s soooo expensive to train them that we’re going to hire UPS drivers instead. I mean, those skills are pretty close. Or hospitals: “It’s really difficult to train a good doctor, so we’re going to hire a bunch of butchers and guys who shell coconuts. Oh, and since we want the outcomes to be predictable, palm readers.”

    It seems that organizations want to scale up quickly, and then become frustrated when productivity and proficiency doesn’t grow relatively. I encourage organizations to scale at a rate that provides them the ability to have awareness and the ability to adapt the approach to maintain an acceptable degree of QUALITY. Don’t simply scale up to get bodies in seats.

    Cookbooks don’t always produce chefs.

    Nicely put. There’s a big difference between scaling up and blowing up.

    Reply
  4. I got a chance to work with newbies recently. I didn’t show them the test cases. They asked “Then, how to test?” I replied “use your brain and sapience.” Gave them some Heuristic. They are happily exploring and having fun. Now I am planning to show them the SBTM, so that will help them to focus on their mission

    –Dhanasekar S

    That’s great, Dhanasekar. People learn much more quickly and much more deeply when they’re allowed to explore and when they’re allowed to have fun. Keep in touch, and let me know how things go!

    Reply
  5. My team has taken the approach that Michael suggests with every new hire that comes on the team. It works well for us. I think it builds a sense of appreciation in the newcomer and the more senior people get a chance to learn at the same time.

    I deviate in one aspect. After doing the hands on style of coaching sometimes I purposely give them a script to follow. I want to see what they do with it…how do they react…what questions they ask…see how they feel about using that method.

    It is a useful gauge on how well the coaching has gone and opens up more opportunity for everyone to learn.

    Michael says: A bit of history here: Adam approached me several years ago after a TASSQ meeting, and one of the first things that he said to me was that he wanted to create a world-class test team at the startup where he was working. I was eager to help out, and I’d like to think that I did at various times along the way. I’ve taught Rapid Testing to most of Adam’s employees, for example, and I’ve held several coaching sessions with them. Several colleagues (Rob Sabourin, James Bach, Jerry Weinberg) have also worked extensively with Adam and his staff. Adam’s manager is also one of the sharpest I’ve ever encountered, and he certainly paved the bumpy roads and cleared many of the obstacles. But it was Adam and his people that did the heavy lifting in terms of building and maintaining the team. When the startup was acquired by a much larger multinational corporation a couple of years ago, the quality of the products, the excellence of the company’s testing, and the possibility of broadening Adam’s approach to the rest of the firm was cited as one of the big factors in the acquisition. Adam: you did it! And a big factor in your success, in my view, is that even when you’ve got something that seems to be working, you continue to test, in just the ways that you’ve described above.

    Reply

Leave a Comment