1. Home
2. Blog
3. The Test Automation Pyramid

The test automation pyramid proposed by Mike Cohn can help you find the best approach to test automation.

 

Picture from “More Agile Testing: Learning Journeys for the Whole Team” (Janet Gregory, Lisa Crispin)

 

The most straightforward approach to test automation is just to take test cases created for manual testing and automate them at the level of user interface (GUI) using tools like Selenium. Nevertheless, this is the least efficient approach. Automated GUI tests are longer-running, vulnerable to any changes and hard to maintain.

 

Mike Cohn’s automation pyramid is an excellent illustration of a more efficient approach. The width of each pyramid level shows how many tests should be there in comparison to other levels.

 

Unit tests are at the bottom level of the pyramid. They should represent the majority of your tests. For example, to test a class that computes interest in an amount, you should create a unit test rendering the interest rate x and balance y. The expected result: Correct computation of the interest amount with required accuracy.

 

The middle level refers to tests that verify business behavior (but not through GUI!). Such tests are sometimes called API tests. If you use the behavior-driven development (BDD) methodology, your automated tests will refer to that level. You may need quite a large number of unit tests at this level, yet less than unit tests. Such tests can cover several components simultaneously and check the product behavior in terms of business. Example: After computing the interest on the deposit, the required amount is added to the balance.

 

The top level of the pyramid represents automated tests that directly refer to the user interface. Their number should be much lower. An example of such a test: After calculating the interest, a new correct amount is reflected in the bank statement.

 

And the icing on the cake is manual testing. Certain types of tests cannot be automated, e.g. exploratory testing or usability testing, but ideally we should always try to minimize the amount of manual tests.

 

Some other important principles regarding the test automation pyramid:

 

Avoid duplicating tests at different levels. There’s no need to repeat the same tests at different levels. For example, if boundary values were checked in unit tests, you should not repeat them at the GUI level – you won’t get any new data.

 

Generally speaking, wherever possible one should strive for shifting tests to a lower level. Say, you can check the calculation of interest on a negative sum at a “medium level” or even at the level of unit tests. So why should you do it at the user interface level? Test automation at a lower level is more efficient, it allows you to identify defects earlier and save time and money.