On the Importance of QA Automation for Modern App Development

What is QA Automation

As the name suggests QA automation means there are automated testing tools involved in testing the software. QA automation allows to delegate time-consuming repetitive tasks to the tools. These tools don’t only speed up the development process. They can perform advanced tests that are simply impossible to do manually.

This does not mean that quality assurance can be fully done by automated tools. That there’s no need for human involvement at all. First of all, the tests have to be written by someone. Then the tests have to be carried out. The test reports have to be read and understood by someone. Finally, manual testing still is a big part of a proper testing strategy.

QA automation has been gaining traction in the past few years. The more teams embrace the continuous practices, the more popular QA automation becomes. You can get into the automated testing by:

• Having your in-house developers create tests from scratch.
• Using codeless automation software.
• Outsourcing QA automation to third-party providers.

Read more: What is a Software Testing Life Cycle: an inside look at quality Assurance Process at Fulcrum Rocks

QA Automation Patterns and Antipatterns

Generally speaking, patterns are a set of consistently repeated actions. We act according to our cognitive and intuitive values. These values form the QA automation culture. So patterns and antipatterns are the reflection of the automation culture. And they also form the culture.

Let’s elaborate. Every team comes up with their own testing methods. These methods we call patterns. They are often formed on their own around the development cycles. Some of these testing patterns have become the industry standard. The pyramid, for example, is generally referred to as good practice by most of the sources.

The test pyramid was first introduced back in 2009 by Mike Cohn in his book Succeeding with Agile. The pyramid pattern answered the essential questions. When to test? What to test?

The original pyramid consists of three layers:

• unit tests;
• service tests;
• UI tests.

The higher the layer the more expensive the tests become. The general rule is – the more expensive the tests, the less of them we do. So we do thousands of unit tests, hundreds of service tests, and dozens of UI tests.

But even the most experienced programmers often fall into the automation antipatterns trap. What are the antipatterns?

The Ice-Cream Cone Anti-Pattern

If the majority of your QA effort lies in UI and manual testing – congratulations, you’ve got yourself an ice-cream cone. Why is this bad? As the number of features grows, so does the number of tests required. UI tests are slow and expensive. As are manual tests. So this antipattern makes the whole development cycle slower and more expensive. Besides, if you put the testing off till the UI is ready your product will always be late to the market.

The Software Testing Cupcake Anti-Pattern

This scenario is quite common. There are different teams that write and execute different tests on different levels. The developers are in charge of the unit, integration, and component tests. A different team writes black-box tests. There’s a QA specialist who automates the regression tests. And there’s a team of manual testers.

All of these teams work separately and never or rarely collaborate. Oftentimes there’s no consensus on what scenarios have to get the automated testing. As a result, the same scenarios end up automated on different levels. Yes, the additional tests are not bad themselves. But the team inevitably loses efficiency running this many tests on every level.

Automation Hourglass

This antipattern happens when your development team writes too many Unit tests. Your QA has too many UI or end-to-end tests. And not enough middle-level tests, like contract and integration ones.

The Ideal Automation Testing Design Pattern

Remember the testing pyramid from the previous paragraph? That concept was introduced a long time ago, and for some years it was thought of as the ideal pattern. But the modern world disagrees. It seems overly simplistic. The original level names are argued to be irrelevant to the modern development cycle.

Still, we at Fulcrum believe that the pyramid pattern is a good rule of thumb for creating our own ideal testing pattern. The general rules you have to remember from the original pyramid:

• Write tests of different level of detail.
• The higher the testing level the fewer tests you should have.

The pyramid shape itself proves to be a fast, maintainable, and scalable testing strategy. Which allows creating a healthy QA automation culture within the team. Here’s how our ideal pattern looks now:

You can see there’s a Contract tests level overlapping Unit and Component tests. Contract tests check the compatibility of backend and frontend versions. We run them parallel to the Unit and Component tests.

How to define areas of responsibility

We’ve already touched upon this in the previous paragraphs. Generally, the higher the level the more QA specialist is involved in writing the tests. Here’s how the responsibility areas look in our team:

Kör study case: why QA automation is indispensable

Kör is an edtech project we created for our client from Norway. To put it simply, Kör is an online driving school. The platform allows students to book driving programs and lessons online. It keeps track of their progress. And allows the students’ family and friends to participate in the process.

We worked on the project from the very first stages. It was one of the first projects where we applied continuous practices.

When it comes to creating a QA automation culture we have to admit – we did not think of it right away. We started automating the tests when the project was about 6 months in development.

The full-on QA automation we applied when it was about 9-10 months in. At first, we had the ice-cream cone. We had way too much of expensive and slow manual tests. And too few of the fast and cheap unit tests. We did not have automated UI and integration tests at all at this stage.

When the project passed the global milestones we inevitably had to think about making the tests more manageable. The project was getting bigger. So we had to make sure the quality was high without slowing down the development speed. This is when we transitioned to the hourglass anti-pattern. Now we are moving to the ideal pyramid we described above.

What is the point of all this? QA automation brings in:

• speed;
• scalability;
• early bug detection;
• better code quality.

Let’s illustrate with a real-life example. Here’s what we saw in terms of speed on the Kör project when we automated the smoke test suite:

The automated suit was executed in 1 minute. Manually the same suit took about 8 hours to execute. Another example we have to show you concerns scalability.

Our project currently has 1 automation QA specialist and two manual QA engineers. Let’s say we have one release per sprint. If we need to make 5 releases per sprint we’ll have to hire an average of 10 manual QAs or about 3 automation specialists. Simply put – the more releases you want the more manual testers you’ll need. But the number of automation engineers won’t be that high.

With automated tests, bugs are found on average 50% faster. This is especially critical if the bug is at the end of the passage. And finding bugs faster means they are cheaper to fix.

As we’ve already said above the Kör project was developed with the continuous practices implied. This means we had very frequent releases. To be able to scale and release more often we went for automated QA. And never once regretted it.

As you can see QA automation proves to be the best choice for efficient, scalable, and profitable software development. If you don’t fall into the antipattern trap and uphold a healthy automation culture within your team you are bound to succeed.

Of course, if you need help with QA automation Fulcrum Rocks is just a call away!