Being paid to use your brain is weird, right?
Is it just me, or is it really weird to be paid for your brainpower and how you think? It could very well be me: being told at school that you have no ability or value beyond manual labour jobs plants that impostor syndrome worm firmly in your head. But enough about my insecurities.
Software testers and developers may not think of themselves like this, but we are indeed knowledge or thought workers. We are paid for the power of our brains and our ability to think, equally or more so than for our particular skills.
What is a thought worker?
According to Wikipedia, there is no definition of a thought worker, and no succinct definition for a knowledge worker. So, for the purposes of this article, I’ll use the term ‘thought worker’ throughout, which is distinct from ‘thoughtworker,’ or someone who works for Thoughtworks, the company.
I have defined a thought worker in the Ministry of Testing Glossary as:
A thought worker, particularly in the context of software development and testing, is someone whose primary contribution and value stems from their cognitive abilities rather than purely from any physical output. For example, many roles could write a test case. For it to have value, target risk, and generate meaningful feedback, deep thought and critical analysis must take place. It is about being valued for their capacity to solve intricate problems, to think deeply and critically about complex systems, point out potential issues or ambiguities, or to connect seemingly disparate ideas, as much or even more than for any physical skill they might employ.
Think of it this way. While a developer might spend hours typing code, or a tester might click countless buttons, the true value these individuals bring is in the mental gymnastics beforehand. It is in the careful consideration of design patterns, the meticulous planning of test strategies, the insightful deduction when tracking down an elusive bug, or the creative leap that brings a new feature to life. It is the ability to anticipate future problems, to understand intricate user behaviours, and to synthesise information from various sources to form a coherent solution.
The work product of a thought worker is often the clarity, the strategy, the insightful question, the elegant solution, or the precise bug report. Their time is best spent in deep work, grappling with complexities, rather than simply executing repetitive tasks. Recognising the contribution of a thought worker means appreciating the immense intellectual capital they bring to the table. Fostering an environment that encourages deep thinking and problem-solving is paramount in building truly high-quality and innovative software. It is about valuing the brain behind the keyboard.
You could also simply say that ‘the value is in the thought before the action, not only in the action itself.’
Thinking about thinking
At this point, we could delve deeper into Immanuel Kant’s moral philosophy, which posits that action is driven by motive and must originate from a moral place or sense of duty. We could also consider the intrinsic and extrinsic value of thinking, where the thought process has intrinsic value, and the resulting action holds the extrinsic value. We could even discuss how physiological research has found a strong link between thought and actions, and even how gestures can influence our thinking. While those topics are interesting, and I’ve added links in the resources section to some related materials, let’s stay on software development and testing, shall we?
For software testers, we need to ask ourselves two questions
- How much thought do we actually put into examining the thinking we engage in?
- How much effort do we put into thinking about the things we think automatically, or subconsciously, versus deeper thought about something?
Those are the questions I asked myself when considering how I think when I’m testing and my tester's mindset. These questions have been bouncing around in my head for years, ever since I first began creating training materials and teaching software testing.
Understanding the tester’s mindset
From the beginning of my software testing career in 2003, I’d repeatedly heard about the ‘tester's mindset.’ There were very few actual definitions and none that I felt fit well. I did some research to see if someone specific coined the term, but it is more likely that it evolved over time.
The more I learned about testing, the less I felt that we, as testers, effectively explain our craft to others. From my early research into understanding the tester's mindset, it soon became clear, just as I had learned that there was no simple definition of a knowledge or thought worker, that explaining a tester's mindset wouldn’t be simple either.
There are various short or simplistic definitions of what software testing is, and I've even tried my hand at it, but none have ever felt quite right. How do you explain something complex in just a couple of sentences? I have, however, had some excellent conversations about both software testing and a tester’s mindset, and I have seen some online discussions too.
In an excellent club post, the insightful Luke Liu asked two questions.
- What does a testing mindset mean to you?
- What’s your tester mindset?
By the time he posted those queries, I had 16 years of testing behind me. And my understanding of what makes for a tester’s mindset had grown. This was my reply in June 2019.
I don’t think that as testers, we should or can have just one mindset. The ability to think in different ways and from different perspectives is one of our superpowers.
A very under-considered, underrated and valuable one is the inclusive mindset. Looking at how different types of people interact with our systems is very important, in my humble opinion.
My opinion about testers needing to use multiple mindsets hasn’t really changed, but it has evolved. I’m now more able to articulate what I mean by multiple mindsets. Below are some examples, each with a brief explanation of the mindset. Maybe you could join in the Club conversation and suggest your own or expand on these?
11 software testing mindsets
- Inclusive mindset: Approaches testing with empathy and inclusivity to look at things from a multitude of perspectives. Focuses on accessibility, usability, emotional responses, and ethical considerations.
- Sceptical mindset: Accepts nothing at face value and questions everything they think they know. Appropriate for reviewing requirements, identifying missing acceptance criteria, and evaluating ideas.
- Scientific mindset: Uses the scientific method of hypothesis, experimentation, observation and learning. Uses evidence-based reasoning to develop measurable tests and valuable automation solutions.
- Exploratory mindset: Goes beyond the obvious to uncover information. Can find less-travelled paths through software to reveal bugs and edge cases.
- Risk-based mindset: Prioritises their work based on what can do the most harm to the product or project. Most valuable when working under time constraints or under pressure.
- Collaborative mindset: Thrives in working closely with people in other roles to create shared understanding and expand group knowledge. Focuses on communication, shared goals, and psychological safety.
- Creative mindset: Uses techniques like lateral thinking or usage of tools in ways different from their intended use. Suggests or uses variations in test data, testing personas, or unusual settings.
- Holistic mindset: Uses a holistic approach and systems thinking to consider causes and effects. Identifies dependencies and unintended consequences, and tracks the ripples across software that result from small changes.
- Ethical mindset: Challenges dark patterns or exclusions and ensures the testing strategy has a conscience.
- Blue-sky mindset: Creative thinking not tied to practical limitations or solely closely related areas. Tries non-standard ideas or actions and isn’t afraid to ask ‘left-field,’ apparently unrelated, or sometimes even the more obvious questions.
- Critical mindset: Uses critical analysis and radical candour to identify assumptions and bias in requirements, artefacts, ideas, or tests.
There are probably many more mindsets out there. The main point is that, as testers, we need to adjust our thinking based on the context in which we find ourselves. This is true even if that means using seemingly conflicting mindsets in conjunction with each other.
Reflecting on assumptions
On a site called The four-hour tester, I came across an interpretation exercise using the English nursery rhyme, “Mary had a little lamb.” What does the sentence actually mean? The idea is to work through each word in the sentence and identify a variety of interpretations that can then be applied to create many potential meanings.
Doing this exercise is a great way to use critical and sceptical mindsets to avoid assumptions and biases that we all have and cannot avoid. You can apply other mindsets to this exercise as well.
So, let's dive in and try a few ideas. However, if you'd like to stop reading here and try the exercise for yourself before continuing, please do. You can share your results on the Club post afterwards.
Who is ‘Mary‘?
We have no context or knowledge about Mary. So our immediate response, if we are familiar with the nursery rhyme, is to draw on our experience to assume that Mary is a child. Even if you have no knowledge of the nursery rhyme, it is still very easy to interpret the name as the name of a person.
However, if we pause and challenge our initial assumption, we find that there is no reason Mary might not be an animal. We could also conjecture that Mary is the name of a poisonous plant that killed a lamb. It is quite unlikely, but we cannot rule it out without more information.
In what context is the word ‘had’ used?
Looking at the whole sentence, an understandable first thought would be that whoever Mary is, she no longer has a lamb. ‘Had‘ is usually used to indicate a former state or something in the past. Since ‘had’ is also the past tense of the verb ‘have,’ we could also easily speculate that Mary enjoyed some food.
‘A‘ stands for how many things?
The letter ‘A‘ often serves as the shortest word in the English language. It can be used in many ways, such as indicating membership or belonging to something. For example: Ady is a Pro member of the Ministry of Testing. It can refer to someone, something or the first. ‘A man.’ ‘A bicycle.’ Is it answer (A) ‘Ady thinks too much?’
How little is ‘little‘?
The above is a fair question, since we usually use the term ‘little’ in comparison to something. For example: a ‘little’ bit to drink as opposed to larger amounts of alcohol. A ‘little’ confused, as opposed to having no ideas or knowledge of a situation or thing. There is even a 2019 film called ‘Little,‘ although I’ve no idea if it featured a lamb.
Who, what, or why is ‘lamb’?
’Lamb’ can refer to a young sheep, typically one year old or younger. ’Lamb’ is also a meat known for its tenderness and flavour. It can also be used as a term of endearment: speaking about a young child, ‘isn’t she a little lamb?’ However, it can also be used in a derogatory sense to describe someone who is easily deceived or manipulated.
Emily O’Connor also used this same sentence in her 404 Talk: Finding test cases in acceptance criteria. By changing each word, she demonstrated how to uncover gaps, edge cases, and hidden assumptions. You can watch her talk for a walk-through of examples.
So, what does ‘Mary had a little lamb’ mean?
Here is a small sample of the many potential meanings of the sentence. There are many others.
- Mary has a lamb
- Mary no longer has a lamb
- Mary ate some lamb
- Mary gave birth to a lamb (Mary is a sheep)
- Mary used to look after a small child
How many possible meanings did you come up with?
Ambiguity is everywhere
It is our inherent nature as human beings to seek simple answers to even the most complex questions. Knowing and understanding can be hugely different things. Albert Einstein suggested that true intelligence comes from comprehension, not just acquiring knowledge. ‘Any fool can know. The point is to understand.‘
Acronyms are ambiguity machines, as well as lots of other things
Context is everything because the answer to every question in testing begins with, ‘it depends’.
- XL: Is it extra large or the number 40 in Roman numerals?
- STD: Is it a sexually transmitted disease, a doctor of sacred theology, a state transition diagram, a subscriber trunk dialling, or the Société de transportation de Montreal? And don’t get me started on the Systematic Theological Department.
Are these cage-free eggs? Or are these caged eggs that want to be free?
To sum up
We should ask ourselves how much we actually think about our thinking when we’re analysing requirements, working out what and how to test, or reflecting on other general day-to-day work tasks. We should recognise ourselves as thought workers and value our capacity to learn, understand and apply that knowledge in a thoughtful way. Most of all, we should recognise that we have multiple testing mindsets, and the way we apply them, along with the thinking that goes with that, is the key to contributing value and making quality software.
For more information
- How is Systems Thinking different from Critical Thinking, Hanisha Arora
- The Power of Doubt - Becoming A Software Skeptic, Zeger Van Hese
- Knowledge worker, Wikipedia definition
- Club questions on the tester's mindset from Luke Liu
- Immanuel Kant’s moral philosophy, Stanford Encyclopedia of Philosophy
- Action’s influence on thought: The case of gesture, Susan Goldin-Meadow and Sian Beilock, Perspectives on Psychological Science
