I spent a significant amount of my career in the role of a dedicated testing specialist. I worked at Microsoft leading a variety of cross-company initiatives when we had 10,000 testers at the company. We worked closely with development teams and, at the time, made a difference in product quality. For most of that time, developers generally did a small bit of testing, but our test teams performed the vast majority of all testing efforts, including extensive suites of verification tests enhanced with a flurry of diagnostic tools and a healthy dose of exploratory testing and investigation.
Somewhere in my tester journey, Microsoft moved from a mix of testers with and without programming experience to a model where all testers knew how to program, and I was a fly on the wall when we came up with the title for the infamous SDET role. There were many good (and some not so good) reasons for this move that are outside the focus of this post. One thing I remember from some folks opposed to the move was a notion that testers who knew how to program could not do effective testing because they were “skewed” by their understanding of how the code works. The feeling of these people was that the testing mindset is separate from the developer mindset 🧠 – that if you had one, you couldn’t have the other.
My experiences showed a different story. While I certainly ran across testers who tried too hard to solve every testing challenge with code, most readily and easily took on the role of tester and did deep exploration and investigation in order to understand and evaluate risk. Often, as expected, they would write programs or utilities to accelerate their testing. Their programming skills didn’t hurt their testing – their programming skills enhanced their testing. The idea of a skewed mindset was a myth.
For the last several years, I’ve been working on teams without dedicated testers. While these teams often have a few folks (including myself) who have some responsibility for helping the development team do better testing, the developers are responsible for fully testing their code – not just for functional correctness, but for all aspects of quality.
A few people have stated to me recently that developers are unable to perform testing because “they lack the mindset for skilled testing”. This statement – like the statement I heard many years ago about skewed mindsets is flawed and incorrect.
🧠👉 Watch this live webinar recording: Mindsets, Skill Sets, and Developers that can Test 👈👨💻
Mindsets and Skill Sets
Some voices in software development believe that building a product demands a certain mindset, while testing it demands a different mindset.
The book, Mindset by Carol S. Dweck says that mindset shapes how you learn and relate to others – and states that you have one of two mindsets – a fixed mindset, where you believe your abilities are unchangeable, and a growth mindset, where you believe the abilities you’re born with are a starting point for learning and advancing.
Peter Drucker coined the term, knowledge work to differentiate work that requires problem-solving and critical thinking from rote factory work. Authors such as Daniel Pink (A Whole New Mind) have elaborated on the impact of creative thinking in knowledge workers.
Software development and software testing are knowledge work. Both require multiple skillsets, constant learning, and problem-solving. While developing and testing software may require different problem-solving approaches or skill sets, they are both part of the same (growth) mindset, and the best people I know in software can switch between their development/builder and tester/investigator skill sets rapidly and fluidly. While I agree that it’s not easy – with deliberate and frequent practice shifting between these skill sets, most knowledge workers I’ve worked with can – and have become quite successful in developing this flow.
The Creators Skill Set
I studied music composition as both an undergraduate and graduate student 🎶 Like building applications and writing, composition requires creation, bound by rules – which are sometimes intentionally broken in order to achieve the creator’s intent – as well as deep analysis and evaluation. As a composer, I constantly had to switch from putting notes on the page to looking at the passage or entire piece as a whole to make sure it achieved my intent. This analysis ranged from verifying notes and voicing were correct to examining every nuance of dynamics and orchestration. Like all metaphors, this one breaks down at some point, but composition skills require both creative (builder) and analysis skill sets (I took multiple courses in each), and the act of composition includes ample amounts of both.
For most of the last decade, I’ve spent a significant amount of my time helping developers expand their testing knowledge. I’ve watched hundreds of developers grow their knowledge about testing, and then almost immediately apply what they have learned. To be fair, I’ve also seen them make many of the same mistakes that new testers also make, but they’re eager to learn and constantly adjust. Many of these developers are at least as good at testing as the best testers I know. With no prompting or mindset shifts, most find a way to fluidly shift from the microscope view to the 10,000-foot view and back again.
What I’ve found in nearly every case is that initially, developers lack the skill sets that experienced testers have mastered. I’ve also seen that developers are completely capable of learning a wide variety of deep testing and investigation skills. I’ve also found that teams where developers have testing skills deliver more quickly, more predictably, and with higher quality.
Making the Shift
I’m not advocating for any software team to eliminate the testing role (although I believe testing expertise is much more suited embedded into the team than in a dedicated test team). But I am firmly against the idea that developers shouldn’t do testing or can’t be good testers. I’ve proved that myth wrong dozens if not hundreds of times and colleagues in the industry have shared at least as many examples. Developers are capable of testing, can do testing and we should expect them to do testing. The expert testers of today would be well served by helping them learn and improve these skills.
We can start by recognizing that we’re all knowledge workers and that a big part of our job satisfaction and growth comes from learning and taking on harder and more challenging tasks. We should also recognize that software development requires a variety of unique skills, but not a change in mindset. We don’t all have to master every skill, but learning, growth, and skill development is something we all can do.
We just have to put our minds to it 😉
I challenge you to whip through this recording of a webinar I hosted last week and form your own opinions 🧠
