Testing Profile: Darth Vader

Testing Profile: Darth Vader


(Originally published April 22, 2016)
A preface if you will, about how this blogpost came about and why I think it’s probably going to become a regular segment of my blog. I was tweeting with a few folks using the hashtag #TestingMovies. Which I kind of ran away with, and will keep using because it’s like free advertising for my blog. When I posted this tweet:




When my friend and peer responded with:



Which really got me thinking, what kind of tester would Darth Vader be? Granted, those that take things very seriously might find this line of thought juvenile, but as a lot of us are geeks, and many more of us like learning things from movies about our professions, I didn’t see this as juvenile at all. I took it as a challenge to understand and explain Star Wars in a way that might be fun and actually become a valuable lesson for someone learning how to test or how to break down a system and approach that system for testing. I believe I now have a response for my friend.

Let me set up the system for you. And a quick disclaimer.

I do not own or have rights to any of these characters. I am writing based on common knowledge and the genre. Please do not flame me Disney or LucasFilm – all characters and images are their property alone, and I’m not getting paid for this blog.

First we are going to equate the Force with the Code. And if you are a tester, or a developer, you might first think – “Yeah, that’s right… the Force is like the Code, that’s awesome.” And then your second thought is, “Heeeyyyy, what about the light side and the dark side?” And my response to that is, a difference of languages and your personal and philosophical beliefs can make one see a language as dark or light. Even the structure of the language or even how it was structured for the program could play into that. I’ve had many an argument about JavaScript and Java being the dark side, while others think it is C# or .Net – frankly, as a tester, you get exposed to nearly everything along the way. There’s no dark code or light code, just how you use it. (See what I did there?)

Which brings me to the point of this blog. Darth Vader is not a good tester. He’s not actually even a tester, he’s a testing tool. He’s a very manipulated, incredibly smart and ruthless testing tool that comes in and force chokes the crap out of the environment, i.e. the poor sod that doesn’t agree with him, using the dark side of the code, but he’s not a tester. He’s more like automation. He’s been told what to do, how to do it, but has some latitude on how to get those things done because he has parameters set by the real tester, Emperor Palpatine.

In the expansive system called the Empire, Emperor Palpatine is actually the real tester here, using Darth Vader as the one to seek out variables and identify them and bring them to him. The Emperor likes to keep things in line, in check, status quo. He has control over his domain, he knows the Force, both the light side and the dark side. He senses issues before they even hit his door, why? Because the Force/the Code has given him a heads up or Vader came and told him something directly, good or bad.

Then you might also argue that there’s a point where he does turn on Palpatine and tells him no, but that makes even more of a case for being a testing tool. Vader gave him negative response to a command, and then killed the tester. While most automation won’t kill the person running it, when it does throw errors or generally refuses to do something you know it could do before, it can kill a lot of time while you try to figure out what’s wrong with it and if it’s the automation having a problem or something with the system causing the automation to choke (Hah, get it? Choke. Yeah, I can hear the groans from here). Or, in this case, it might be another tester, like Luke, giving the automation new code and that caused the error/death. Based on some new theories about Luke, and his role in that last scene, this is a possibility.

There is one variable that isn’t explained here, and that’s the programmer. If the Force is like Code, then the programmer is crazy being or beings putting that code together. Or it’s just Disney and LucasArts/LucasFilm. Take your pick.

Let me know what you think, either here in the comments or comment on Twitter @melthetester
Suggestions for more testing profiles would also be welcome!

Comments

Post a Comment

Most Read Posts

Ready, Tester One? *GO!*

"I handed my passport to the immigration officer, and he looked at it and looked at me and said, 'What are you?'" - Grace Hopper (60 Minutes Interview) The Grace Hopper quote above always makes me think about my job as a tester. Companies that develop software know they need testers, but they generally have hard time figuring out what testers are and what skills they need in the role. There have many discussions about how testers can be more technical and at some point, coding comes up in the conversation. My response on twitter contained a few things on a list I have, which I created for a client, so they could have a checklist of skills. This checklist was a guideline to determine the skill level of the tester applicant. This is by no means a complete list and I would be open to additions to the list. Feel free to add those to the comments or tweet them to me. For clarity, I took the list of skills I had and broke them into levels. I like games and I lik
Read more

Learning From Failure: The Tricky iOS Environment

"You build on failure. You use it as a stepping stone. Close the door on the past. You don't try to forget the mistakes, but you don't dwell on it. You don't let it have any of your energy, or any of your time, or any of your space."  - Johnny Cash There are times when our work, as a team, as testers on a team can give us insight into how we can improve things for the overall success of the product. Often those things are issues or defects which can present themselves at the most inconvenient times, in the most inconsistent ways. When we can learn from them and improve things for everyone on the team, the team benefits. When the team owns the defects and the testing strategy, not only the testers, then customers benefit as well. I was working remotely verifying a release and only had simulators and emulators to work with as I was testing mobile builds. Often folks mistrust builds which only use emulated software and not real devices for fairly good reasons
Read more

Postman In The Pipeline: Newman Delivers

Image
  It's not me, it's the songs.  I'm just the postman,  I deliver the songs....  - Bob Dylan Recently, I've had the chance to work on a project with some other awesome folks which has involved creating a BFF - A back end for front end service. This allows the app to access several API and aggregate calls into something the app can use, or lets the app send information to the BFF for several APIs to receive. Part of the code coverage for the BFF was creating some simple tests with Postman around the business logic and interactions. Learning About Postman I did lots of reading. Lots of reading how others has done things (Danny Danton - big props for being a super help!). Eventually, I came down to a small set of tests which could give us some accuracy about our BFF pipeline and the APIs we were accessing with it. Postman has a couple of options for this, global variables, environmental variables, and plain variables. One of the first problems I came across w
Read more