Automated Testing 101 - Swimming with Sharks
Tags: testing, automation, qa
Published: 2019-09-04 08:09:23

### Preamble
I'm starting a new series called **Automated Testing 101** where I will be covering the topic of getting a test automation effort off the ground & making it successful. This has been something I've wanted to write about for a long time and it all kind of kicked off based on my comment to [Steven Lemon's](https://medium.com/@steven.lemon182) post over on Medium about his development teams [Test Automation troubles](https://medium.com/@steven.lemon182/our-teams-troubles-with-hand-written-automated-ui-tests-cb189cbbff90).

### There's sharks in the water
Lets say you build cages for shark encounters...You and your engineering team understand the "perceived" dangers. All creation steps of the cages are done by hand. The testing of a cage's durability is conducted by hand also. You've heard some complaints from customers about the lack of durability of your cages but no ones been hurt by a shark as far as you know. But in the same breath from your business leaders you are told your engineering team/org needs to start building more shark encounter cages faster with higher quality. Then someone says aloud that we should _automate_ our engineering processes.

![Smiling Shark](https://media.giphy.com/media/d61HjTO829HXO/giphy.gif)

You might be saying, How the hell does this relate to software development? Like my fake shark cage engineering company, we build software products for people and have an idea of how the product should be used. We never fully know how our products are actually used. There are complaints about the quality of the product (bugs or missing features) and our business leaders always want something new or fixed faster.

[Fast forward] To meet the needs of delivering faster your software engineering team has implemented layers of automation around the development processes like continuous builds/deployments and infrastructure scaling. Now the business turns to the QA team and says the testing efforts are taking too long and slowing delivery. We need testing to be quicker and more accurate. So lets implement automated testing.

![More Sharks](https://media.giphy.com/media/QiCpt3n2WsZq/giphy.gif)

### Getting Started with Test Automation
**TIME**. The #1 reason given to a QA/Engineering team for implementing automated testing. #2 is **consistency** of test execution. Both of these bubble down to a belief that the bottle neck in software development lies within the QA team & their abilities to complete the necessary validation efforts [_this is a topic for another post. we'll go with it for now_].

So here is the deal with shifting a group from manual testing to automated testing that the business or engineering teams need to understand.

1. Manual testing will never be fully replaced by automated testing.

2. An engineering team can not become reliant on automated tests over manual testing for a long time until trust is earned by the automated tests by preventing and/or discovering issues.

3. Know that all current manual tests will not translate to being automated. There will be a need to rewrite or throw away some tests.

4. Automated testing should not just be UI tests. This could becomes a receipt for disaster.

5. Automated testing is not just owned by the QA team. The entire development team has just as much responsibility by making the platform developed consistently and accessible for automated testing.

6. UI tests can be flaky or brittle so they must be focused on testing the UI interactions and use the necessary business logic to drive the UI behaviors.

7. The kick off of a test automation project should start by defining the scope of test automation project that the engineering & QA teams will create [unit test, integration tests, API tests, UI tests, etc]. Google [Test Automation Pyramid](https://www.google.com/search?q=test%20automation%20pyramid) if you haven't yet.

8. The initial focus of UI automated testing should be around getting rid of the low hanging fruit [BVT, common UI interactions, etc] while you flush out your automation framework/platform of choice. And then target more advanced scenarios/tests.

9. Finally you'll have to figure out a way to show the execution consistency of the automated tests [aka Reporting] so you can show the business/team the value of all the efforts behind the project.

### Closing this chapter
Ultimately in software development, the customers and business leaders are the sharks. For each, you have to design and develop your products & testing approaches to keep your engineering team safe from being eaten alive while pleasing the hungriest of each species.

So, now that I've armed you with information and theory, are you ready to jump into your shark encounter cage of test automation? Hahah no you're not! Right now I've made you shark bait. You'll have to wait for Part 2 so I can start turning you into a fisherman & not food for the sharks.

![Shark Bait](https://media.giphy.com/media/My9BTPlUtvt3W/giphy.gif)


**Bonus: 10.** I don't do 10 Tips or Top 10s


_Credits_:
- Banner Image: [isango.com](https://www.isango.com/theguidebook/swim-with-sharks/)
- Shark GIFs: [Finding Nemo](https://www.imdb.com/title/tt0266543/)