Cutting Edge Computing

Should Testers Learn to Code?  The Definitive Answer September 23, 2020

I came across this fundamental question yet again today, and am long since weary of reading answers.  Those who ask the question are predisposed to a particular answer (almost always in the affirmative).  Tired of the mountains of answers that are there to be climbed, I decided to cogitate on the definitive answer for all time, to bury this question in the sands of time.

Before my answer sends gravity ripples across Known Space, let me say that I like to take contrarian viewpoints when possible.  A few years ago, my friends at TestRail published a blog post on the topic, and I responded with my own post entitled “Should Coders Learn to Test?”  Regrettably, my levity was not well received.

The answer to the fundamental question, however, is yes.  It’s clear that in a world without constraints, testers should learn to code.  More knowledge is always better than less, even if the value of that knowledge is indeterminate at the time it is acquired.

But we live in a world of constraints, whether it be time, other alternatives, inclination, aptitude, or other.  These constraints are almost always a deciding factor on the actions we take in navigating our professional lives.  How we respond to those constraints defines the directions we take at various points in life.

Is it possible that not learning to code can have detrimental effects on testers in both the short and long term.  If team and management expectations are that they provide the types of error detection and analysis that assumes an in-depth knowledge of the code, then does not have the skills or inclination to do so penalize their standing with the team and their career prospects?

But it is just as possible that other knowledge could be just as effective in project and career success.  Testers may be experts at the domain, and be able to offer invaluable advice on how the software will really be used; they may write the best documentation; or have the best problem-solving skills.  Yet culturally we denigrate them because they can’t code?

I’ll explore that thought later in more detail, but it occurs to me that we as software professionals are more or less stuck in an Agile-ish way of thinking about our projects.  We bandy about terms like Scrum, sprints, product owner, Jira, and retrospective as if they magically convey a skill and efficiency on the team that was not there in the past.  And we truly believe that Agile team members don’t specialize; we are all just team members, which enables us to do any task required by the project.  I would like to question that assumption.

I casually follow American football during the season, and listen to the talking heads praise coaches (Scrum masters???) such as the New England Patriots’ Bill Belichick for adapting to the strengths of his individual players, and designing offensive and defensive strategies that take advantage of those strengths.  In contrast, many other coaches seem to fixate on their preferred “systems”, remaining in their comfort zones and forcing the players to adapt to their preferences.  In many cases, those coaches don’t seem to last very long.

Continuing that analogy, can we adapt our project teams to take advantage of the strengths of individual team members, rather than always force them into an Agile methodology?  Perhaps we need to study more about team structure and interpersonal dynamics rather than how to properly formulate and carry out Scrum.  Let’s use our people’s strengths, rather than simply use our people.

<To be continued>