Although I'm a doctor, not a writer, I think Bones would allow me this homage to the prop known as the Biobed Monitor given his reliance on it during times of crisis on board the Enterprise. While the hand-held tricorder has always been the more popular medical device, Biobed Monitors have actually appeared on-screen more frequently over the years, serving an important technological and dramatic role in every incarnation of the franchise. Leonard “Bones” McCoy’s Biobed Monitor was the precursor to modern advances in non-invasive patient monitoring and diagnosis. McCoy operates with help from his trusty Biobed Monitorįrom cell phones to virtual reality, we've heard a lot about the Star Trek universe’s influence on real technology. Brett's article features a very cool piece that spanned two decades of use in various Star Trek productions. 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.Today's special guest blogger is Brett Leggett, a life-long Star Trek fan and avid collector of screen-used Star Trek props and costumes.
#Dammit jim i ma doctor software
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. We’ve been facing the exact same challenge in test automation since the heady days of XRunner and ATF. Some are having fun rising to the challenge, others are worried or damn miserable. Worse still for career software testers and domain experts trying to make the same leap with no coding background. 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. And despite all those battle scars, JavaScript and its ecosystem still presents a world of befuddlement!) More recently C#, Java and JavaScript have dominated my day to day. I’ve automated tests in WinRunner Pseudo-C, VBA, QTP VBScript, Java and C#. I’ve written Assembler, Pascal, LISP, C, C++, FORTAN, PL1, REXX, COBOL, Z and AMN specs. (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. “Rejected promises…” it seems poignant somehow. Something unexpectedly got executed before something else on the queue and it’s back to the drawing board.
Hours staring at syntax that I thought had clicked the day before and bam, an exception or a rejected promise. I’ve spent the last few years getting elbows deep in JavaScript, and it took some serious getting used to. 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!). Don’t get me wrong, there are plenty of individuals who cut a pretty adept path in both camps, the black-belt “Ninjas”. 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. 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!). That seems to be the only response to the challenge of increasing demand for test automation across the industry. “I have to learn automation to progress in my career”
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.
#Dammit jim i ma doctor code
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. 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. We are told regularly that AI and Expert Systems might be poised to replace aspects of all professions, medicine included. It takes a certain set of skills, arguably different mindsets for each. And like wise we aren’t all cut out to be coders, software testers, or CEOs. Let’s face facts people, we aren’t all cut out to be doctors.
0 kommentar(er)
