Wednesday, May 25, 2016

Book Review - "Dear Evil Tester"

Book Review: "Dear Evil Tester"


If you are a tester, if you are a developer, if you just like really funny shit, you should read this book! 

Dear Alan Richardson,

This book had me laughing at my desk and my coworkers wondering if I had gone around the bin. I was enchanted by the sarcasm and wit, but drawn to the practical advice you had in your answers given with the Evil Tester persona.

I have favorites that I go back to and read on really, really stressful days where I need a laugh. I also find myself in the essay section as well, reading some inspiring stuff. I think the essay which most inspired me was "Unconventional Influences". When I get bogged down in my own self-importance, I remember that in the grand scheme, it's all my own bullshit that is plaguing me. It's good to question things, but it's also good to be open to the answers you get from the questions. Your essay reminds me of this all the time. Influence can be a double-edged sword. Used for good, it can be an amazing tool. Used poorly, and you might cut off your own head in spite of yourself.

I also like the recommended reading section, though Alan, lets talk seriously. Let see some love for a couple of other books like: "Agile Testing" or "More Agile Testing" by Lisa Crispin and Janet Gregory. Or "Explore It!:Reduce Risk and Increase Confidence with Exploratory Testing" by Elizabeth Hendrickson. (Really, I mention those as a counter-point to the ones you referenced. I'm cool with the ones you have already. Honest!)

And because book reviews these days need to have some kind of ranking, I'll give your book four out of five emojis. (I would say 4.5 emojis but giving half emojis doesn't work, have you ever seen half an emoji? Also, the fifth emoji is reserved for something epic and just EPIC. If I ever give something five emojis, I probably sold my soul to it or they own this blog, whichever happens first.)

Humbly blogging,
Mel The Tester

Sunday, May 22, 2016

Mel's Prediction Corner: Down the Road

"I reject your reality and substitute my own" - Adam Savage


One of the reasons I wanted to change the format of my blog was to open it up for more ideas than just discussing in fun and clever ways how movies can influence my work or how I look at my job as a tester in the field of software development.

I generate ideas. I love giving people ideas! It could be anything from a product modification to just suggesting what things might look like in 20 years. Some of them are like the flying car, they will probably never happen. Others though, might be reality later on. That's half the fun. I think it's one of the reasons I like usability testing and design. I have a chance to work with something and make it even better. Testing lets me do that in all kinds of ways and I think that's what appeals to me the most, the possibility to make something better than it was before.

Prediction corner are a few thoughts I have about what might happen in the near future. These are mostly just thoughts I put together based on things I've read. For me, it's kinda fun thinking about where things will be and how much will change.

In 20 years or less, GUIs and UIs in general won't exist as we know them today.

So, this is probably not as mind blowing as you think reading it.  We won't have them. Companies will either specialize in content or the interface, they won't be doing both. I predict that we will eventually buy devices that will present us with widgets that can run content from different sources. It won't have a UI of it's own because whatever device we have will be the UI. We are already trending towards this. Consoles do this to an extent. Chromebooks and mobile devices are almost there with their own OS with some or all content and services partially or entirely based in the cloud.

In the next 50 years, humans won't write code, we'll all be testers instead.

I've seen articles pop up in my email and twitter feed taking about the end of testing or the end of QA. I predict, that eventually, when AIs become a very stable and very affordable thing, people won't be writing software code. Design will be dictated to an AI, specified out according to business rules fed into the AI and then, tested, tweaked and tested again. I think testing and testers will be come even more important than developers and everybody in the software and hardware industry will move more towards testing methodologies and systems that support people testing computer/AI made products.

Knowing and understanding how functions and classes work won't be important. Making sure the "thing" works as needed and/or interacting with the AI writing the code will be paramount. What we are doing now as testers in this growing business could end up defining how we test things in the future. How people approach software development has already changed rapidly in the last 20 years. There might come a time when the difference between developers and testers will be moot point. When, not if, the AIs take over writing code, someone is still going to have to test it out. (3)



Reference Articles:
1)Microsoft opens Windows 10 to iPhone, Android apps
2)The npm Blog - kik, left-pad and npm
3)How Should We Talk to AIs? 

