What is an expert tester?
When some people talk about “expert testers” they often refer to the personal traits such as curiosity, passion, dynamic, detail oriented, strong constitution, honesty, integrity, etc. We can describe the characteristics of these traits that we admire and we certainly look for when hiring new testers. People can strive to emulate the characteristics of these traits, but it is virtually impossible to teach someone to be passionate or curious. So, are there skills and knowledge we can teach to increase expertise and enable people to become more effecttive and more efficient in a increasinly complex world?
There are people on our teams whom we respect because they seem to have a knack for testing. But, testing is not an art or a knack that you simply acquire during your journey down the road of life. The testers most respected by other testers and developers alike seem to consistently demonstrate tacit knowledge of the discipline. So, in order to better prepare all testers at Microsoft to excel in their roles I was interested in the tacit knowledge of our star performers that could then be converted into explicit knowledge (which is something that can be more easily learned). I am wrapping up a case study on this work, and I can already see that many conclusions map to an article Rob Foshay wrote regarding expertise and the types of knoweldge that are common in experts in various fields. The article summarized three types of knowledge; how things work, context knowledge, and ill-sturctured problem solving. I found it especially interesting how these categories mapped so well to the skills and knowledge of software testers in general.
How things work implies in-depth system knowledge. (This is not general systems thinking.) Forshay describes this as follows; “…the expert knows the parts of the system and how they interact, both when they work as intended, and when they don’t work as intended. Furthermore, the expert can predict or explain how the system is behaving, or how it will behave if he or she makes a change.” So, what are the parts of the system for testers? The system includes the domain or customer space, different supported hardware platforms, operating systems, interfaces between applications and the operating system and/or hardware, the application itself, algorithms in the application, and even the programming language used are all important parts of the system and provide valuable context for designing and developing tests.
Context knowledge is the understanding of “…the particular requirements and design problems of a particular type of system, and its users, and how various designs have worked in the past.” It is always important to identify clear goals and define a course of action to achieve those target goals rather than guess and simply try different stuff.
Software by nature is an ill-sturctured problem. An ill-structured problem has a known starting point, a general idea of where the project is going, but the solution may not be well understood, or there may be several equally acceptable alternative solutions, and of course, it could all change. Forshay discusses strategies for solving ill-structured problems. Star performers are extremely efficient at solving complex problems using general rules, heuristics, techniques, and experience. But, as Forshay states, “…don’t confuse these strategies with the content-free problem-solving strategies advocated in the 1960’s, and still sometimes taught today: research has shown that such general strategies are rarely used by experts.”