Developer mindset

Hi all,

So, I’ve just been listening to TapTalks latest podcast episode with Angie Jones. At one point, she says that test automation engineers need to have the developer skillset and the tester mindset. I think this is a great explanation about the skills required for test automation.

This has got me thinking. There has already been a lot of discussion about the testers mindset (here is one discussion on the club). But, what is the developers mindset? How does this differ from the testers mindset? Does this prevent a developer from also being a good tester? Is there a part of the tester mindset that prevents them from being good developers?


Of course testers and developers need the skills for their respective roles. But I see the mindsets as synergistic: If you can think like a developer, you can be a better tester; if you can think like a tester, you can be a better developer.

1 Like

What is a developer’s mindset? Once you got that defined across different people’s (developers & non-developers) viewpoints, you can get a rough idea of how that helps or hurts a tester. The answer isn’t same from everyone so you want multiple viewpoints.

In my view, a tester’s mindset never hurts a developer. Helps one develop/write better code, and/or hand-off better quality code to QA for testing. It also helps them write more & better unit tests, as not all code is actually unit tested. The only negative where it could hurt developer is the mindset from a perfectionist tester (need full test coverage, find all corner cases, etc.) where the search for quality while developing code will impede and slow down the project, you have to find a good balance for when is code tested “good enough”, rather than never ending testing + refactoring to improve code.

A developer’s skills would help a tester on automation, but it’s also mindset or how they use the skills that better helps them in automation. Having skills and how you use them aren’t the same. Applied correctly, the skills + mindset provide for better architectural design, abstraction, and implementation of the test code for better maintainability like keeping the test framework & tooling separate from test case code rather than spaghetti code mixed in, where you can refactor and make changes to UI page objects & framework code without breaking the test case (it works seemlessly behind the scenes), if the framework was written in such a way that test cases are well abstracted from the internal logics of the framework/tooling.

Here’s some articles I wrote where the intersection of developer + tester is useful for a tester (and for developer)

1 Like

There’s a bit of a false dichotomy going on when people talk about “Tester” vs “Developer” mindsets, almost assuming that only one or the other can exist, but not both.

In reality, however, they are a collection of characteristics that someone has bundled together and labelled a “Fill-in-the-blank Mindset.”

Here’s a list from an article on mindset. See if you can identify if its a “Developer” or a "Tester mindset

  1. Take it apart to see how it works
  2. Solve problems
  3. Decompose
  4. Automate
  5. Compose
  6. Generalize
  7. Abstract
  8. Craft

Here’s another list from another article

  1. Being proactive and asking the right questions
  2. Being curious, collaborative, challenging and diplomatic
  3. Being creative
  4. Learning and knowledge transfer
  5. Test Automation

Without clicking at links, can you tell me which is which?

The answer to that is “probably not.”

The whole reason we are even having the discussion of “tester” or “developer” mindset, is because we as an industry have gotten complacent with developers writing shitty code.

Let me explain.

Here’s what people usually mean by “Tester Mindset” - A person who thinks about how stuff might break when they’re working on that stuff.

Here’s what people usually mean by “Developer Mindset” - A person who writes happy-path code and thinks about how to make things work.

Sometimes, people write long lists about mindsets (see above) that go beyond these two things, but anything outside of these two items are just generic good things that any person should do - regardless of their role in software.

And here’s why this distinction of builder/breaker makes no sense: A developer who writes code that is not resilient to how stuff might break not writing good code. A developer must necessarily think with a “testers mindset” in order to write good code. If they don’t - they’re writing shitty code.

A developer that is creating an input field on a web app, must necessarily think about input sanitation, including sql injection, sting length, and a host of other naughty strings.

A developer that is interfacing with an external, or internal API, must necessarily think about how the API may malfunction and write code that handles the API being unresponsive, or returning with an unexpected response.

A developer that is writing a class that interfaces with a filesystem must necessarily think about how to handle missing files, already existing files, locked files, missing directories, permissions issues and a host of other I/O issues.

If the they want to write good code, a Developer, while developing with whatever developer mindset they have, must also think about how stuff might break and thereby also have a “tester mindset.”

And because it is virtually impossible to separate “developer” and “tester” mindsets into two separate things, especially while writing good code, I find the terminology of “tester” or “developer” mindset to be misleading.

But for too long, we’ve let developers write crappy code, thereby requiring an army of testers to come after them and write a bunch of bugs, so that the developer can go back and re-write the code to be less crappy - and its all because we’ve gotten complacent with the crappy output some developers provide.

And not only that. We’ve encouraged it. We moved “quality” to be a QA teams responsibility and gave a free pass to developers to just write stuff w/o thinking about quality. After all, there’s a whole team over there whose job title and role is to think about quality. They’ll take care of it. Why would developers overstep their bounds?


[quote=“lgibbs, post:1, topic:32648, full:true”]
Hi all,

So, I’ve just been listening to TapTalks latest podcast episode with Angie Jones. At one point…[/quote]

Louise, can you give us a link to the actual podcast here?

Oops, sorry about that. I’ve updated the link in the original post. You can also try here:


Thanks Louise. New podcasts are always welcome for skimming though. I like where Angie is coming from journey wize, not sure about the podcast though, its not really on topic - probably more about selling testautomationU than anything else in that last 2019 episode.

Yeah , developer mindset - I have been automating for a decade now more or less, and my biggest mindset gripe is that a developer often says.

“But this is only test code, right?”

Is like the quickest way to get a blank stare. I prefer to think of it in terms of Debono’s Thinking Hats (citation to come) , rather than mindset, as that implies a mental disease almost, where as simply saying: “Putting on your salesperson hat”, is not an invitation to stop thinking, but rather to clear all bias and just reset the perspective.

Citation Original Source -
Easier to read version -

1 Like

“But this is only test code, right?”

I’ve been responding to these type of questions with

“You mean the code that decides if dev’s product code goes to production?”


Pure Gold Daniil.

I need to put this up on my twitter status now (runs off…)