Wednesday, May 18, 2016

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!

Jurassic World: Waiting Until Development Is Done To Bring In The Expert

Jurassic World: Waiting Until Development Is Done To Bring In The Expert




(Originally Posted on Feb 26, 2016)
 While I was heading to Europe for the European Testing Conference, I had a chance to catch up on some movie watching. One movie that was on the list was Jurassic World. Ah the tale of woe that continues to be told from people messing with DNA that clearly should have been left to the prehistoric past.

Science is always exciting. Bones are cool, old stuff is cool, finding things are cool, until you realize that people work long hours in the hot sun and often don’t find the cool stuff for years. Treasure maps don’t exist in reality. But I digress. Back to the point of bringing up Jurassic World and why it involves testing.

“Domain Expert.”

You’ve probably heard this term used if you are anywhere near a development process or follow any number of processes that require the development department have domain knowledge or at least context knowledge of what they are trying to develop. Often, when you have people that are paying attention to the changes in the field they work in or are developing software for a field, they become experts by default, or over a period of time, learning as they go. Once you have enough knowledge, people generally regard you as an expert, or at minimum, someone that people can go to with questions and possibly get answers. Why, then, would a developer not ask questions?

The scenario in Jurassic World: Boss asks for new, bigger, scarier dino to be created. The scientist (aka the developer) takes advantage of this and creates a new, bigger, scarier dino and everyone was impressed. Until some factors were not considered and people start to die. The scientist (developer) combined DNA with properties they knew might have consequences, but decided that it wasn’t important to disclose those. The Boss (product manager) didn’t see the results until it was fully developed and then knew enough about what he was seeing to be worried and called in the Expert (tester or domain expert) to evaluate the project and give a report based on what he saw. The project manager (who is pretty much a manager type, but she obviously ran the show while the boss was legging it around the world), was excited the new project was on schedule and fully developed, ready for investors (aka – ready to ship according to the developer). Does this start to sound familiar?

I’m sure those currently working as independent testers might find themselves in situations where they are brought in at the 11th hour to assess a product. I know I’ve been placed in this scenario myself a time or two. When this happens, often testers or domain experts are seen as nay-sayers, or people holding up the development process. When real defects, which are very serious, like security issues, or behavioral issues are found, because development is already so far along, often those issues are not very well addressed unless brought up while the product development is still in progress.

When it was mentioned, by the expert, that the walls were too short and its mental development from infant to adult was not addressed correctly. The manager brushes it off and explains that they’ve taken precautions even while the dinosaur was trying to give them the slip. The expert was left in the awkward situation of trying to help with damage control rather than enjoying his job.

If a fictional world can prove that having experts associated in the beginning of a project could point things out sooner rather than later and avoid catastrophe, then why do people/companies/employers constantly wait until the last minute or exclude experts all together and ship to the public regardless? A factor might be the amount of risk associated with a project. I admit, when risk is involved, and measured, hopefully, there is more oversight for projects that deal with sensitive information or aviation or shipping toxic waste. I think people would be a lot more worried to discover that many of the things that go on around us are done without bringing in experts, or the experts are so rare that taking them from other projects to evaluate a new one or test it is deemed unnecessary because someone evaluated the risk and decided it is acceptable to them or that the impossible couldn’t happen. If you apply it to real life, you can see the impossible does happen – oil spills, lead poisoning via water sources, refineries located in flood plains that, surprise, become flooded, destroying whole towns. Or even Tsunamis taking out nuclear power plants.

Even worse, the expert or tester is brought in and then when they state their concerns those concerns are ignored or not taken seriously. This happened with the Challenger shuttle explosion and it cost seven people their lives.

Humans need oversight. We need to accept it and understand that while the impossible might never happen, planning for it or at least being aware of it is something the domain expert or tester can do. We present the risks and hope people follow through before it’s too late.

Though I have to admit, we might not have a whole genre of disaster movies if people paid attention to possible complications from the beginning.

Fun, excitement, a tester craves not these things....

Fun, excitement, a tester craves not these things....

(Originally published Feb 3rd, 2016)


