Most of my work is teaching, coaching, and evaluating testers. But as a humanist, I want to apply the Diversity Heuristic: our differences can make us a stronger team. That means I can’t pick one comfortable kind of tester and grade people against that template. On the other hand, I do see interesting patterns of skill and temperament among testers, and it seems reasonable to talk about those patterns in a broad sense. Even though snowflakes are unique, it’s also true that snowflakes are all alike.
So, I propose that there are at least seven different types of testers: administrative tester, technical tester, analytical tester, social tester, empathic tester, user, and developer. As I explain each type, I want you to understand this:
These types are patterns, not prisons. They are clusters of heuristics; or in some cases, roles. Your style or situation may fit more than one of these patterns.
- Administrative Tester. The administrative tester wants to move things along. Do the task, clear the obstacles, get to “done.” High level administrative testers want to be in the meetings, track the agreements, get the resources, update the dashboards. They are coordinators; managers. Low level administrative testers often enjoy the paperwork aspect of testing: checking off boxes on spreadsheets, etc. (I was a test manager for years and did a lot of administrative work.) Oh, and by “high level” I don’t necessarily mean “high ranking.” I mean someone who prefers to deal with the big picture of testing, but not so much the details of each test. “Low level” means focusing on each click and keystroke; each testing moment. Warning: Administrative testers can be tempted to “fake” the test process– to move things along at the expense of the quality of the work.
- Technical Tester. The technical tester builds tools, uses tools, and in general thinks in terms of code. They are great as advocates for testability because they speak the language of developers. The people called SDETs are technical testers. Google and Microsoft love technical testers. (As a programmer I have one foot in this pattern at all times.) Warning: Technical testers are often tempted not to test things that can’t easily be tested with the tools they have. And they often don’t study testing, as such, preferring to learn more about tools.
- Analytical Tester. The analytical tester loves models and typically enjoys mathematics (although not necessarily). Analytical testers create diagrams, matrices, and outlines. They read long specs. They gravitate to combination testing. (If I had to choose one category to be, I would have to say I am more analytical than anything else.) Warning: Analytical testers are prone to planning paralysis. They often dream of optimal test sets instead of good enough. If they can’t easily model it, they may ignore it.
- Social Tester. The social tester wants you! Social testers discover all the people who can help them and prefer working in teams to being alone. Social testers understand that other people often have already done the work that needs to be done, and that no one person needs to have the whole solution. A social tester knows that you don’t have to be a coder to test– but it sure helps to know one. A good social tester cultivates social capital: credibility and services to offer others. (I follow a lot of the social tester pattern. My brother, Jon, is the classic social tester.) Warning: Social testers can get lazy and seem like they are mooching off of other people’s hard work. Also, they can socialize too much, at the expense of the work.
- Empathic Tester. Empathic testers immerse themselves in the product. Their primary method is to empathize with the users. This is not quite the same as being a user expert, since there’s an important difference between being a tester who advocates for users and a user who happens to test. This is so different from my style that I have not recognized, nor respected, this pattern until recently. People with a non-technical background often adopt this pattern, and sometimes also the administrative or social tester pattern, too. Warning: Empathic testers typically have a difficult time putting into words what they do and how they do it.
- User Expert. Notice I did not say “user tester.” User experts may be called domain experts or subject matter experts. They do not see themselves as testers, but as potential users who are helping out in a testing role. An expert tester can make tremendous use of user experts. Warning: User experts, not having a tester identity, tend not to study or develop deep testing skills.
- Developer. Developers often test. They are ideally situated for unit testing, and they create testability in the products they design. A technical tester can benefit by spending time as a developer, and when a developer comes into testing, he is usually a technical tester. Warning: Developers, not having a tester identity, tend not to study or develop deep testing skills.
When I’m sizing up a tester during coaching. I find it useful to think in terms of these categories, so that I can more efficiently guess his strengths and weaknesses and be of service.
Do you think I have missed a category? Do you think I have de-composed them poorly? Make your case in the comments.
James, in your view what’s the benefit(s) of this categorization?
From your post, it seems like you get value of this when recruiting or forming a team.
Is there any value for the individual tester?
[James’ Reply: I use it in teaching and coaching. I use it when talking to testers. It has value in predicting tester behavior and responses. Just as knowing that you have a flu, and not just a set of symptoms, helps you predict what will happen next.]
Testers trying to find/fit themselves into the tags above mostly will be fitting themselves /out/ of the other tags.
[James’ Reply: Possibly. How is that a problem?]
I know you wrote “your situation may fit more than one”, but still, having a list of the rest of things I am not sounds more limiting than liberating.
[James’ Reply: The purpose of the model is not to liberate. You liberate yourself. The purpose of the model is help make sense of what’s happening and predict what will happen next.]
Do you see a danger or problem in creating/promoting this classification?
[James’ Reply: Of course. It’s a heuristic. Any heuristic may fail. Perhaps there is an alternative scheme of categorization that has more predictive power, and this heuristic will dissuade people from discovering it. Perhaps someone will think that the categories represent the fundamental nature of the tester and that they can’t explore one category because they are caught in another.
I don’t see much danger, here. It’s a speculative model that helps me, and I wanted to share it.]
I realized I fitted into at least four categories. I find it also that I am a “sophomore tester” in that I seek knowledge from many places. I gather books and articles and consume them like nutrition for my hunger of knowledge. That would be the “sophos”-part. I am also “moros”, which would mean in my case a bit of a fool. The stuff I learn and seek may not help me with my current work or assignment. So I slowly become a mountain of knowledge and lessen in practical skills. I would also consider myself a procrastinator professional. If my mind wonders, it wonders to places I never thought it would go – physics pages, philosophical, psychological forums, you name it. It may come in handy at some point, but not right now. A bookworm could also be a good word for what I do. If I could, I would just sit in the company library and read stuff about programming and testing all day long.
– Peksi
Nice post, James, thanks! As I’m mostly an analytical tester according to your categories, I think that we can create some criterias for tester groups. Like:
– Perspective (tester looks at the product from the developer’s point of view or from the user’s point of view)
– Technical background (does tester have it or no)
– Preferable test techniques (black box, gray box, white box)
– Communication (how tester communicates with other stakeholders)
– Identity (does tester think of himself as a tester)
– Preferable test activities (planning, testing, designing tests)
[James’ Reply: Spoken like an analytical tester– trying to tease out the variables! I agree that we might benefit from doing this. I’m not entirely confident about what I would say for about these for each type. I don’t want to be overly definitive, but there is quite a danger of that, when these systems grow. I would like to see what you have to say for each of these, though.]
Maybe using these criteria, we can determine the tester’s category quicker.
[James’ Reply: Maybe.]
Personally I have a habit to classify testers based on preferable test activity. That’s why I searched for some categories as Executor (who likes to test, even without designing tests) and Designer (who likes to create tests) in your list. But it seems to me that it is another dimension, which you intentionally didn’t mention.
[James’ Reply: I didn’t mention it because I think it doesn’t exist. If you don’t design tests, then I would say you are not a tester. And anyone following instructions *competently* IS designing the test, in an important sense. You can’t give someone instructions, have them ignorantly follow them, and call that testing. That’s what I would call “human checking.” However the closest I have to that is the administrative tester, who particularly enjoys the “get it done” part of testing, rather than the planning bits. The administrative tester designs tests, but will look for the simplest ways to do it, rather than setting clever traps for bugs, the way an analytical tester does, or writing a tool that scoops bugs up by steam shovel, the way a technical tester does.]
Empathic Tester – “People with a non-technical background often adopt this pattern, and sometimes also the administrative or social tester pattern, too.”
I think you just described me perfectly!
Hey..I think you have missed an all rounder… Kind of…a person who is no expert in any category as such but takes care of and does a little bit of everything.. What do you say…??
[James’ Reply: There can be no such person. Read the categories carefully. Some are mutually exclusive. The Developer type and User type do not see themselves as testers, but the others do. The empathic tester does not make formal models, but the analytical tester does.]
Does the above kind depends on the situation of the project/ task we get in… I guess am seeing it more as a role and one can change roles depending on the situation… Let me know …
[James’ Reply: To some extent it might. I certainly have been in the Developer pattern before, meaning that for some period of time on a project I wrote code and did not see myself as a tester. But in a bigger sense it makes no difference. Each tester can decide what skills to develop. For me, I prefer not to be in a developer role, and when I am in a tester role I don’t see myself as a user. I’m not comfortable with the empathic way because I need to be able to explain my work. That leaves me with the other four. Of those, the one I feel worst at is the one I did for years– administrative. These days I would rather work with people who are like that than to be one. I’m probably 50% analytical, 25% technical and 25% social. I can approach every project that way.]
James, what kind of tester are you?
[James’ Reply: Mostly analytical, with some social and some technical.]
Hi James. I’m having a hard time profiling a couple of great testers I know. I almost want to put a part of their style in the “empathic” bucket, but I’m not sure that’s quite right. You tell me.
They are incredibly good at learning a new piece of software. They deconstruct it quickly and are able to find “anti-patterns” and call them bugs. To a degree they recognize that the software is inconsistent with certain principles, though they may not have a formal set of inconsistency heuristics, e.g. HICCUPPS.
Do you see this type of tester fitting into one of your existing roles?
[James’ Reply: It’s hard to say from this description. You haven’t said anything about their technical habits or abilities, so there’s no particular evidence of technical. They aren’t developers. They don’t sound like administrative testers, and you haven’t mentioned anything social. That leaves empathic or analytical. Do they make lists and diagrams? Do they tend to talk more about how to do the work than actually doing it? If so they are more analytical.]
Not entirely, but at least partially related are the tester personas I wrote for Microsoft several years ago. These are (I guess) an expansion of the technical tester, as well as a testament to how the technical tester can overlap into a few of the other roles as you describe.
The original post is long-gone, but I did a quick cut-n-paste here: http://angryweasel.com/blog/?page_id=664
Interesting topic. Very useful to think about.
Just like when discussing different tester roles, I find the most interesting part to try to break down the different roles, or in this case tester types, into different attributes/skills/thought patterns/etc. to understand all the components that make up the different types/roles.
Once this is done you can create different categories based on what you want to visualize/explain/describe with those categories. So in different situations you can use different categories depending on what you want to communicate, but the underlying components are the same.
I wrote a presentation about it only regarding skills, but the same concept I think is valid for mindsets/thought patterns/etc. Nothing new or revolutionary, but it was good for me to formulate my thoughts.
http://www.slideshare.net/JohanHoberg/the-testing-skillset
Thank you for continuously providing interesting topics to think about.
/Johan
What about the fake tester who actually fakes testing many products for an entire generation and gets away with it? What about the “Well-Defined tester” who believes truly that “testing defintions maketh a person”? What about the “Certified Tester” who thinks he’s a testing expert because he cleared some tests? But on 2nd thoughts, I think I’ll write one on “7 different types of fake testers” 🙂 !!!
[James’ Reply: I don’t consider any of those to be testers, so that’s outside the scope of my post.]
For me, I’m having a tough time choosing between technical, analytical, social, and empathic.
[James’ Reply: You don’t have to choose. I know you are a technical tester. I’ve seen you do analytical and social things. So, you’re versatile.]
Plus one more – the instant gratification tester. I *will* find a bug, probably very quickly, but it might not be the most important bug.
[James’ Reply: If that’s the ongoing style of the tester, I suspect that’s empathic. Anyway, strictly speaking, I don’t see “instant gratification” as a type of tester. It doesn’t represent any form of thinking or particular heuristic.]
James Whittaker’s “How to Break…” books seem to cater to instant gratification.
[James’ Reply: Creating that requires an analytical style, but following it is more of an administrative style, to me.]
I belong to Social and Technical Tester Category 🙂
And trying to learn to be more than the present.
[James’ Reply: I’m an ambassador of analytical testing, if that’s something you want to work on.]
Do you have a metric for evaluation of these types? E.g. would you think that some would get paid more than others for their testing services?
[James’ Reply: I don’t know what a metric for evaluation is. But as to your second question, there’s plenty of work in Agile projects for developers and technical testers. Lots of users are being used for testing, and I suspect that will continue. As for anything else, I don’t have any strong impression one way or another.
Of course, any kind of tester who develops a special knowledge of a product or technology will have good job security in that role.
I can say this: if what you want is to make a lot of money as a tester, then you should cultivate a public reputation and become very good at testing. In general, you should also cultivate the skill of coding (it comes in very handy) and if you don’t want that skill then your best income path would be as a test manager or trainer.]
Don’t know…. I see why you did this but I am still struggling to accept a given definitive list of testing types. Maybe it’s just my abhorrence of ISTQB trying to pin a name on everything.
[James’ Reply: I try to pin a name of everything interesting– it’s how I can use words to help explore ideas. That’s not the problem. The problem would be if I tried to promote my idea as the one way that everyone thinks. Clearly it’s not, and I haven’t claimed that.
It’s the authoritarian, anti-intellectual, and downright lying ways of the ISTQB that appall us, not the general concept of using words.]
Oh well…here goes. I’d see myself as a Technical Tester and a bit of Empathic Tester.
[James’ Reply: I thought you were technical, too.]
@David: Perfect example of trying to bridge being stereotyped. Your work on learning development practices brings you closer to Technical Tester. Maybe an all-rounder doesn’t exist but your marketability and effectiveness in testing increases if you start to bridge several of these types.
Sorry for the unnecessarily academic jargon: to clarify ‘metric for evaluation’ translates to ‘way of measuring the value of’. Thanks for your answer. Your post describes well how you identify valuable contributors who may not have been recognised previously. There is always a danger of putting some skills on a pedestal at the expense of others …
These heuristic patterns are personal to you – and as such, it’s difficult to say if something is missing as they are in your frame – and I don’t have enough information about how (or based on what) you have framed them.
I’ve seen a model of your test coaching in the past, but it’s difficult for me to reconcile that to these patterns, which indicates there is probably a different frame (or several, or probably very many) that you’re using to construct these patterns.
[James’ Reply: My coaching model is completely orthogonal to these tester types.]
I think the construction of these patterns is useful from a coaching perspective – but unsure if useful in a different context. (And you probably can’t use them /well/ if you don’t study testing.)
[James’ Reply: It may help when you are comparing yourself to others. The appropriate choice of role model matters. I think, for instance, that there are people called testers who do not study testing or in any way feel like testers. So, maybe they are actually users-in-a-testing-role and shouldn’t be comparing themselves to, say, an analytical tester like me.]
If I would construct such heuristics for pattern recognition – and to share them – I’d probably leave out the “warning” words -> those examples are examples of patterns and so part of the heuristic. The warnings could be a note (appendix or extension) to the patterns, a type of implementation detail (note to the coach) rather than a part of the pattern recognition.
To extend on this commentary I need to construct my own pattern heuristics.
[James’ Reply: That’s a giveway– you’re an analytical tester.]
I normally find with most lists of patterns/types that I respond like Jaspreet – can’t I be a little bit of everything? But with this, the Analytical type jumps out at me as what I tend to gravitate towards. I can do Administrative (and do it well, but sometimes I feel like I’m missing out on all the fun), Social, and Technical (unlike Administrative, I do enjoy this very much), but I’m pretty sure of my main preference.
Which leads me to another thing: I’ve been a little frustrated in the past when working with people who I consider to be good testers, but who just don’t seem to love modelling or be able to explain their testing to me in the way I’d like them to, although they’re very clear on explaining the customer impact of the bugs they find. I’m now wondering whether my bias has caused me to misjudge them because I’ve mistaken their lack of interest in diagrams, matrices etc for a lack of genuine interest in studying testing. It’s possible that I’d now classify them as Empathic testers, but I’m not entirely sure from the description – I’d love to hear more about this type. I’d also be interested in hearing more about how you approach coaching Empathic testers as I suspect that I haven’t been terribly effective at this in the past.
[James’ Reply: My “discovery” of empathic testers as a category distinct from “incompetent testers” is the main thing that prompted me to write that post. I also think I have discriminated about empathic testers. And yes, of course you can be a little of everything… But perhaps not at the same time and in the same way.]
@Oliver: That’s the plan mate, and you know that well. 😉 Now, back to this language called Python…
Wow, when I glanced at the categories I thought I would end up being a technical tester but after reading the descriptions the one that I think most describes me is the empathic tester. Food for thought for me…
Hi James, to add to what Joe Harter said – I may fall into that category which doesn’t exist, yet.
I’d say a large amount is empathic but, and that’s a big one, they don’t necesarrily empathize with with the users but with the system. Meaning, drawing on their experience on how similar systems behaved in the past. The inconsistency heuristic is used against almost everything.
[James’ Reply: The inconsistency heuristic is universal, I think. We all use it, all the time. I may be wrong, but I haven’t seen a counterexample.]
Is a behaviour consistent with my experience of similar systems? Against itself? Where does it differ, where does it not. Ist that a problem or not? What does it mean in this context? Do I have enough information to make a judgement call, if not, who do I ask? (Social).
Depending on the technical implementation, what kind of bugs do I expect? I may know next to nothing about the domain and still be able to find bugs due to experience with technical similar systems, even though I can’t code (very well) and only use simple tools to help manual testing.
The idea here is to get the shape of the system. Identify which areas are important for the user/business/etc. then go into these areas, with a domain specialist if possible.
Admin tasks are minimal, just enough to write a few things down and see if something inconsistent was written down prompting more tests. After writing a sentence the questions pops up “Is it really true? How can I be sure that it’s true?” which guides further testing.
I reckon that depending on the project people tend to shift from one test type to another, depending on what’s needed but it’s a nice summary reminding me not to let the other aspects slip. Thanks
[James’ Reply: Possibly, but I tend to doubt it. I think these are coping patterns that stay pretty consistent. If you are comfortable with formal models, you WILL use them. If you are not, then you won’t. If you are comfortable with coding, then you will make tools. If you have a strong need to “get it done” then you will define testing so as to make an efficient process for getting done (admin).]
James, there is a very prevalent hybrid role that I have encountered time and again in my career and that is the Technical/Empathetic. This person usually has a very technical background, but may not spend a lot of time creating tools/code. They definitely immerse themselves in the product AND the code. They love looking for edge use cases that are likely to have been missed by development. They can be very effective testers, but sometimes can fall into the role of the Perfect Code Zealot (I’m not a fan of Zealot testers, unless their energy can be channeled appropriately). What I do know is that these people will find a lot of bugs. Whether those are the “best” bugs is another topic 😉
I may have seen more of these people because most of my career has been in compilers and back-end/platform systems, which seem to have a gravitational pull for this type. One of the reasons I like working with this type is that their minds are always working on the next way to break the product.
Whether this hybrid is worthy of a category of their own, I’ll leave up to you if you agree.
By the way, having worked with Jon, I totally agree with him being the epitome of the Social Tester and why I think he is such a great all around tester.
[James’ Reply: I think I had one of those working for me, in the debugger team at Borland.]
Hi James,
I’m curious if you noticed (in your travels) whether certain parts of the globe generally have X tester kinds over others? I understand that testers may cross into different categories but as an experienced teacher and mentor, i wonder if you have noticed *clumps* off certain kinds of testers around the world? For example, New Zealand *may be* more the home of the empathetic tester and User Expert whereas other countries may generally be different (and of course we could drill down further if it was relevant/useful/amusing/interesting into different cities and so forth).
It would be interesting to see you’ve observed 🙂
And if i was to apply these categories to me i would say that I’m a social tester (that has a dormant Analytical tester waiting to *bust* out at the right opportunity!)
Thank you for your post James.
[James’ Reply: No, I haven’t noticed any variation according to geography. I would say the variation has to do with culture. I find that Agilists are more often technical testers, users, or developers, for instance. Big companies that don’t focus on technology are more often full of administrative testers. Regulated companies are strongly administrative. Small startups that are not otherwise consciously Agilist are teeming with users, developers and empathic testers. Social and analytical testers are sprinkled all over, and are more rare.]
Good Article 🙂
I’ve found that I fit in four categories.
Would you mind if I translate your article into Thai language ?
( I put the credit to your website,you name and the link of this article below of my translation article )
[James’ Reply: Go ahead.]
Academic Tester:
These people prefer to study idealistic and/or academic ways of thinking about testing, above testing. To them, learning about testing is more interesting than actually doing the testing. They tend to get bored if they spend an entire day testing. They sometimes struggle to balance how much time they study testing theory/practices with how much time they spend getting practical test work done; the line between the two activities may seem more blurred to them than it does to other testers (which can be both a strength and a weakness, depending on context).
[James’ Reply: If I encountered such a person, I think I would categorize him as an analytical tester not yet comfortable with his skills. It would have described me pretty well in 1991, except that I was a test manager, so I took refuge in being the management version of an administrative tester, while furtively acquiring books and papers about testing.
I bet there are a lot of academics who fit this description, but I feel no need to talk about them, since they don’t impact the industry in any way.]
Nice article James., i thought i’m shrinking between all the 7.., 🙁
could you please tell me, A Good tester comes in which category..?
I don know who am i., but i want to be the one good in Software Testing industry..,Of course yes, am on the way of it.,
Thanks in advance for your answers.,
[James’ Reply: Any of these types can be a good tester. However, the developers and users don’t consider themselves testers.]
Is it possible to be an Empathic Tester *and* an Analytic Tester? I definitely take an analytic approach a lot of the time (supplemented by slowly growing Technical skills), especially when I’m exploring a potential bug I’ve identified in more detail, or trying to figure out if there are any big areas I’ve missed in my testing so far. I’m also very analytical when I’m doing automation work. My early (and most productive) testing, though, tends to be a lot more intuitive, and I spend a lot of time trying to understand users, and thinking about what things users might see as bugs that we might not necessarily realize were problems. So it seems like I fit in both categories to at least some extent.
[James’ Reply: Absolutely. You sound like a versatile tester.]
Hi James,
I have worked with a person who I can only describe as “thinking out of the box” as a primary (and almost only) method for approaching testing. I want to assert that thinking ad-hoc is a valuable method for complimenting a larger approach to testing, so I didn’t see his approach as a negative.
[James’ Reply: I would challenge you to point to any testing which did NOT include ad hoc thinking– which is a phrase that means “thinking about the specific situation I am in right now.”]
But, he was valuable as part of a team, but not so much as a single entity. His approach was not really risk-based or context sensitive, and I wouldn’t go as far as random either, but generally he approached an application primarily on his What-If’s. It’s a little bit gut-feeling, instead of employing any kind of structure or plan.
But as the larger team consisting of myself (veering towards social), a senior tester (analytical), and him, where he displayed this sort-of hybrid between Empathic and Ad-Hoc, we made a very competent and successful team when all working together on one application or project.
The complications arose when we were working on separate projects, where he suffered more than the others from being unstructured, (worth pointing out that we were all working as Exploratory testers, so when I mean unstructured I mean not approaching tasks with any kind of charter, plan or risk-based take on things, or any kind of best-approach based on context).
[James’ Reply: That’s part of what I mean by “empathic.” I was trying to convey two things with that term: A) an attempt to connect with the user’s experience, B) an intuitive mental approach. You seem to be referring to the intuitive aspect.]
It’s not an intention of being negative towards him, what I am genuinely interested in is;
– If you have experienced someone like this?
[James’ Reply: Yes. I group them in the empathic category.]
– Your experiences, positive or negative?
[James’ Reply: My experience is that I have historically not trusted them and not considered them educated testers. I now believe I have been mistaken in that attitude. Although I am not much of an empathic tester myself, I believe I can use my skills to help bring words to what they are doing.]
– If this brings up an “8th” type of tester, and if so, how would you name/describe these traits?
[James’ Reply: Well, it suggests that “intuitive” may be a more descriptive label than empathic, but I still think empathic is better from a rhetorical standpoint.]
And not related as much, but a general question;
– If you were in a scenario where you had to construct a test team, and were asked to pick four people from seven people, who individually conformed to your categorisations (each individual represented one categorisation at 95% level, the other 5 percent may veer towards other categories), which four would you pick from?
[James’ Reply: Assuming that all other things are equal, my bias would be to get one social, one technical, and two analyticals. That happens to conform with my own self-description (25% social, 25% technical, 50% analytical). However, if I had access to a user expert, I would go for that, regardless of type. If I had to pick a test manager, I would probably choose administrative.]
Personally I would go for a Tech(or Dev), a Social, an Analytical and an Empathic tester, to try to cover different bases, this is a little bit like covering overall development principles;
Design/Analysis (Analytical tester)
Development (Technical tester)
Test (Social – using different applicable principles, (from own and other testers), to apply good testing in context)
User acceptance (Empathic)
Cheers,
Ben
You are not the only one who has not recognized or respected empathetic testers. The industry is rife with this kind of attitude, including in my current place of employment. I want to thank you for this list, because it gave me words to express what I’ve known for a long time but could not express in a meaningful, intelligent-sounding way. Empathetic testers and other testers with non-technical backgrounds are often faced with having to continually prove to a skeptical audience why their skill set and approach to testing is valuable. This would be okay if it weren’t for the fact that, as you note above, we often have trouble categorizing and explaining what we do and how we do it. We just know when we are immersed in the testing that we care deeply and that we are noticing things that others might not notice and that it somehow matters! It’s a different type of intelligence that does not seem to be prevalent in the technology industry, but I believe is needed to keep it balanced. It doesn’t meatter if your list is definitive or not; it gets us thinking and helps people like me formalize my tester identity a bit more. Thank you!
[James’ Reply: Now we need to deepen our understanding of empathic tester competencies and how they develop them.]
Hi James,
I am considering scenario where tester from any of the 7 categories moved into non testing role but because of past experience he/she do not give up testing. How about calling them Passionate Tester.
They do testing whenever they get an opportunity e.g. whenever they are accessing portal/products/tool/accessing their bank site/eCommerce sites or even when they are using Facebook/LinkedIn. Passionate tester just do not give up testing 🙂
Regards,
Yogi
Hi James!
I think this is a great start for a good discussion. My reply reflects on what I’ve seen during my career and what I’ve been lately thinking about. Lately, in this case, includes a period of about a year. I started pondering about this after I realized I had made a huge mistake in my past and the main motivation for this bad decision was fear. That was the moment when I really felt the pain fear-driven decisions can do; even if they seemed acceptable at the time of the judgement.
I call this the “Coward” tester, but someone might want to call it the “Compliant” tester or something like that. I use coward because of the reasons mentioned above.
[James’ Reply: Brian Osman calls such people “possum testers.” I generally call them “fake testers” or “ceremonial testers.”]
Some characteristics of a coward tester:
– afraid to write bugs because “dev’s would kill me if I’d report that”
– will provide any kind of report when asked
– will make a boatload of test cases when asked
– does’t question pretty much anything
– prefers to make shallow agreements and act polite with people rather than do his job properly
– doesn’t raise up issues that slow down testing or make it unnecessary difficult
– I could keep on going, but I hope I’ve made my point already
I know the characteristics are leaky. What is “doing a job properly”, for example? Those explanations are for a new comment or a blog post. I didn’t want to write a book, this time.
[James’ Reply: My list of tester types is intended to be a positive statement. But, of course, any of the categories can turn bad. The kind of tester you are talking about most readily is found when the Administrative Tester type goes bad– they see themselves as “getting the job done” (by faking it if necessary).]
As a side note, I think the tester I am describing might not be a tester type, actully. It might be typical for some testers to work in this way, but instead of being a tester type, I think it might be more of a personality type.
Thanks for the post!
Best regards,
Jari
After reading I feel like an Empathic tester but I can when questioned give reasons as to how I’m testing and how I’ve arrived there. I can be very analytical when in a project but at the same time I rarely create diagrams around my testing, it’s definitely not a favoured activity for me.
James,
I particularly liked this post. It not only made me think about what kind of tester I am, but what my teammates at work are.
On this same line, I have a thought for you, though: that guy Mario from previous posts that went against you (I believe in the excellent checking vs testing post), he seems to be analytical as well. In one of your comments in this post above, you mention that you are also analytical. Do you think that’s why you two are butting heads?
[James’ Reply: Yes, that’s a factor. When an analytical tester wants to bully you, he’ll often use a particular style of scientific discourse (such as using words like “discourse”) to establish intellectual dominance. The problem with that is: I’m a master of that rhetorical style. Someone comes at me like that and he’s going to be choking on his meta-models and spitting out teeth pretty darn quick– unless he has good ideas, of course.
The man is confused and poorly educated, that’s why he’s having trouble with me. The fact that he uses an analytical style just makes him especially irritating.]
I propose this: ask him to test something that you also test (like a challenge).. maybe you can beat him at his own game. I’m sure he’s all talk and won’t take your offer anyway, you and Michael are the best of the best!
Anyway, thanks!
[James’ Reply: If I were in the same room with him, I would probably do that.]
I figured, why wait until he’s in the same room? So I went ahead and contacted him about the challenge. I’ve also been contacting all the people I know so they tune in and “watch”. This should be interesting if he responds.
-Matt
[James’ Reply: Look, there’s a big difference between being in the same room and not being in the same room. I don’t want to do a remote challenge, and I didn’t ask you to invite him for one, but since you did and he contacted me– I gave him one. He immediately refused it. He offered a different one instead, but I’m not in the mood to argue with him about the terms on which he will demonstrate that he’s not an idiot.
When and if we’re ever in the same room, I will probably offer him another challenge, and I suspect he’ll refuse that one, too.]
Hi All,
I was thinking of a couple of cases. One is the “business-focussed” tester. They are someone who has a project focus usually and probably puts a priority on considering risk and trying to think outside the box since the worst bugs are usually the ones you never thought about testing for. I think you might put this under administrative but I don’t think that’s accurate as they don’t care about ticking boxes or necessarily about project timelines, just about minimising risk as effectively as possible within project constraints.
[James’ Reply: There are certainly a lot of people like that. I think I would call them a combination of analytical and administrative, or empathic and administrative. The fact that they are focused on the business is an administrative thing, but thinking through risk is an analytical thing.]
Another is the “it’s a cool game” tester who enjoys finding bugs or writing programs that do so, just for it’s own sake. You might say they are a subtype of analytical but I don’t think so because they’d rather just do it, than analyse.
[James’ Reply: Hey, analyticals actually do testing, you know! But perhaps you are speaking more of the empathic tester.]
Thirdly, there is the team player who cares most about helping the team and relating well to the team rather than the analytical, technical, adminstrative or user aspects. That sounds similar to empathic but it’s with the team, not the users.
[James’ Reply: You just described the social tester.
Of course, I may well be suffering from an assimilation bias.]
Funnily enough I think I’m a mix of the 3 above, with the 3rd a little below the first two in priority for me.
I’m not sure how much these are simply personality types applied in a testing context – there certainly seems to be a crossover. They could also be seen as archetypes I guess.
cheers,
John
Hi James
I like this categorization, probably because I am an analytical person…
But as a tester, I am dominantly empathic. I want to find out what is important about the product, and I want to help make it as good as possible.
I would rather say I empathize with the product, than the user (or probably the relation.)
[James’ Reply: I wonder if you are using the word “empathy” in the same way that I am. To empathize with something is to feel what it feels. I don’t think it is possible to empathize with a product, since it has no feelings.]
I don’t find it difficult to describe what I do, but it requires someone who wants to listen…
I use analytical tools, e.g. SFDIPOT, CRUCSPIC STMP and product-specific models, because they help me understand the product, in many ways.
I use my technical skills to be able to reach further and test faster.
I am quite social when it comes to asking work questions, but not a lot otherwise.
I perform administrative tasks, when I have to.
I often try to do something real with the product, touching on the user expert, because it enhances my understanding.
So all roles are involved, but the others are supportive to me, helping me be a better empathic tester.
[James’ Reply: You have spelled empathic “emphatic” throughout your comment (I corrected it). I’m starting to wonder if you actually mean to be saying emphatic. If so, I don’t know what an emphatic tester is.]
An interesting side-effect is that I have problems when testing products I don’t like.
I rather enjoy the paradox “trying to destroy something I love”.
[James’ Reply: I’ve never understood how looking for problems in a thing is in any conceivable way trying to destroy it.]
There might be some more orthogonal types of testers, that I suspect aren’t as interesting as your seven:
Result-driven: what matters are the results we get; wants to have as much test execution as possible.
[James’ Reply: That’s included in my administrative category.]
Accountability-driven: What I do should be visible, so it is reviewable, and possible to go back to.
[James’ Reply: That’s included in my analytical category, mostly.]
Responsibility-driven: I must do what I promised, so no one can blame me.
[James’ Reply: That’s included in my administrative category, too.]
Professional: fulfills the testing mission, within given constraints.
[James’ Reply: All kinds of testers do that, inasmuch as they comprehend their mission.]
Specialized: Performance, security, usability…
[James’ Reply: You’ve just named nearly all the specialties, right there.]
I think your categorization will be useful for further investigations about “what we test and why”.
/Rikard
Hi
You are right, empathy is something for persons (my misspelling of empathy was a second-language typo, it is “empati” in Swedish.)
But I feel for the product, and want it to reach its potential.
/Rikard
[James’ Reply: But… if you change the product (to fix a bug, for instance), it’s no longer the same product. So, aren’t you really saying that you feel for the IDEA of the product?]
Good point!
I would even say that I feel for MY idea of the product, using my mental model of what should be good about it, and what is important.
It is not correct, it’s not identical to others’, but it is useful.
/Rikard
What would you call an ex-developer, long time tester, that leads, reports and coordinates test projects, test team members and processes; who builds tools to make the teams life easier when an efficiency can be realized; who analyses data for test patterns and test boundaries, identifies requirement and design issues before they reach the testing stage; who is passionate in championing the client (and/or users) experience of the product; who is a Subject Matter Expert (SME) in the areas being tested.
[James’ Reply: I am an ex-developer, but when I test I am not in the role of developer. Championing the user is not the same thing as empathizing. Empathy is a process, not a goal.
But, I’m quibbling… I would call such a person quite versatile. I try to be such a person.]
I haven’t thought about this for very long, but there might actually be an interesting overlap type somewhere between “empathic” and “analytical”, which might possibly deserve its own type (or might not…). Given your talk at Test Bash last year I might call this the “galumphing tester” (I originally thought of “backwards” tester, but that’s a bit unflattering!).
Rather than analysing the specs, breaking the system down into pieces, and then building test cases in a bottom-up way from their models as an analytical tester might do, or thinking about what the user would do as some empathic testers might, galumphing testers might start by trying to inject as much complexity into the system as possible, and then when they find something suspicious or interesting, would work backwards to try to isolate the simplest possible cause of the problem (sort of analytical, certainly not just random, but doing their analysis and building their models on the fly as and when they see something break).
These are the sorts of people who wouldn’t necessarily start with the nice simple mainline case, they’d go for the obscurest and most neglected parts of the system, or maybe start stress testing, or something, because they tend to think about risk as “the things most likely to break” rather than “the things the user cares most about”. I think the video of you in the taxi mashing the screen to try and break it is you exhibiting this sort of behaviour. They might be empathic in this sense because they’re more likely to follow their instincts than make an upfront plan (but as I say, they’re not empathising with the user especially, hence maybe being their own breed?).
These people are great at finding all of those really hard-to-reproduce bugs, and are probably better than most at figuring out the repro steps for that bug, since a) they’re used to working backwards from complicated scenarios, and b) they probably have especially good memories (and/or use recording software), combined with strong inference and pattern-matching abilities.
The warning for these people is that they risk neglecting the mainline cases, and they risk making their test cases so complicated or destructive that they can’t get back the information about how they broke something. It’s good when this type is coupled with a bit of the social tester because then they can get the developer or others involved in helping them make sense of their results, and perhaps they can get another person on the team (the user expert or developer, for example) to test the mainline cases so they can focus on trying all the complicated stuff.
[James’ Reply: That’s an interesting description. I agree it’s one technique. What I’m struggling with is how someone can be a competent tester if that’s the majority of what he does. I supposed we might generalize it and call it the “technique-driven” tester, though. Something to think about.]
Hi James, thanks a lot to share these opinions. I’m a tester doing performance testing works. I’m wondering if I can translate this article into Chinese and publish the translation on my personal blog? Just share the ideas with other programmer and surely for non-business purpose. Besides, I will add the original link to your blog without doubt.
I’m looking forward to your reply 🙂
[James’ Reply: Go ahead.]
Yes, I like the “technique-driven” tester as a generalisation. It’s not necessarily all about galumphing – that was perhaps just the (extreme) example that first came to my mind, which didn’t feel like it was covered elsewhere in your model.
> What I’m struggling with is how someone can be a competent tester if that’s the majority of what he does.
I think the general idea of using techniques as a starting point for exploring software is a significantly more palatable one than just someone who loves button-mashing! I appreciate you taking what I threw out there and improving on it – thanks! 🙂
I’ve been thinking about this for quite some time: I want to say I am clearly a social tester, but I am also technical.
What I find interesting is that I don’t like the “technical” label applied to myself. A few years back, I refused to do an interview with Google because they told me all of their testers must be able to code and I had to prove I could do that as well. I can code and I actually love coding, but I found their mandatory requirement to be almost insulting, especially since the position was not a technical one.
I think this must have to do with the warnings associated with each type: it turns out I’d rather seem lazy and like I’m mooching off of other people’s work than be someone who prefers studying tools to studying testing. I’d rather be socializing too much than thinking only in terms of code.
I hope the combination of the two types and the differences between them might work to my advantage, if I learn to use them well.
I find that I am a Technical , Analytical and User Expert in the work that I do.
Being the above three has helped me to evaluate testers for the various companies I have worked for as well as understanding the work they do.
Thank you for provide the description of the types.
How do you size up a person during coaching to fit into one or more of the listed categories? Do you ask them straight out or do you go through an interaction or a set of questions and then arrive at a conclusion?
[James’ Reply: I don’t really think in terms of “fitting” them into the categories, but rather I notice what they do and wonder if what I’m seeing is someone who is more comfortable with analytical or perhaps an empathic style. If I can’t decide, I might try giving an exercise that demands one or the other style and see how they react.
I might also ask, but I prefer to see directly from behavior.]
I think with current development in testing field and clients requiring more and more ‘all in’ testers you need to have a little from everything to be a ‘good’ tester. Specially having knowledge of test tools is a big plus!
I have been thinking about the use of the phrase “technical tester”. It seems like the phrase “technical tester” opens itself up to mis-interpretation. “Technical”, as I understand it, has two connotations:
1. relating to technology (e.g.: technical writer)
2. relating to the techniques of a craft (e.g.: technical chess player, technical wrestler)
[James’ Reply: The common usage is meaning #1 in testing. The term I use for referring to #2 is analytical tester.]
I get that you are using the phrase to mean related to technology. However people may mis-interpret it as mastery over the techniques being used in the craft. To me, this mis-interpretation has at least a couple of downsides. One, the mis-interpretation makes it look like being technology-inclined is the highest form of our craft.
[James’ Reply: Yes, it might be misinterpreted. But I think that particular problem is rare.]
Two, some people seem to like defining things by contrast. So if these people hear the phrase “technical tester”, they may assume that the rest of the testers are “non-technical”.
[James’ Reply: I don’t see a problem with that. Simply speak of mixtures. I’m about half analytical tester, one third technical tester, and the rest social.]
I have thought about alternatives but do not have a replacement phrase yet. Your thoughts?
I think most of the emphatic tester has a QA/BA role on a team.
I would like to suggest adding three more categories to this list. First two under types of testers and last one under “so-called-tester” / “mythical tester”
1. Cognitive tester – who is a ‘thinking’ tester and is a bit of every other category you have already mentioned. Has a rationale to approach and can change hats at short notice to adapt and bring best to the table. The experiential testers can also be falling under this category.
2. Impulsive tester – A rare breed – who has a natural ability to test and figure out the loopholes. Their ability of intuitiveness highlights more number of critical bugs than that identified by most of the testers.
3. Checker – who is not a tester but thinks himself to be a great one. We cannot disregard this category of people ( referred as testers in the industry). Reason being they live in mythical classification of testers and do no significant value add to testing as a process.
Thank you very much for this very intriguing post (although I am not sure whether you would end up reading this response considering how old the post is).
I went through a lot of the testers that I’ve worked with in my mind, trying to classify them into one or more of the seven types. I came across one whom I had trouble fitting into any of the seven categories, and that’s what really prompted me to leave a response.
May I suggest, an “Academic Tester”: An academic tester’s main focus is on studying the product. They like to study designs, specifications, manuals, etc. to “complete” their understanding of the product. These testers perform testing not so much to “discover”, but to “confirm” that the product works (or does not work) as per their knowledge. These testers often very quickly become SMEs in the area that they were tasked with testing. Warning: academic testers can end up spending too much time just learning about the product rather than spending the time to actually test the product.
[James’ Reply: A person who seeks to confirm instead of discover is not, in my view, a tester at all. I don’t see this as an academic sort of thing, but as a misunderstanding of testing.]
Hey James, so I just got to discover about your kinds of testers. As the testing industry has evolved so much over these years, do you think we need to reevaluate these kinds, introduce more kinds maybe. What do you think about it, I would love to have a conversation about this
[James’ Reply: Nothing is ever settled. But offhand I don’t know of any categories I would add, delete, or change. What do you suggest?]