The Automated Tester

Write. Code. Automate.

In the last couple of years I’ve seen a huge spike in demand for people who can write, code, and automate their own acceptance tests. I call these folks
automated testers. Not only do these people automate their own tests, they also do their own analysis and enjoy talking with customers.

In this talk I would like to explore the role of the automated tester, show how it is different than traditional Quality Assurance (QA), and share a few ideas on how to get there.

Software is eating the world

In his seminal article, Software Is Eating the world, Mark Andreesen makes a strong case for how software is taking over huge swathes of the modern economy and eating the world. Amazon. Apple. Google. Twitter. All these companies are building highly defensible, highly profitable businesses, with software at the heart of what they do.

This is great for the disruptors, but painful for the incumbents.

• Amazon killed Barnes and Noble.
• Netflix ended BlockBuster.
• And AirBnb and Uber are redefining the meaning of hotel and taxi.

And it’s not just companies that are getting disrupted. It’s people.

With the rise of Agile, and the popularity of running projects with a more entrepreneurial startup spirit, traditional software development roles are being challenged. None more so than traditional QA.

Everyone is a tester

Today everyone is a tester.

• Analysts test.
• Developers test.
• Designers test.
• Customers tests.

Everyone tests. Quality is no longer the sole domain or responsibility of a single group or entity. It’s a team responsibility. And that’s a big change for the traditional tester. Everyone is in their house.

This wouldn’t be a big deal if testers could show up on a project, be given a well written spec, and then be left alone to create comprehensive test plans to be executed every time someone changed the software. But those days are gone.

That role doesn’t exist anymore.

So if analysts are testing. And developers are testing. What’s traditional QA doing?

Leveling Up

I see two options. Traditional QA can dig in, defend their turf, and fight for the mantle of sole custodians of quality (in other words try to keep the status quo). Or they can branch out and get into analysis and development they way BAs and dev’s have gotten into testing.

To do this, the trick is to stop viewing analysis, development as testing as siloed roles. These are things that need to be done. Who does them doesn’t really matter.

I know many testers who are wonderful analysts. They bring an attention to detail and outside the box way of thinking that’s invaluable in flushing out requirements and necessary for doing thorough analysis.

I also know testers who are great at automating their own test cases. I don’t mean simple click and record playback bloat ware. I mean actually getting into code, using open source frameworks like Watir, Selenium, Cucumber, and RSpec.

By expanding their skills and getting into these other areas testers can quickly become doubly valuable on projects. Not only can do their own analysis and write great acceptance tests. They can code them up, verify things work, and reduce their reliance on developers for automation.

Shorter queues. Fewer handoffs. Less waste. More value.

Don’t let yourself be limited by yesterday’s job definitions.

Enter The Automated Tester

This is where the automated tester comes in. These are testing experts with a passion for business and a thirst for automation.

They like knowing the business because it helps them write better test cases. And the more they automate, the more time they have for edges cases and exploratory testing.

They also like technology because a good understanding of the tech gives them insight the limits and capabilities of their testing frameworks.

The experienced ones know they can’t (and shouldn’t) automate everything. Every test has a cost and they think carefully about what to automated. They also work closely with developers to to see what unit tests the developers have written and make sure they aren’t duplicating effort.

And of course they still love exploratory testing. Automation is fine. But it’s not perfect. To truly be effective you still can’t beat the intuition and creativity that comes from firing up the browser, clicking through the app, and looking for ways to bust things along the way.

Getting there

Now if all this sounds easy – I assure you it isn’t. This is a tough, demanding role. You’ve got know the business. You’ve got to have a passion for automation and technology. And you have to enjoy continuously learning and retraining yourself.

But it’s a huge opportunity. It’s an invaluable role and one I think we are going to start seeing a lot more demand for in the near future.

Here are some ideas on how to get there.

1. Build apps.

You don’t have to be a developer. The goal is to get just deep enough to understand at a high-level how things work.

If you are testing web apps, you should know how HTML/CSS and JavaScript work. If you are building iPhone applications, you should have XCode and be really familiar with the emulator.

Did you know, that if you build a simple app holding a table with some numbers from a database, you’ve basically replicated 99% of the business applications being built today!

Building simple apps and understanding the technology is going to give you insight. Insight into how these testing frameworks works, their limitations, and where they need to be abandoned.

2. Master one testing automation framework.

There are a lot of automated tested frameworks to choose from. Don’t sweat it. Just pick one. Learn it really well. Then move onto another.

They all work pretty much the same, and once you’ve got one figured out they all work pretty much the same.

If you are testing the web, start with Selenium. Then try Watir, RSpec, Cucumber, or whatever else your team likes. If you are on the iPhone try Frank. The framework doesn’t really matter. Just pick one and go.

3. Hug a developer.

A good developer can be your best friend. The good ones are already doing what you getting into and the best will be more than happy to show you how it all works. They can set you up, help get you going, and even augment the frameworks you are using by making them easier to use.

Study what they do. Learn how they set things up. And soon you will be able to do it on your own.

4. Automate everything.

I know I just said the good tester don’t automate everything before their eyes, but in the beginning you should try, just to get the practice and see what’s possible.

You are going to write a lot of bad tests when you first start out. Don’t worry about it – we all do. Just automated everything you can, and you’ll soon start to get a feel for which tests add value, which ones don’t, and where to draw that line.

5. Fear nothing.

It’s going to be scary when you start (I am talking to you traditional QA testers). You are going to be leaving a space of traditional, comfort, strength, and responsibility, and entering something completely foreign and new. I’ll let you in on a little secret. It’s like this for everybody.

Developers go through this every time they learn a new language. BA’s go through it when learning a new business domain. And PMs go through it when they drop the Gantt chart in favor of the burndown.

You have nothing to fear. Everyone is going through it. Just be humble. Ask for help when you need it. And you will fit right in.

One challenge

One challenge of becoming an automated tester is people are going to look at you a little bit funny. Companies don’t like things that don’t fall neatly into slots, and you are going to be an anomaly.

You are going to go to conferences, explain what you do to people and they are going ask:

So are you a analyst, tester, or developer?

Conferences, papers, titles, pay scales, expectations, and bodies of knowledge are not going to be ready for you. Nobody is expecting you to work like this. We’ve got 50 years of history working against us. But it’s like that for the pioneers.

All I can say is hang in there. Do whatever feels right. Start slow. Start fast. Look for the opportunity and seize it when it comes.

In the meantime practice, be prepared, and keep taking on more responsibility. Once you demonstrate the value this role brings (through action – not words) project managers will soon be getting into fist fights for your services, and you’ll have the freedom to contribute however you wish.

Remember the goal isn’t to test or even build great software. It’s to build something wonderful for our customers. And you are just doing whatever it takes to make that happen.

Summary

There’s a new role for testers out there. One that blends the art of traditional testing, with analysis, development, and automation.

If you have a passion for testing, are curious about technology, and are looking for more ways to contribute to your project, consider becoming an automated tester. It’s an exciting role, one that every Agile project needs, and one I hope we see a lot more people entering in the near future.

Advertisement