The tester stereotype follows the common picture of IT people: introverted, not very sociable and fixated on a single interest. An industry survey among testers shows the opposite: only 6 percent fit that picture. Testers come from theater studies, urban planning, boatbuilding and the arts, hold a wide range of degrees and work in technical and non-technical roles alike.
Key Takeaways
- Only 6 percent of the testers surveyed match the classic IT stereotype of the introverted, socially isolated nerd with a single interest.
- Testers come from fields such as boatbuilding, theater studies, urban planning and international relations, so there is clearly no single educational path into IT.
- An IT degree doesn’t predict who ends up in a technical role: 40 percent of humanities graduates worked in test automation, and 40 percent of IT graduates held no technical role at all.
- Recruitment databases and career guides keep the stereotype alive by encouraging mainly the stereotypical IT type to apply, which narrows diversity from the start.
- Isabel Evans developed 12 heuristics, phrased as questions, that help tool builders and evaluators match testing tools to what users actually need.
The Tester Stereotype Doesn’t Match Reality
Testers are far more varied than the usual tester stereotype suggests. An industry survey by Isabel Evans backs this up with hard data rather than gut feeling. She sent out open questionnaires through online networks and at conferences and asked not only about ways of working and tools, but also about hobbies and personal background.
The answers came from all over the place: boatbuilding, theater studies, international relations, urban planning, fine arts. That is why the first version of her article was called “From Artists to Town Planners”. It was later renamed “Breaking Stereotypes”.
The range of hobbies stands out too. Many respondents named artistic interests, often several at once. That doesn’t fit the picture of a narrow-minded loner obsessed with one special interest.
What the IT Stereotype Actually Claims
The stereotype describes someone who isn’t very sociable, has no interest in art, doesn’t say much and is fixated on a single hobby. A nerdy, quirky type, in short.
That image didn’t appear out of nowhere. It sits in recruitment databases and career guides. Look it up there and the message is roughly: if you’re this kind of person, go into IT. So the stereotype works as a filter before anyone is even hired.
Isabel Evans builds on a study by McChesney that looked at exactly this comparison: people who wanted to go into IT versus people who already worked in IT, both measured against the stereotype from those databases.
Only 6 Percent of Testers Fit the Mold
In Isabel’s group of testers, just 6 percent matched the IT stereotype. In McChesney’s general IT sample, it was around 26 to 30 percent. A sizable share, but nowhere near a majority.
Applicants who wanted an IT career matched the stereotype more often than people who were already doing the job. In other words, hiring narrows down who feels encouraged to go into IT in the first place.
That creates a practical problem. If software is supposed to serve the whole world but only a narrow group builds and tests it, the link to reality goes missing. Diversity in a team isn’t a goal in itself. It decides whom the software ends up reaching.
A Degree Says Little about a Tester’s Later Role
Testers’ educational backgrounds range from the humanities to the natural and social sciences, and some have no university degree at all. The degree barely predicts what work someone ends up doing.
The numbers go against what you might expect. About 40 percent of the humanities graduates worked in test automation or other technical testing roles. At the same time, about 40 percent of the IT graduates didn’t work in a technical role at all.
So if you assume that a humanities background leads straight into test management and a computer science degree into automation, you’ll be wrong. A degree reveals neither talent nor preference.
How a Tester’s Field of Study Shapes Communication
There is a link between what testers studied and how they write about their work. Isabel Evans modeled the communication styles from the open answers in the survey.
The patterns were clear:
| Background | Communication style |
|---|---|
| Humanities | Readable, well-phrased texts, almost like essays, with narrative descriptions around people and problems |
| Social sciences | Focus on the organization, teams and how people deal with each other |
| Natural sciences | Structured lists, short and informative, clear order |
| IT graduates | Lots of technical detail, little structure, functional rather than narrative |
| No degree | Enthusiastic storytelling, vivid and direct |
That makes a case for mixed teams. People from the humanities and social sciences carry the story through the company and talk to other departments. Scientists bring order and structure. IT graduates supply the technical skills, though often without the communication side.
A team needs all of these voices to name risks and work out what everyone needs from each other.
Tools Fail on Usability, Not on Looks
The research started with testers’ experiences with their tools. Those experiences often affected their quality of life: a lot of frustration, strong emotional reactions and, now and then, positive feelings. That alone is reason enough to care about well-being at work.
What really frustrated users was usability, not surface-level ease of use. The key question was: can I carry on with my workflow? Does the tool get me where I need to go?
This led to the idea of an illusion of user-friendliness. Tools get bought for their good-looking interfaces. At first glance they seem easy to use, but once you start working, the tool doesn’t support the way you test.
These findings didn’t come from leading questions. Respondents were asked to tell the story of an experience with a tool. Which technical and quality characteristics were behind it only emerged when the open answers were analyzed.
Twelve Heuristics Instead of a Ready-Made Framework
The data didn’t produce an all-encompassing framework but a set of twelve heuristics, phrased as questions. The original plan to build a model that derives the ideal testing tool from a set of inputs failed because there were too many variables.
The push came from Hussein Dugan, a researcher at another university. His advice: don’t write a tool for building tools, don’t try to solve the whole problem, derive heuristics from the evidence you already have.
“The heuristics are a tool you have to think with. They prompt your thinking, they don’t hand you finished answers.”
(Isabel Evans)
The twelve questions are open on purpose, because there is no single right answer. You don’t work through them from one to twelve. In case studies, people used them differently depending on the context: they brought some questions forward, changed the order or came back to a question later in the process.
The heuristics are meant for everyone who deals with tools. Teams building tools in-house, developers of open source tools, vendors and people evaluating tools can all use them. The plan is to publish them under a Creative Commons license so that anyone can use them freely.
Diversity Starts in Recruiting
Solid data like this belongs with HR people and recruiters. That is where the stereotype sits, narrowing the pool of candidates long before anyone is hired.
The benefit goes beyond testing. The same evidence helps when looking for developers, UX specialists, product owners, systems analysts and architects. A study that shows how varied the backgrounds of successful IT people are gives you a concrete argument.
In practice: take the evidence to your HR department or your manager and get the conversation going. If IT and testing are to have a future, they need people who reflect the rest of the world, not a single stereotype.
Frequently Asked Questions
Where do people who work in software testing come from?
From a wide variety of fields. An industry survey by Isabel Evans cites, among others, boatbuilding, theater studies, international relations, urban planning, and fine arts as testers’ previous fields of work and study. The range of hobbies was also striking: Many respondents reported artistic interests, often pursuing several at the same time.
How many IT professionals actually fit the “nerd” stereotype?
A clear minority. In the tester group surveyed by Isabel Evans, 6 percent fit the image of the unsociable, taciturn person with a single specialized interest. In a more general IT sample by McChesney, the figure was around 26 to 30 percent, a considerable proportion, but far from the majority.
How does the IT stereotype influence who even applies for IT jobs?
It acts as a filter before hiring. Recruitment databases and career guidance resources describe a specific type of person and, in effect, encourage precisely that type to apply. In McChesney’s comparison, people aspiring to an IT career were more likely to fit the stereotype than those already working in the field.
Is a degree in computer science a prerequisite for technical testing roles?
No. A degree is hardly a predictor of what role someone will eventually take on. About 40 percent of the humanities majors surveyed worked in test automation or other technical testing roles, while about 40 percent of IT graduates were not working in any technical role at all. People without a college degree are also represented in testing.
Why is a diverse background beneficial in a testing team?
Because one’s field of study shapes how someone talks and writes about work. Humanities and social sciences graduates tell stories centered on people, teams, and problems, and carry those stories to other departments. Scientists bring concise, organized structures. IT graduates provide technical details, often without the communicative aspect. Only together can risks be identified and mutual expectations clarified.
Why do testing tools often disappoint despite having modern interfaces?
Because usability and aesthetics are two different things. Isabel Evans calls this the illusion of user-friendliness: tools are purchased because of their attractive interfaces, appear easy to use at first glance, and then fail to support the actual testing process. The crucial question for users is whether they can continue their workflow and achieve their goals.
What advantages do heuristics offer over a fixed evaluation model for tools?
They remain applicable in contexts where a model fails. The original plan to derive the ideal testing tool from user input failed due to the number of variables. Instead, twelve deliberately open-ended questions were developed. In case studies, users brought individual questions forward, changed the order, or returned to a question later rather than working through them sequentially.
