Saturday, November 26, 2016

The Domain Is The Thing!


 “Time is a game played beautifully by children.”
― Heraclitus, Fragments


I had an interesting experience this weekend. A friend of mine contacted me and asked for some ideas to help her daughter learn about testing video games.

Think about that for a minute. I've had a lot of kids, including my oldest nephew ask about game design and creating video games, but my friend mentioned testing. Testing as a career. Testing as something that happens with a technology genre most kids are introduced to first.

Games and tech have had a long marriage and they have shepherded many a child into the tech industry with ideas of creating or designing games for the next generation of kids.

This isn't a new thing either. A friend of mine from my second grade class showed me game designs he had created on paper after I had shown him some of the stuff I was writing. We were 9 years old. Personal computers were barely an idea then. I know he was talking about the Atari or arcade games, but still, he was really sure of what he was going to do. I think I wanted to be a nurse, much like my mother. I don't know what he grew up to be, but I ended up being more drawn to computers and technology that I ever dreamed of at that age.

Finding Your Domain

These are suggestions for any tester who is asked the question, how do I get into an industry or area of knowledge and how do I test it. (This could also help with a career day if you volunteer to present for your child's class.)

Here were some of my suggestions:

- Study things outside of computer science like art, anthropology, psychology, history, music or even politics. Games have such a wide range of topics and ideas these days anything could be applicable.

- Computer science is always a good sector, but in the world of games, understanding graphics, design and design elements are a huge help, even if you are only involved in the back-end code.

- Graphics engines, monitor/display types and resolutions, basically any hardware you can find out about and a game could be played on. The more you know about it, the more you understand.

- Read technical magazines about game styles, gaming tech, gaming computers, basically anything that would collect information about not only opinions on the game play, but opinions and information about the hardware the games are meant to be played on.

- Fastest way to learn code is to do it.

For kids, I generally suggest to parents the Kano. It's a great little computer module based on Raspberry Pi and includes a lot of great visual content that allows users to "code" in a more visual manner. Adults can use it too, but it's definitely a good place for kids to start.

For adults, I have been suggesting FreeCodeCamp.com - you are walked through the basics of what you would have to do to be a full stack developer. When you have completed the challenges, you have about 400 hours of development time under your name, along with projects you create along the way.

Understanding Your Domain

While some of this is domain specific, you can certainly apply them to basically any software development job your child could ask about. Technology and science are so vast and specialized these days, most topics or domains have a lot of journals, articles, blogs and even TV shows dedicated to the topics. Encourage them to find their favorites and learn.

Half Way To Testing

After your youngling does all of the research and understanding they could possibly manage, they can research testing.

Testing to me is like the icing for the figurative cake of development. It covers the cake and depending on the cake, it's in-between the layers too. All the reading and research informs you how various things interact between each other.

From the processor to the graphics cards, knowing about what is interacting with the software at a given time, and when, can give you a lot of ideas to test a video game, and that's just the functional parts. Apply that to other domains and you can easily see how this knowledge can inform testing. 

This is the VALUE that testers bring to the table every time. When you know even a hint of something about the area you are working in and use that to inform your testing, you can be an extremely powerful member of the team testing the software or hardware. 



Even answering a question about game testing could lead them to do amazing things which their technical skills will have been honed for from an early age. The idea of this makes me excited for the future of testing and what the next generation of testers will be doing.

Sunday, November 13, 2016

Test Bash Philly 99 Second Talk - Leap, Don't Look

Credit: Jeffrey Veregge - http://www.jeffreyveregge.com

Leap, Don't Look 

Superheroes have to start somewhere.

They learn over time.
They have complex stories.
They do things at times we all wonder about.
They do things we wish we could do ourselves.

A short time ago, 
I wished I could write more, 
I wished I could speak more, 
I wished I could learn and grow my skills.

I did a lot of wishing. 

I wished for people to understand my viewpoint, 
or at least give me credit for the good ideas along with the dumb ones.

I wished my life was more interesting than it was.

I wished.

One day, I stopped wishing and I did.

It was a small step. 
Just a tiny one. 

I wrote an essay for a contest about how much I loved Ministry of Testing and Test Bash.

In two years, I've gone from wishing to doing. 
I've traveled more, 
I write more, 
I've learned more and continue to do so.

So Leap, don't look.
Do, don't wait.
Don't let fear of failure and what if's stop you.

Be your own superhero.

Testers thrive on doing the impossible, 
testing the edge cases and the boundaries,
finding the mysteries in the black box.

If you aren't doing the same thing in life, 
even in the smallest way, you might be missing a very significant part 
of why you are a tester in the first place.

Tuesday, November 8, 2016

Mel's Rant: Non-technical Testing Is An Oxymoron

"The true delight is in the finding out rather than in the knowing." - Isaac Asimov


Somewhere in the the distant past, like a decade ago, manual testing wasn't considered non-technical. It was actually considered to be a very technical job in which someone doing the testing had to understand computers, operating systems, command line syntax to access everything from the directory to error logs, and a million other things that started appearing in the computing ecosystem.

Fast forward to present day, manual testers everywhere are being called non-technical because they don't practice automation on a regular basis. 

When did understanding computers become a non-technical thing? 

We don't call business analysts non-technical. They produce technical writing and information necessary for developers and testers to understand how code is supposed to be created and work. 

We don't call customer service reps non-technical. They deal with customers that are even less technical savvy than your average four-year-old on a daily basis. They manage to bridge the gap between the "helpful tips" people get from their computers and the internet and the compatibility issues each system presents that they interact with. They have to know how to get to log files, operate a command line, understand where to find different parts of browsers including subtle differences between versions. 

Why has the notion persisted that manual testers are not technical? All testing starts with a manual effort, no matter who does it. 

The conversation we should be having is level of technical ability. If you can demonstrate a technical acumen, especially if you start off in testing and go into a business analyst role or start in a customer service background and go into a tester role, then you are technical. Your technical abilities should be based off of your skill set, and what you can do. 

The other part of the argument often is that anyone could read test cases and testing scripts and test an application or hardware. 

I don't think this is the case. Maybe in another ten years when we've all lived with computers from birth, then maybe that argument might be valid.

I think (the thought is based on conversations not actual proof) the idea comes from the game testing realm. Companies like Blizzard and Zynga hire testers who play the games. They don't necessarily hire testers to actually think like testers. But, they are still technical. They know the games better than anyone. They often they know them well enough to understand where the gaps are in the game, what breaks it, and what hardware is the best to run various games on. If that's not technical knowledge, then I'm not sure I understand the definition of technical. 

I've heard time an again that folks in a game testing role are not technical. I think that's an excuse to pay someone $12 an hour instead of a real wage. Unfortunately, the rest of the industry has bought into that idea.

I was phone screened by Zynga once. They were interested in having me as a tester. I described what I did and they went silent for a moment. The person on the other end spoke again and said that I was too technical for the QA role. I might make a better fit as a manager or a lead. I was surprised considering I had been a tester less than a year at the time. 

Their business model and practice requires a large amount of manual testing. That might have changed, but I doubt it. Because of the graphical nature of most games, manual testing will always necessary to companies in the gaming industry until they figure out how to automate random, interactive, graphical responses (which might or might not happen with machine learning - but we have to wait and see). 

I've interviewed with other places that have given me the equivalent of a developers test and was told I wasn't technical enough to be hired in as a QA. That's OK too. 

I am a coder by rote. I mimic patterns and copy/paste with the best of them. I have some fundamentals but I don't practice them often enough for me completely avoid running to the internets to look things up. I at least I know where to find answers and usually what they are for. It's often been good enough for automation. It's maybe not good enough to start an automation framework by myself from scratch, however, I'm working on it. I'm getting better. Maybe at some point I'll be able to set up and tear down a whole infrastructure by myself with an automation framework and all the goodies included. Those are goals and I'll get there in time. I have faith in that.

This  the conversation we should be having in the industry as testers, and with people who are also in the industry but are in other roles is: where your technical skills are at? Not Are non-technical or technical, because computers are inherently technical, period. The idea that you would call any position in a software development organization non-technical is crazy pants! Testing, even manual testing, is a technical endeavor. It might be the foundation of the testers skill set, much like using an IDE is for developers, but it's still a skill. And it's a technical one.