coding | Cutting Edge Computing

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

Posted by Peter Varhol in Software development, Strategy.
Tags: Agile, coding, testing
1 comment so far

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.

Another Old Line Conglomerate Gets It Wrong August 4, 2016

Posted by Peter Varhol in Software development, Technology and Culture.
Tags: coding, GE
add a comment

I seem to be taking my curmudgeon role seriously. Today I read that Jeff Immelt, longtime CEO of industrial conglomerate GE, says that every new (young) person hired has to learn how to code.

So many things to say here. First, I have never been a proponent of the “everyone can code” school. No, let me amend that; everyone can probably learn to code, but is that the best and most productive use of their time? I would guess not.

Second, I’m sure that in saying that Immelt has put his money where his mouth is, and has gotten his own coding skills together. No? Well, he’s the boss, so he should be setting the example.

This is just stupid, and I am willing to bet a dollar that GE won’t follow through on this idle boast. Not even the most Millennial-driven, Silicon Valley-based, we’re so full of ourselves startup tech company would demand that every employee know how to code.

And no company needs all of their employees to be spending time on a single shared skill that only a few will actually use. GE needs to focus on hiring the best people possible for hundreds of different types of professional jobs. It may be an advantage for all of them to have some level of aptitude for understanding how software works, but not coding shouldn’t be a deal-breaker.

I have worked at larger companies where grandiose strategies have been announced and promoted, but rarely if ever followed through. This pronouncement is almost certainly for PR purposes only, and will quietly get shelved sooner rather than later. And making such a statement does no credit whatsoever to Immelt, who should know better.

Software Testing is a State of Mind July 2, 2015

Posted by Peter Varhol in Software development.
Tags: coding, skills, testing
1 comment so far

I was prompted to write this by yet another post on whether or not testers should learn to code. While it gave cogent arguments on both sides, it (prematurely, I believe) concluded that testing is a fundamental skill for testers, and discussed how testers could develop their coding skills.

The reality is much more nuanced. There are different types of testers. An automation engineer is likely to be coding, or scripting, on a daily basis. A functional tester using an automated testing tool (commonly Selenium, or perhaps a commercial one) will write or modify scripts generated by the tool.

And in general, we try to automate repeatable processes. Often this can be done with customizable workflows in an ALM product, but there might be some amount of scripting required.

But while coding knowledge can improve a tester’s skill set, it’s not required for all roles. And sometimes it can detract from other, more important skills. That got me to thinking about the unique skill sets of testers. There are unique mental and experiential skills that testers bring to their job. The best testers intuitively recognize the skills needed, and work hard to develop them.

Curiosity. Good testers do more than execute test cases. They look for inconsistencies or incongruities, question why, and don’t stop looking for improvements until the software is deployed.
Logic and Discipline. Testers do very detailed work, and approach that work in a step-by-step logical fashion. Their thought processes have to be clear and sharp, and they have to move methodically from one step to the next.
Imagination. Testers understand the user personas and put themselves in their role. The best can work through the application as both a new and experienced user, and find things no one ever considered.
Confidence. Testers often have to present unpopular points of view. If they can do so while believing in their own skills and conclusions, while also taking into account differing points of view, they can be successful voice of both the user and application quality.
Dealing with Ambiguity. It’s rarely clear what a requirement says, whether the test case really addresses it, whether an issue is really an issue, and what priority it is. Testers have to be ready to create a hypothesis, and provide evidence to support or reject that hypothesis.

These tend to be different skill sets than those possessed by coders. In particular, many coders tend to focus very narrowly on their particular assignments, because of the level of detail required to understand and successfully implement their part of the application. Coders also dislike ambiguity; code either works or it doesn’t, it either satisfies a requirement or it doesn’t. Computers aren’t ambiguous, so coders can’t write code that doesn’t clearly produce a specific end result.

Coders may argue that they produce a tangible result, source code that makes an application concept a reality. Whereas the work product of testers is usually a bit more amorphous. Ideally, a tester would like to say that software meets requirements and is of high quality, in which case few defects will be found. If testers write many defects, it’s interpreted as negative news rather than a desired result.

But organizations can’t look at testers as second class participants because of that. Testers have a unique skill set that remains essential in getting good and useful software into the hands of users. I don’t think that skill set has been very well documented to date, however. And it may not be appreciated because of that.