- March 2, 2023
- Lina Kuratomi, Automation QA
I love QA automation. I believe in the power it has to change the rhythm of the Development Life Cycle and I also think it has the power to bring a team closer together, as it has a direct impact on the day-to-day work of developers and QAs. I wanted to start by saying that, so I make it clear that I’m not against QA automation per se, but against using it the wrong way.
Because, yes, I can now say, after years of being brought into projects to do automation, that some people have used it in the same way one could use a chainsaw to cut a sheet of paper: you can absolutely do it, but you would probably be better off with scissors.
We all know how the theory goes
QA automation saves time for the team by running those tests that are time consuming or that need to be run so many times that even when they are quick, they take a good chunk out of the team’s allocated time. This frees the team up to focus on more valuable, analytical tasks that can’t be automated. Or work on documentation, or apply their big beautiful brains to something that doesn’t wear them off with tedious repetition, ultimately protecting them from making simple human mistakes.
Regression is the most favoured type of test when people start thinking about automation, because as a product starts to grow, so does the code base and functionalities you need to keep an eye on. The code base has to continue to work smoothly as you release new features into production. A successfully automated regression makes everyone sleep soundly at night, knowing if a new feature breaks a core feature the tests will alert everyone. This is one of the biggest joys an AQA can experience. Not to mention that it allows us to start spending time in other things, like testing NFRs or even reducing the technical debt!
Additionally, if you bring Acceptance Test Driven Development (ATDD) or Behavior-Driven Development (BDD) into the equation, business will join the automation bus: they will start participating in selecting what to automate, when to automate it and will get to see more closely how it adds value. And then bring the pizza and the beer, because it’s a party for the whole team!
On the other hand, not fully understanding the cost of building and maintaining an automation project can lead people to see QA automation as a silver bullet that will give the QA team superpowers to certify the quality of all the code developed, even if the ratio is something as disproportionate as 7:1. If we were to pay for a chainsaw, it should be because we understand what it takes to operate it and the very specific advantages you can get out of it. The project needs to be able to afford the fuel needed and should have at least one member on their ranks (ideally more) able to wield it to cut down wood effectively. In the same way, QA automation needs the project and the team to be ready to implement it. It will need stable features worth the time investment, a roadmap to know those features won’t be changing immediately after they are automated, a curated pool of eligible test scenarios and working environments.
With all these things in mind, it’s important to sit down for a few minutes and answer the following questions:
- Is QA automation going to help us solve the problem we want to solve with this project?
- Is it going to pile up on the good side of the balance?
- Is the project robust enough and the roadmap stable enough to support QA automation?
- Is the team prepared to undertake the creation and maintenance of a QA automation project?
This should include the technical preparedness, but also the time availability. - Do we have all the necessary inputs to produce useful results? In terms of infrastructure, test
scenarios, stable features, etc?
The answer to some of these might be a “not yet, but we will” and that’s okay. But in that case, a pragmatic approach is to keep using manual tests until you’re ready to host a QA automation project.
Think about, for example, an MVP. What is the problem that an MVP is trying to solve? It’s usually a business idea that has been spotted, but it’s not completely clear what its final shape is going to be. MVPs are supposed to be able to pivot faster than other projects. In doing so, trying to automate something could cause a lot of rework on the potential QA automation project the team could put together. So it will pile on the “bad” side of the balance, on the things you have to do, but are not really adding that much value to the work. It will also not be a robust enough project, because it might also be testing different approaches of the same solution, and most of those will be “quick and dirty” at the beginning.
This will also take a lot of time from the team, so time availability for QA automation might be limited. And the infrastructure might also be all over the place, since the team might also be experimenting with different options that might make them nimbler. For a project like this a solid strategy of manual testing, combined with a few automation scripts on the lower levels of the Test Pyramid would work better than investing on UI focused end-to-end automation.
Think about, for example, an MVP. What is the problem that an MVP is trying to solve? It’s usually a business idea that has been spotted, but it’s not completely clear what its final shape is going to be. MVPs are supposed to be able to pivot faster than other projects. In doing so, trying to automate something could cause a lot of rework on the potential QA automation project the team could put together. So it will pile on the “bad” side of the balance, on the things you have to do, but are not really adding that much value to the work. It will also not be a robust enough project, because it might also be testing different approaches of the same solution, and most of those will be “quick and dirty” at the beginning.
This will also take a lot of time from the team, so time availability for QA automation might be limited. And the infrastructure might also be all over the place, since the team might also be experimenting with different options that might make them nimbler. For a project like this a solid strategy of manual testing, combined with a few automation scripts on the lower levels of the Test Pyramid would work better than investing on UI focused end-to-end automation.
And yes, I also know there’s a hype to get on the QA automation wave that is taking over the world for a good reason, but we’re in favour of empowering our customers to take a pragmatic approach. By laying out pros and cons carefully we can choose the most suitable strategy that allows the team to move at a dynamic pace, pivot as needed but also match the product and growth ambitions well.
QA automation is a very powerful tool. Just like a chainsaw. But trying to use it when you are not ready for it might cost the team time and effort they might never get back. This could leave them confused and affect their motivation by making them feel they failed, or even making them think that QA automation just never works.
Get in Contact
If you have a new concept or existing product and are considering taking the next steps, we would love to discuss if a BoatyardX Discovery project can help you achieve your product vision.
Reach out at letsgettowork@boatyardx.com
Join BoatyardX
Now spread across 4 locations, Cluj and Iasi in Romania, Bogota, Colombia and Dublin, the BoatyardX team currently exceeds 100 people and continues to grow.
With customers in North and South America, Europe, Northern Africa and South-East Asia, the team spans the key working timezones. Expertise is enhanced across the teams through establishing technical competency groups led by experienced leaders, charged with ensuring best practice and efficient learning across all the organisation.