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.

–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!

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.

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.

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