Full Guide: Introducing The Web Automation Initiative to Your Organization and Team
Tags: testing, tutorial, motivation, architecture
Published: 2020-06-24 07:51:04

---
title: Full Guide: Introducing The Web Automation Initiative to Your Organization and Team
published: true
description: There comes the time that that you want to start your web automation initiative. That requires a quite smart deal of preparation. You have got to convince also your team that this is worthwhile .In the same manner you have to make the decision of which web automation strategy and which library or framework you should consider based on your applications use cases. Let us go over some foundational concerns to help guide that decision and effort.
tags: testing, tutorial, motivation, architecture
canonical_url: https://www.thehomeofwebautomation.com/foot-in-the-door/
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/yc0v3ewstx1bmilh4liz.jpg
---

>_This is not a post to discuss and compare the low-level capabilities of each web automation library or framework. Here we plan to lay out some foundational concerns that you should keep in mind when choosing the right tool for the job._

 __Enjoy__!

# Stepping with the "right" foot in the door for Web Automation

## Proposing a Web Automation Initiative 👔
There comes the time that that you want to start your web automation initiative. That requires a quite _smart deal of preparation_.

First you have got to convince your team that this is worthwhile.

In the same manner you have to make the decision of which web automation strategy and which library or framework you should consider based on your application use cases. 

Let us go over some foundational concerns to help guide that decision and effort.

## Getting In The Mood 🤖
The first best thing is that you arrived at the point of discussing something related to web automation 👏

In most discussions around web automation, especially when planning to introduce a new initiative or re-evaluate your technology stack, the topics that can quickly drive the discussions are __cross-browser compatibility, programming language API and community backing__ that available tools offer. 

>To not get confused here, by _browser compatibility_ we mean the range of available browsers a web automation task can run seamlessly on without any change required.

### Aim For Efficiency 🚀
For modern software products and businesses, __efficiency is a vital factor__. 

That makes it all the more important for us to be _pragmatic_. That means evaluate solutions that 
1. Minimize wasted effort 
2. Do just enough to complete the task at hand safely and with the expected quality levels

_For our context we need to pick the right web automation tool serving our own needs._

&emsp;\-_How many people in the team have experience with web automation testing ?_
&emsp;\-_Do we have to run the suite in different browsers ?_
&emsp;\-_Do we need to support Internet Explorer ?_

These are just some standard and common questions, but we will go over the process on how you can evaluate your requirements and tradeoffs even in more complex situations. 
__Let's go!__ 🏄

## Evaluating Your Reality
The first step for exploring the best possible solution is to __rule out the cases__ you do not even need to consider such decision. 

They are probably self explanatory but compiling down a table with rough estimations to get you out of this situation pretty quickly:

| Type of web automation task | What path to take |
| :-------------: |:-----:|
| Task that aims to automate otherwise manual labour. |  Pick the tool that you feel most comfortable with except if execution speed is important. If it is, probably <b>Puppeteer</b> or <b>Playwright</b> would be just fine. |
| Proof Of Concept for initiating an End To End testing initiative. | Go with the tool that requires less setup and needs the minimum amount of code to achieve the required use cases. You could go with <b>Puppeteer</b> or <b>Playwright</b> if you are into vanilla but <b>Cypress</b> would be my go-to here.  |
| Designing an End To End testing platform in an enterprise setting. | <b>Selenium</b> and <b>Selenium-based</b> frameworks would probably fit better as portability around teams and cross-browser compatibility is an absolute must for those businesses. |
| Generate PDF from a remote context on a user action | Speed is of the essence and you have all the control. In that case you can look into a solution like <b>serverless puppeteer/playwright</b>. |

_These situations as coarse grained as they might seem, can at least point you to a first solid direction. Efficiency metrics and team feedback will guide you for the rest of the decisions you have to make down the line depending on the path you chose initially._

