Tester Versus Developer Mindset As A Personal And Subjective Account

If I describe it as a feeling then, yes, the tester and developer mindset difference exists

People talk about tester mindset versus the developer mindset. There are varying notions of what those different mindsets might entail. There are competing opinions about whether or not either really exists.

In this article I am going to describe the tester versus developer mindset difference entirely from my own personal experience. I am going to describe my feelings as I work on different testing and development problems, and how those feelings seem to me to affect my work and performance. This article will be a subjective account.

I do not know if others will consider a subjective account about feelings meaningful or relevant. What I hope to do is get down to irrefutable facts. The facts are that these are my memories of my feelings. Sometimes what we need are irrefutable facts to move forward so we can ask questions of relevance, salience, meaning, implications, ponder counter facts or conditions. The discussion is far more interesting when we move beyond fighting over the facts.

Background to my experiences

I programmed computers as a hobby as a teenager (1980s). I have a minor in Computer Science from Western Washington University (class of 1990). I started at Microsoft in 1990 as a product support engineer, moved into testing in 1994. As a tester I wrote a great deal of code to support my testing in various ways. In 2012 I moved into the Office Engineering team where I worked on the automation system in Office, doing mostly coding and design and large scale automation analysis for over a decade. I officially became a software engineer in 2014.

Short version, I have over 20 years of software testing experience on large scale products, and over a decade of being mostly a programmer. My background and skills for testing are more in-depth than in programming, but I have done many years of both. This background shapes a lot of the feelings I am going to share.

Do I feel two different mindsets? Yes

There is something I feel, as if it is happening to me mentally and emotionally, when I am primarily testing that is different than when I am primarily coding. This difference is further amplified when what I am testing is my own code versus someone else’.

What do I feel in each mindset?

Some of these feelings are blunt and raw, and may seem like bragging. I am trying to be honest about feelings, and I know that in many cases the feelings I have may not reflect something really happening outside of me, but the way I am writing this I am obligated to present an honest account.

My tester mindset default state feelings

I have to set a default state for how I feel when I am testing. By far, I am more comfortable with testing than with any other work activity. There are many times, when testing, where I feel like I am in a zone. Ideas are flowing, I am digging deep, I am finding out information nobody has figured out yet. The product feels like it is melting under my fingers. I see bugs everywhere. I see new things I want to try at every turn. I see simple problems. I see deep complicated problems I don’t understand, but I want to dig deeper.

This level of performance becomes a baseline I contrast against feelings at other times.

My mindset when I am writing code and trying to test

I am describing a mindset when I am dominantly writing code. This means that for some time period such as a day the main thing I am doing is creating or changing product code. I am focused on creation or alteration of something that solves a problem of some kind.

I do a lot of testing when I code, but it is also always in short bursts. Sometimes as short as a few seconds, usually a few minutes. I test to learn something, write or change some code to address what I learned, test more to learn something else. I use a test first, coding after TDD style approach to my coding (although not for larger designs where I work out my ideas up front).

I actually catch myself with an internal dialog telling me NOT to try certain tests or areas of investigation. Going far beyond a dulled sense of capability, I feel almost a dread for doing more or going deeper. I feel a dread for switching away from changing the code.

I feel mentally hobbled and crippled when I do this kind of testing. All I can imagine is the next functional behavior I want to change or create in the code. It is mentally arduous to imagine the test code would demonstrate failure of that change to do what I intended. I am pretty good at it, and actually enjoy it, but compared to the flow state I am in during my testing default I feel slowed down with a dulled imagination.

By analogy, I imagine how an Olympic class swimmer must feel if they were to return to the pool recovering from a major back injury. Used to world class times and long sessions, they instead awkwardly do their laps at a pace that appears like a novice swimmer. This is how I feel when I try to test while directly writing my own code.

If I was to compare this mindset against my default testing mindset, I would say it feels somewhere like 15-25% of my high performance testing state of mind.

My mindset when I am testing code I wrote

I describe here the act of primarily shifting to testing my own code for a significant period of time. Maybe a day, maybe an hour, but time that is dedicated to testing and not writing code.

I still feel somewhat hobbled, but less so. My initial transition is slower, less ideas flowing, but I start to pick up the longer I work at it.

I find the natural idea flow that seems to come without assistance when I test someone else’s code requires assistance. I rely more on exercises like rote enumeration of cases to stimulate thought, or picking some activity that is testing adjacent but open ended enough I have to experience the product as someone other than the person who is going to change the code.

I would say that after maybe an hour or so I can get myself feeling like I am around 50% of what I would normally be in my default testing state. As the time committment grows longer - a day or two - or the exercises get more and more distant from writing the code - the feeling creeps higher than 50%.

During this time, sometimes I feel urges to get back to changing the product code. Sometimes I see a bug and want to fix it immediately instead of execute more tests. Sometimes I start to get bored of the testing, and adding the next feature on the list is more attractive.

Projecting my feelings outward and onto others

This account of my feelings about other people might bother people a lot. I will stand behind how I feel about what I describe, but will concede that my feelings are not a fair, or measurably accurate account or assessment of other people’s skills or work. I am going to be blunt but honest. It is wise and fair if you contemplate my feelings with skepticism.

Non-testers usually describe and demonstrate testing that feels to me like my 25% experience

When I hear developers and product managers and consultants describe testing activity and what they expect testers to do, or advise how testing ought to be done, the examples they offer, the ideas they describe, the methodologies they propose feel like the ideas I come up with when I am hobbled by my “testing while trying to write code” mindset. Further frustrating is when such people describe such testing as top level performance, sufficient for all uses. From the perspective of my feelings, these other accounts and behaviors feel obliviously amateurish.

Non-testers who commit and dedicate time to testing start to feel to me like my 100% experience

Sometimes a non-tester dedicates time to only testing. For me, this means far more than the minute by minute slices implementing TDD cases. It means far more than summing up development sprints with unit tests to run in a CI/CD pipeline. It suggests time commitments of days at least. Sometimes long term when a non-tester effectively turns themself into a tester to tackle really hard problems

Almost every time I have seen a non-tester do this, the results to me feel far more impressive. I feel every time I have seen someone, especially developers, talk about a specific testing problem as its own thing to wrestle with, investigate, plan for, build a solution and strategy for, I feel as if they are experiencing something similar to my “in the zone” state. The ideas feel richer, the solutions more inventive, the output feels deeper and more fruitful.

Summarizing my feelings as beliefs

• I believe I experience a difference between a tester and developer mindset
• I believe that difference affects my productivity and quality of testing work
• I believe that experience is further affected by whether I am testing my own code or someone elses
• I believe I am able to increase my testing productivity when working on my own code by dedicating time to testing and applying exercise to assist in the sift
• I believe I see evidence of a lower quality testing output similar to my own diminished “test my own stuff” performance when observing or talking to people who do not dedicate time specifically to testing
• I believe I see significant improvement in performance when non-testers dedicate time to testing

I feel in those beliefs might be indications of ways to think about, discuss, or work with shifts between tester and developer mindset and impact on testing productivity and quality.