The test automation potato
If you work with software development, for sure you have already seen an example of the test automation pyramid. You have seen or heard something about it at least a hundred times, but this, my friends, this is new: I’m here to present you a new trend, the test automation potato.
If you were living in a cave and haven’t heard about the pyramid before, it is a guide on how to shape your automated tests to have faster and reliable feedback about what you are developing. Basically, you have three layers there, from top to down, UI, Integration, and Unit tests. Then, you should keep most of your them in the lower levels of the pyramid, there, tests run faster and more isolated, on higher levels tests are slower and more integrated (AND FLAKY, THEY ARE FLAKY). The UI layer is also known to have the flakiest tests, but you must mitigate this problem by doing it properly.
As I have mentioned before, it’s just a guide. Some people take it as a strict rule for test automation, the silver bullet, the solution for all problems, and this is not true. I know you see people talking about it a lot of times, but the idea of this post is to show a new way to see it, respecting this guide but also respecting your software, your team, your organization.
We are seeing new “shapes” coming around, and what does it mean? A test automation honeycomb? A hive? A 3D octagon model? An evil pentagram with a skull in the center (sometimes people do strange things to see tests passing)? A POTATO???
Quick pause!
I don’t care about the names you use in your pyramid or whatever shape you want to use, you will see tests named like: GUI, UI, End-to-end, Interface, Acceptance, UAT, Smoke, Integration, Integrated, API, Service, Contract, Unit, regression, sanity and so on. How many of those names have you seen before? Probably all of them! You know the meaning of some of them, but it may mean something else for other people.
If you want to name your tests like the Teletubbies, it’s ok, what is really important is that your team/organization agrees about the meaning of each one, then you can call it however you want (Tinky-Winky tests would be outstanding).
Continuing…
Let’s say you are working in a company that has a monolithic API and a single user interface. You have a poster with the test automation pyramid in your wall, it works perfectly for your team, your CD pipelines are working like a charm and you live in the dreamland. Then you go for a new adventure, a new company where the systems are different, the software architecture is more complex, and you get dropped into a team that works just with microservices. You will look to that poster every day and will desperately think: Oh my god! There’s no UI, I can’t live with a weird test automation trapezoid!
So how would you shape your automated tests? How to structure them to get the best possible feedback for your team? The answer is pretty simple.
You need to know what is best for YOU! You can try to copy models from Google, Facebook, Spotify, and many others. But you’re not delivering the same! You have different customers, features, needs, developers, systems, culture, architecture, you’re not them!
Of course, they are good sources of knowledge and you will find a lot of useful stuff regarding technologies, processes, and business. As said before, you can always use it as a guide, and get the parts that work for you, get pieces of different shapes, bring it together and build your own! Talk to your devs, PO’s, designers, QA’s, stakeholders, whoever participates in the development lifecycle.
If you have a small service, but at the same time your unit tests are becoming complex cause you have to mock a lot of stuff and you’re spending a lot of time maintaining it, why can’t you cover “everything” in the integration layer? Just keep in mind that everyone involved in this process is aware and agrees about the plan.
So the whole point of this post is:
If at the end of the day your test automation “shape” looks like a potato, it really doesn’t matter, if it meets your needs, makes your team more confident, makes you deliver high-quality software on time, everything is fine!
Thanks again to Leonardo Galani and Stefan Teixeira for reviewing :)
