Test Pyramid

What is Test Pyramid?

I have been interacting with many QA’s as part of my organizations recruitment efforts. One of the common themes I found was most of them write a lot of Automated tests its good step in right direction.
I went on to discuss about details of this automation and found that they spend lot of time in maintaining and debugging these tests.

These conversations made me think that our assumption many people know about Test Pyramid but it’s not true.

Before getting into the details of Test Pyramid lets talk about what all types of automation tests that are usually being written within a Software development team.

1. Unit tests: Tests written for each class/method that are present in the code. The aim of these tests is to ensure that developers are able test the individual method, function or a class again the requirements.
2. Integration tests:  Tests written for integration between different units or modules of an application. Example like integration with database or an external application.
3. UI tests: Tests written to drive the UI for an application. These tests validate working application when the entire application is running.
4. Manual tests: Tests executed by testers manually.

The above tests are high level classification of the tests.

Mike Cohen came up with a visual metaphor of these tests based on the number of tests.

1. Test Pyramid

    A test pyramid recommends that we should have lots of unit tests and the number reduces as we go higher.





Pros:
- Optimized test automation by reducing duplicates
- Faster feedback especially for developers
- Saves time for everyone by avoiding efforts to do sanity every time.

Cons:
- Works well when we have a good CI/CD set-up

2. Ice-cream cone

    Here the we have more of manual tests and the number reduces as we go down.



Pros:
Cons:
- Delayed feedback making deployments slower
- Time consuming as most of the work is done manually.
- More maintenance of Test automation code


3. Cylinder

    Here we roughly have similar number of tests at each layer



Pros:
- This happens to be most typical pattern as each role takes care of their tests
Cons:
- Lots of duplicate tests
- Time consuming automation execution and maintenance.






Comments

Post a Comment

Popular posts from this blog

How can I go about Test Pyramid?

In last blog we went looked at visual metaphors for test automation . In this blog we’ll go step by step about how the test pyramid is implemented. The application developed is a web calculator which is build using Spring.  Application code here The layers we have is: 1. Calculator class which has all the logic for calculations 2. Web layer which takes the input from user. In this application we are not interacting with any Database or third party service. Lets think of some scenarios we’ll like to test:   1. Whole numbers positive and negative 2. Numbers with decimal points 3. Max number and min number 4. UI if things are displayed correctly You can get the application here: Now to get some feedback we test most of the above tests cases manually. As we know testing things manually is a bit time consuming. So to make our lives better we need to put effort in automating the tests If its just QA’s who would be involved in test automation a likely result would be all the tests ...
Read more

How do QA's benefit from Test Pyramid

Image
I would like to talk about my experience with Test Pyramid. A quick overview of test pyramid. Test Pyramid talks about categorizing the automated tests based on the layer of application they are written in and the volume of the tests in each layers. Example: Unit tests: Written for each of the class in the application Integration tests: Written for areas of application which talk to an external system like Databases E2E tests: Typically UI tests written when the entire system is up and running. Based on above example Test Pyramid asks teams to have more tests at Unit level lesser at Integration and minimal at E2E level. You can read more about Test Pyramid here: https://martinfowler.com/articles/practical-test-pyramid.htm l.  When you first hear about test pyramid for the first time the question you might have is how does it really help? I had a similar question. I’ll share my experience in one of my project. The project was about building a website which would consume data from...
Read more

Pairing with Developers a Testers viewpoint

The common thought about a Tester and Developer is that they'll have arguments and see each other as adversaries but that’s a classic myth. While working as a tester there will be times you talk to the developers. Here are some experiences from interactions with developers The Demystifier: The project was set-up such that a single QA was working at off-shore and development team was on shore. The primary task of the QA was to do automation. The project was a simple website with typical navigations using bread-crumbs, search pages etc. The automation was done considering these scenarios and did not have to deal with anything complex. After few weeks the team decided to implement authentication. The authentication was simple username/password but along with it they introduced “captcha” for better security. Since the current automation framework was designed considering no authentication it had to be modified to incorporate the new flow. The challenge was to how to get ...
Read more