Dammit Jim, I'm a Doctor not a Software Developer!

Let’s face facts people, we aren’t all cut out to be doctors. And like wise we aren’t all cut out to be coders, software testers, or CEOs. It takes a certain set of skills, arguably different mindsets for each. 

We are told regularly that AI and Expert Systems might be poised to replace aspects of all professions, medicine included. Should we then be telling our already overburdened medics that they need to learn to code in Java or they’ll be obsolete in a few years? A quick prediction, I don’t think there are going to be queues of Consultants and Surgeons lining up at the Job Center any time soon.

Yet, we are all seeing pressure for brilliant and creative career software testers and business domain experts to learn to code or face limited career prospects.

I was told recently about a conversation between a colleague and a somewhat forlorn but brilliant career software tester who was trying to learn Java and Selenium. Which went something like this: 

“Do you enjoy coding?”

“No, not really”

“Why do you do it then?”

“I have to learn automation to progress in my career”

Learn to Code. That seems to be the only response to the challenge of increasing demand for test automation across the industry. Are we setting unrealistic expectations on career software testers to become “Ninjas”, to meet ever growing functional automation demands? The bottom line is we aren’t all cut out to code, and I’m 100% certain we aren’t all cut out to be good software testers either (or perform surgery for that matter!). 

Let’s take a step back and recognize the career discipline of software testing and the domain expertise acquired, it involves training, experience, talent and creativity in equal measure. Don’t get me wrong, there are plenty of individuals who cut a pretty adept path in both camps, the black-belt “Ninjas”. Hats off to you guys and girls, you are the Surgeons who can knock up a perfect promise-aware JavaScript class (I’m sure they exist!). 

I’ve spent the last few years getting elbows deep in JavaScript, and it took some serious getting used to. Hours staring at syntax that I thought had clicked the day before and bam, an exception or a rejected promise. Something unexpectedly got executed before something else on the queue and it’s back to the drawing board. “Rejected promises…” it seems poignant somehow. It still bites me regularly. It’s fickle and unforgiving. 

(FYI - here’s my background: I wrote my first Sinclair BASIC game at the age of 10 and have been coding pretty much every school or working day since then, along the way picking up a degree in Computer Science. I’ve written Assembler, Pascal, LISP, C, C++, FORTAN, PL1, REXX, COBOL, Z and AMN specs. I’ve automated tests in WinRunner Pseudo-C, VBA, QTP VBScript, Java and C#. More recently C#, Java and JavaScript have dominated my day to day. Probably about 30+ years all in all. And despite all those battle scars, JavaScript and its ecosystem still presents a world of befuddlement!)

So why the potted resumé? Well I’m saying I can empathise somewhat with those trying to make the leap from UFT, its comfortable IDE and quirky VBScript to the murky world of modern asynchronous development languages, package managers, transpilers and what-not. “Where’s the record button again?”. Worse still for career software testers and domain experts trying to make the same leap with no coding background. Some are having fun rising to the challenge, others are worried or damn miserable. 

Here’s the rub. We’ve been facing the exact same challenge in test automation since the heady days of XRunner and ATF. Probably about 25 years give or take, trying to mash up the role of career software tester and coder in order to deliver automated tests. There have been some attempts at addressing the dilemma over the years: Capture Replay (the industry’s most deceptive sales gimmick!), data driven test approaches, keyword frameworks, more recently tabular ‘Script-less’ automation tools.

 Well let’s take this up a gear. 

How about a web platform that can help decipher some of the nuances of coding Selenium JavaScript (if that’s for you), or just have fun using a visual, drag-drop canvas environment to contribute working JS Selenium tests to the automation codebase? 

Take a look at www.scriptworks.io it might just be your next step on the Shaolin Way!