Rethinking Software Testing Experts
I have seen a lot of writings and talks about either becoming a software testing expert or being one. What I see common with them is they all focused on testing skills (question, solve problems, heuristics, etc.). However, there are also for example managers who don’t test almost at all, but who are still considered as software testing experts. Generally, they have good storytelling skills and a background in testing.
These people can often answer questions about testing, but they might not be able to do the actual work. A little like consultants and PhD graduates in some jokes. They are considered experts in their domains, but they can’t actually do the job. So, how come they are still considered as experts?
Harry Collins and Robert Evans wrote a book called Rethinking Expertise
(http://www.amazon.com/Rethinking-Expertise-Harry-Collins/dp/0226113612). In this book, they talk about specialist tacit knowledge, which they split into contributory expertise and interactional expertise. (They also mention “no expertise”, but I’ll leave it for the reader to find details about that.) Now, this brings us to an interesting point where being a software testing expert would not necessarily anymore mean one needs to be very good at testing!
Contributory expertise is the kind where you are able to get the things done. For example, a dentist can fix your teeth and help another dentist out. In the same way, a software tester can generate test data for an application and assist another tester. In this case, the tester is contributing to the testing effort.
Let’s keep up with the dentist metaphor. Dentists usually have assistants, who sterilize the instruments and for example hold the suction device. These assistants get familiar with the terminology the dentist uses and they can explain the whole procedure to the customer. They know the tools and what they do. Actually, they become so good in talking about dentistry they could be confused with dental surgeons.
In the example above, the dental assistant is interacting with the dental surgeon so much they share a common terminology. Most likely, he knows a lot about the theory of dentistry. The exchanges with the specialist give him the interactional expertise of being a dentist. He can’t do the job, but he can discuss fluently about it.
Let’s move back to software testing. Imagine for example a manager who is interested to talk with a tester about the approaches and methods the tester uses. The manager will become familiar with terminology (of that tester) and for example tools from software testing. In case the manager is interested in doing a good job, there are good chances he has recurring one-on-one’s with the tester. The manager can become an expert of software testing, but he might not be able to carry out the tasks of a software tester.
A practical example could be an expert like this telling we should do some specific security tests, but he could not explain us how the tests are done. It’s not only about ubiquitous tacit knowledge, such as popular understanding; the person can have a rather deep understanding of the topic, but he is missing the ability to perform the testing. This has an interesting side effect. If you can’t see the person do testing, it’s impossible (or at least very difficult) to know which type of software testing expert he is.
It’s important to notice we need both kind of experts and one can be both types also. The distinction is useful to understand expertise better, but it should not be seen as criticism towards interactional expertise. And in case you have doubts if someone is a skilled tester, the context-driven software testing community has a lot of challenges to figure that out.
Do you have any comments?
https://www.testingcircus.com/rethinking-software-testing-experts/https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Expert_Testing_Circus.jpg?fit=259%2C194&ssl=1https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Expert_Testing_Circus.jpg?resize=150%2C150&ssl=1ArticlesTesting ExpertsI have seen a lot of writings and talks about either becoming a software testing expert or being one. What I see common with them is they all focused on testing skills (question, solve problems, heuristics, etc.). However, there are also for example managers who don’t test almost at...Jari LaaksoJari Laakso[email protected]AuthorJari Laakso is a software testing professional who constantly strives to become better. He likes to talk and write about software testing, which has enabled him to connect with hundreds and hundreds of testers all around the world. His pursuit of deeper understanding of testing requires, in his opinion, studying various sciences, including linguistics and semantics. Jari has spent about a decade in testing, out of which most on software side. Since 2007, he has worked in different managerial positions, but always tried to keep up with his hands-on testing skills. In addition to this, he is a proud father of one.Testing Circus
Love your post Jari, fascinating area you’re writing about.
I once recruited a “test manager” as my future boss who knew perfectly how to “talk the talk” but sure didn’t “walk the walk”. Had all the markers, words, and knew about all the right people in the interview and completely and utterly fooled me.
In the end he was a catastrophe for the testing department.
Thanks Kristoffer!
I could write about hiring and firing testers (or managers). Sounds like you would have a great story to share also!
I’ve noticed a huge range of skill in “experts”. You might be very shocked at how good some of the experts are if you pair with them. Personally, I’ve learned more from watching them work than listening to them in some cases. I don’t trust experts who aren’t currently doing work.