When I first starting thinking about how I would tie in testing to the SW universe, my first thought was “testers are like Jedi”, but really, that's not true. We might start out like that. We are told when we first enter the business of testing that it's boring and repetitive. Expect downtime and figure out how to use it well. You need to learn about what you are testing as quickly as possible while you are testing as quickly as possible. But not too fast, lest you miss something. You start reading from the great masters, learning from the holocron of information available about testing. You take on the mantle of padiwan and develop a zen-like demeanor about all things testing. You develop a hero complex when people congratulate you for finding a high severity bug, bringing it to everyone's attention. It works for a little while. And then, you are seduced by the dark side.

Automation.

You have a master and they know that framework, the code, the very moment it will break. They read the error reports like a mystic and are able to fix them with lighting speed. You become enamored with this and write your first automation test. It's powerful, it predicts the future, it gives you an early warning system that something in your universe is about to change. You have more power over your testing environment and more feedback than you had previously. You can now test with abandon. Regression testing becomes a thing you barely trifle with. Defects are weak and meaningless to your overall sense of the universe. You feel yourself fill with knowledge and how to use it. Developers are swayed by your though-provoking suggestions. The old master leaves for another position seeing that you are ready to now be the master of your domain. You start training the next apprentice from the pool of test-jedi. The circle is now complete. Or is it?

Maybe when you started testing, it wasn't this information filled universe where the light side was encouraged. Maybe you were just given test cases with little explanation. You were told to look for defects and write reports because that's what your contract calls for. When a developer tells you they fixed a bug you found in the next patch, you exclaim that it's no good to you dead. You needed that bounty for your metrics report. You return to your mission, testing for other things to report. You contract out your skills to the highest bidder. You have your own opinion, but the sith lord in charge of the place barely acknowledges it. You follow orders though you do have resources and obligations of your own. Contract testing can be exciting at times, but it's more or less work you get paid for. Often, jedi-testers consider you and where you hang out a hive of scum and villainy. But that's not true. You're trying to make a living just like everyone else. Bounty hunting was never your original plan, but it's worked out so far.

Or did you reject the hokey religion for a good blaster at your side?

You sympathize with the tester plight and even take on the role for a time, but all the while you are learning the code base, figuring out how the database works, writing little hacks for yourself so you can set up your data faster, respond quicker, and develop habits that might some day get you out of this testing environment and into the real action, though what that is you can't quite say. You smuggle short bursts of code into master, sometimes with the help of another developer, sometimes not. You apply your skills, get your credits and move onto the next job. You easily deal with bounty hunters, testers, automation-sith, other developers and data miners, with a certain amount of swagger all while making plans for your big score. You're going to write a program that will change everything for you. Someday. But for now, you work with everyone, picking up jobs and stories alike. Retelling your favorite ones to folks who ask. Your reputation proceeds you for good or bad reasons.

Then your luck changes and this royal-person shows up.

Whether you consider yourself a prince or a princess, you have the power to influence everybody. You are a political dynamo. You have some testing under your belt and you might even know a little code and have written some, either for automation or for an actual program. You have all this knowledge of the real word, how things work, and who else has influence. You help with shepherding in a new version or a new vision of the software around you. Your ideals are lofty, and your goals and aspirations are just as high-minded. You learn that the universe of products can be a dark place, and sometimes you have to make compromises to survive and build your brand, but you hope that isn't always the case.

We all have different roles we take on at different times in the world of software development. Consider how you fit into the story. How your personal story changes over time should be considered in a career path and in your current position.

Hello Readers!

Hello readers!

I decided that while I have some nostalgia for livejournal, it might not be the best thing to use going forward. I also decided that I had boxed myself into this notion that I would only post about things relating to movies and testing. I decided I had more to say and I wanted something where I could write a blog post and not be so concerned that I'm not following my own strict format. I also know this is dangerous since that strict format has kept me from making hot-headed posts. (Me, hot-headed... phffff... LOL).

I'm going to re-post previous posts from LiveJournal here so that I there is a record, but going forward, I'll probably just post to here.

Hopefully this works out better for everybody!