PYRAMIDING TEST AUTOMATION

Typically , we automate tests for months , years once the feature has been delivered . This is how the industry was 10 years back.

As a result , it takes more effort , resource to complete the automation of tests which may not be helpful and end up in additional cost to project.

This expensive approach was not because of automation but was mainly due to where it was automated. At which level it was automated. Choosing wrong levels for test automation and relying completely on UI automation tests that will execute for lengthy hours was the main reason.

So , what could be done to make test automation strategy more effective is to pyramidize the automation approach so that we tend to test what is actually required more there by adding value to the quality as well as to the organization.

Mike Cohn has conceptualized test pyramids in his book Succeeding with Agile. He talks about different layers of testing and how to do it on each layers.

Pyramidization process eliminates exhaustive test automation and focuses only on automation of tests that adds value. This is achieved by grouping or organizing tests into different hierarchical levels.

Key hierarchical levels include

• GUI Tests (Top most)
• Service Tests ( Mid )
• Unit ( Lowest)

So what does this grouping actually mean ?? Just tagging all the automated tests under this groups. NO. The idea behind grouping is building reliable test suites that contains more automated tests at bottom level compared to higher levels and ensures early defect identification.

We have more units tests automated at the bottom portion as the scope of tests are small , isolated and doesn't have dependencies. These tests are executed before & after commits and are triggered by Development team.

Next comes the service layer where Integration tests are performed. This ensures the integrations with different interfaces , APIs , external and internal dependent components , databases are tested.

Finally we have the UI Tests which are at the top of the hierarchy and it should validate the overall E2E validations from UI end.

The idea is to spend less effort in design and execution of UI Tests followed by an average effort in API tests and finally more in Unit tests. By doing this we try to find out defects at earlier stage by shifting left and can save lot of effort , time , money.

For better understanding , Assume if you have 100 tests automated , split up might be around 60% allocated for Unit tests (major) , 30 % allocated for API tests (mid) , 10 % for UI tests (minor).

Like every strategy , Pyramids too have its own advantage and disadvantage depending on how it is implemented and how it is maintained and adapted for futuristic changes

In a nutshell , it proposes the idea of having very little time spent in UI test automation and focus more on automation of Unit test components / API tests that comes in the earlier stage of lifecycle which increases the probability of catching defects in the earlier stage.