## The Messy Middle of Web Automation 🌀
Since you reached this part of the article, means we can borrow this amazing phrase [Scott Belsky](http://www.scottbelsky.com/) to describe a common but certainly _messy_ situation you need to wrestle with. The _Messy Middle_. 

This phrase will be used to describe the state that at some point in time your web automation endeavors are bound to reach.

One of the characteristics of this state is [choice overload](https://en.wikipedia.org/wiki/Overchoice) 🤯

As browser technology is progressing rapidly, the ecosystem and available tools for web automation are growing along with it, especially in the _End to End_ testing league. The absolutely wrong path to take is start exploring the vast ecosystem without any guidance from you actual __goals, data and expectations__. These main drivers as you can understand are highly dependent on the scenario that brought you to this stage from the start.
 
This _Messy Middle_ most commonly can occur in one of the following scenarios:
- Trying to introduce the concept of End to End testing to a team (_or in a whole organization_).
- Re-evaluating the state of a legacy web automation codebase that bears the weight of time. _Flakiness, Configuration & Setup mayhem, takes hours to run etc..._

Above we list these two specific scenarios as they share the common requirements:
- _Low resource cost_
- _High impact_ 
- A _twist of wow factor_

In both cases you __absolutely need to convince and inspire your team__, that is why we need to invest up front on the things that matter.

### Look Further Into Requirements Not Options
As technologists, and software enthusiasts at that, we love diving in and analyzing a plethora of options that we have to solve a particular problem. It feels like a playground with thousands of toys to pick up and play. 

We want to try the latest, touch the bleeding edge and feel that we are joining the innovation march, __leaving expectations as an afterthought that we will tackle after we make our choices__.


\-_Should we assemble our own minimal framework or start with something like Gauge or WebdriverIO ?_
\-_Should we integrate tests using Cucumber or try it together with TestNG ?_
\-_Might it be a good case to try the Screenplay pattern ?_

At that time, which is bound to happen, take a step back and bring again into your mind the word __"Pragmatic"__. We are operating under the umbrella of a business and we have so many edges that our choices will have an effect on.

From our peers and seniors but finally to the customer, we ought as professionals to make our decisions as informed as possible. Not that the technology questions are unimportant, on the contrary, since they are important they should not be taken lightly.

### Gather Real User Data 👨‍👩‍👧‍👦
There is no better indicator about your real requirements than from the people that actually use your product.

For most use cases, the main difference you first need to consider is how _cross-browser compatible_ your solution needs to be.
</br>
![browsers](https://dev-to-uploads.s3.amazonaws.com/i/5c23mr8l15l0794l46sg.png)
</br>

You are trying to get a foot in the door but if the proposed path does not cover 30% of user technology specifications, it is not the "right" foot you are getting into with. It is totally reasonable to look for the option that would allow broader amount of coverage, but you have to act smart here, you need to base "broader" on something, which __is not 100% of the browser market__.

This step is skipped for most developers as they become allergic to step out of the comfort zone of _development tools_ 😥

Data analytics tools such as _Google Analytics_, can provide you with fine-grained information about which _browser/browser version/device_ combination your actual users are preferring to navigate your product with. 
</br>
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/6f42vqi92raaaixpco1i.png)

__Now you can start working your case with reality as your guide.__</br>
_Special Hint: Look also for the conversions/combination metric! If Internet Explorer users are just 5% but bring 15% of the conversions, it matters a lot!_

It will be clear as day that if your userbase is composed by a considerable amount of traffic from Internet Explorer, you should go for a solution that supports Selenium. On the other hand, if your application is mostly used on Safari, you should give Playwright its fair chance against Puppeteer.

Thankfully though, there are free and open source options that want to lift the burden of this choice from our shoulders as much as possible. Frameworks like [WebdriverIO](https://webdriver.io/) and [CodeceptJS](https://codecept.io/) provide the capabilities to switch between Selenium, Puppeteer or even Playwright(_only for CodeceptJS_) as your automation core library.

### Evaluate Team Experience & Preferences 🤝
Presenting your case in a team that already has experience with web automation is always a good thing. In the best case scenario you will be having more eyes on the target along with more technical knowledge from your peers. 

On the other side of the spectrum, a team that had a bad experience with similar efforts in the past, can be seen as a source of feedback for what went wrong and ways to avoid the same mistakes. 

⭐ _Do not forget that this situation can be fertile ground to change perspectives for the better (that is why you should continue reading)_

#### Bring The Excitement 🏂

Talking about perspectives, it might be by far one of the strongest factors on the success of the initiative, you should strive to excite all the more people from your team. 

Try to create a group of "followers", people that will support your claim that this change will have positive impact for the team as a whole. In the same note, having your peers excited will have a high chance of them being willing to collaborate with you and contribute in the effort. This can only lead to much better results.

>_Keep in mind that more experienced managerial stuff, will not naturally prefer a "one-man" initiative as they will need to account for the bus factor of a new system._

On the other hand, as any _solid initiative_, it needs to pull its own weight, that is why you must strive to require as few slices of people as possible in order to make this a reality.

As an example, if you get the feeling that the CI pipeline is convoluted or it requires significant involvement of Operations people, try to choose a solution that makes the process as lightweight and minimal as possible.

👉 _Minimizing the effort from other individuals and the changes required in other parts of the system, is sure to increase the chance the initiative is accepted and not thrown in a "low priority" bucket._

## Maximum Output - Low Effort
Independently of the results of your preparation, since hopefully you did not skip any corners, it is time to get the wheels spinning. Together with your team you have made the choices, keeping in mind all the needs of the application, and in order to actually start the initiative you need to present to management the __incremental__ steps towards your desired end goal.

_Special Hint: Do not come empty handed on this aspect, expecting the question to be asked by someone else, be prepared with the correct amount of effort that can fit into the work schedule that your team is following._

__"Incremental"__ can mean different things for different people, but we need to have this down for our initiative so that we can produce the maximum amount of output in _low effort_ iterations. What better way to illustrate such a case than with an example.

__Strap in!__
<hr/>

## Example: Monolith with Multiple Frontend Applications 🤹

### The Goal
Let's suppose your case is a monolithic application _(Django, Rails etc.)_ with multiple frontend apps for distinct parts of your product _(Data dashboard, Signup flow, Landing pages)_.

</br>
![Example app architecture](https://dev-to-uploads.s3.amazonaws.com/i/a96h9yfuydv0m3fssmlk.png)
</br>

The application does not have any End to End tests as of yet, but has a simple test pipeline that spins up a local instance of the monolith, runs the backend tests and the different tests for the frontend that happen to be run using [jest](https://jestjs.io/) for all applications.

In this scenario your end goal is to create a containerized suite of End to End tests with Puppeteer that run in every PR merge of the application and tests all the parts at once. 

Some additional features of the suite that everybody agreed on include:
- Screenshots on failure cases
- Statistics of past and current test runs
- Slack notifications when the suite fails to build a PR

### First Iteration Proposal
For the first iteration, you should aim for the least amount of setup required and [happy path](https://en.wikipedia.org/wiki/Happy_path) coverage of couple of the main flows that are most valuable to your business.

Our first targets can look like:
- The _landing page_ is loaded successfully and the CTA is visible within the viewport.
- The _dashboard application_ is loaded successfully and the main 3 routes can be clicked through and render the main graphs of the user expects to see.

</br>

### Common Mistake: Setup For the First Tests ❌
One of the main mistakes that individuals make when introducing a web automation initiative is to try to setup the "final" view of the pipeline integration right at the start of the initiative. 

This is where many trip up and the whole initiative __gets discarded__ when you depend on other people to kickstart it. </br>_Some examples where you will need to take time from your DevOps team..._
- Nobody in the team knows how to setup Jenkins for the Selenium Server to run in parallel
- Your Docker setup is failing for "reasons" 🐳
- You are not feeling comfortable modifying the Jenkinsfile on your own

Without going deeper here into the reasons and remediation of this, you have to go with the __most unobtrusive setup as possible__.

### The Unobtrusive Setup 👻

In our case this means integrating the first scenarios inside the existing frontend unit testing suite. Just the plain `npm test` that your frontend apps are already using in one of the build hooks (_hopefully_ 😅) is more than enough. 

The application is already running the tests in the pipeline, so you can easily go with the solution of adding [jest-puppeteer](https://github.com/smooth-code/jest-puppeteer) to your project and add your two scenarios then and there on their respective frontend repositories.

> No further containerization is required
> No additional commands on the build pipeline
__No further effort, just your two test scenarios__

### First Iteration Complete 🎖
With the scenario described above that would take:
\- One additional NPM package
\- 100 or so lines of code 
\- Some seconds added on the pipeline total build time

__With that we have completed the first iteration of our initiative.__ Every time our application goes through the simple test pipeline, we make sure that two of the main parts of our product are not broken. This is no small guarantee for the business and you manage to deliver it in a really short timespan. 

Hopefully you have surprised a couple of people that did not know the power you can have with End to End tests giving a little effort. 

__Full steam ahead for the next iteration! 🚄__

### Next Iteration!

Actually, for the next iteration, _you are on your own_.

You have already something going on and that is enough to take some time from each iteration cycle and enhance it. Keep showing the value and advocate the confidence that it gives while shipping code into production.

Do not forget that value is expressed differently in the ears of different people.
- Remind developers that they can be confident that they did not break something important while trying new features refactorings 🛠
- Show the product owners that _time-to-release_ will keep decreasing as QA has less manual work to do for each feature ⏲
- Indicate to managers and stakeholders that the main revenue flows are __safe__ while the product is becoming better and more feature-rich 💰

__You got this! 🔥__

## Closing
Thank you for taking the time over yet another _not so short_ writeup, which I hope you enjoyed and found useful ideas about how to tackle a web automation initiative, both in the technical and in the non-technical aspects 🙇‍♂️

From personal experience, committing and going through the process of gathering data, evaluate current requirements and analyze past experiences from your team is probably the most important decision you could have made.

Not because it will make the effort more likely to succeed, _which can never be guaranteed_, but for the sole reason that it will arm you with the __feeling of innate confidence__ and the __joy of solving a real problem for your business__, not just a tech test-drive that might have a chance to fit the requirements.

_Cross-posted from [The Home of Web Automation](https://www.thehomeofwebautomation.com/foot-in-the-door/)_

![the home of web automation log](https://dev-to-uploads.s3.amazonaws.com/i/rlvwytoedzy7wmsr1h9a.png)

_Resources to explore:_
\- [Getting started with Puppeteer](https://www.thehomeofwebautomation.com/getting-started-puppeteer/)
\- [Getting started with Playwright](https://www.thehomeofwebautomation.com/getting-started-playwright/)
\- [Google Analytics technology report](https://support.google.com/analytics/answer/1012034?hl=en#Technology)

_Image by <a href="https://www.pexels.com/@mateusz-dach-99805">Mateusz Dach</a>_