The Test Automation Roadmap is a model that splits the complex topic of test automation into five mindsets. This article covers the first mindset: First Steps. This article is part of a bigger story on the Test Automation Roadmap. You should start with the introduction.
Prove that automation works
When you have the First Steps mindset, it is the first time you think about automating tests. You want to, or have to, prove that test automation will offer value for your situation. Maybe you have never made an automated test. Maybe your team has never worked with them. In any case, someone must be convinced it is worth investing time and energy in test automation.
If no one needs to be convinced, you can skip this mindset and move straight to a different one.
You only need a handful of tests to prove that test automation works for you. Don’t go overboard.
Important
This mindset focuses on proving that automation works for your situation. To prove that it is important to you that any test you make is easy to set up. At this point, you should not spend time fighting with tools or designing a scalable setup. Focus instead on a short time-to-first-demo. With this demo, you will prove that test automation works for your situation.
Problems
All focus is on proving that test automation works for you and at this point, you probably have little experience. Because of this, these tests are not maintainable. The tests’ maintenance can be so bad that you should throw out all tests made in this mindset when adopting another.
Throwing out work done in this mindset is fine. First steps is a proof-of-concept mindset. It is perfectly fine to throw out your work after you have proven the concept. Besides, you only made a handful of tests. Right?
Tools & Techniques
A great place to start is by following a beginner tutorial or training. By necessity, beginner tutorials and trainings adopt the First Steps mindset. It barely matters which tutorial or training you pick at this stage.
Some general advice:
- Keep any test you write as simple as possible. This is good advice for any mindset, but it goes extra here.
- Steer clear of chain tests and end-to-end tests. Environment complexity will make it hard to achieve a short time-to-first-demo. Focus on testing your application in isolation first. Ask your local neighborhood developer about how to run your application in isolation.
- When you use static code analysis, use the default ruleset. Fiddling with rules is rarely worth it, and certainly not in this mindset.
- When you write unit or component tests, steer clear of mocking, stubbing, and spying. They are more advanced concepts that you don’t need in your first proof-of-concept.
- When writing API or GUI tests, pick any tool you like. It truly does not matter what tool you choose. However, it matters a lot in other mindsets.
- If you don’t know where to start, start with API tests. If your application has no APIs, start with GUI tests instead.
- Steer clear of pipelines. You don’t need them yet.
Position in the model
In the full model, the First Steps mindset is the smallest. This indicates that you should leave this proof-of-concept mindset as soon as possible.
While small, the First Steps mindset is by no means unimportant. Everyone is a beginner at some point and will need this mindset to get started. The small size tells you to leave this mindset as soon as possible. It can be tempting to stick with what you know now that you finally learned a little bit about test automation. However, testing with this mindset is not sustainable in the long run. Please don’t try it.
Real-world example
A short story follows about how a team used the First Steps mindset in a company of about 2000 employees (according to LinkedIn). The team made a web-based customer portal, which they tested manually. They wanted to make some automated GUI tests, but the team was new to test automation. They didn’t know how to start.
One of the first things their manager asked was if an already purchased tool would work. Testers in the team looked at this tool but decided it would be a bad fit because of its complexity.
Instead, the testers started a pretty elaborate proof of concept with four tools: Cypress, Playwright, Puppeteer, and Selenium. With each tool, they made the same few tests for the portals’ front page. In Excel, they tracked the pros and cons of each tool. After looking at the pros and cons, the team decided Cypress was the right tool for them. With this decision made and the usefulness of test automation proven, they started using Cypress. But they no longer used the First Steps mindset.
Note that the team threw out most of their work with the First Steps mindset. They considered building these tests to be research. They learned a lot by making the same tests with different tools and used these lessons in another mindset.
Conclusion
Test automation with the first steps mindset is about proving that test automation will work for you and your situation. It’s a proof-of-concept mindset, meaning you should leave it behind as soon as possible. Focus on a short time-to-first-demo.
Since you’ll likely throw out any work done with this mindset, you should keep tests as simple as possible. Keep this in mind when writing tests, but also when picking tools.
If you don’t know where to start, follow a beginner tutorial or training. Which tool the tutorial/workshop covers is not that important. These beginner resources will use the first steps mindset by definition. By starting anywhere, you gain a clearer picture of the complex topic of test automation.