How do QA's benefit from Test Pyramid


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.html. 

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 CRM and display it along with other things like login etc.

Since we were already doing TDD for most of the things we thought why not try to follow the Test Pyramid.

 “Quality as a team responsibility” 

When we decided to try and follow Test Pyramid the developers started adding more tests to ensure that the functionality the developed is tested ASAP rather than waiting for the UI tests. 

These increased number of tests really helped improve the code quality as well as the product quality. Now even developers were talking about various scenarios that we need to cover and how can it be tested in either Unit or integration tests.

This helped us push the “Quality as a team responsibility”.

“Saves time for more exploratory testing”

With more tests at Unit and Integration level most of the builds that were deployed for QA’s to test did not have any obvious bugs resulting in time saved for doing sanity on each build and finding obvious defects late.

Any basic functionality not working was mostly detected early on and developers would fix it quickly rather than waiting for a QA or UI test to point it out.

This helped QA’s focus more on exploratory testing and finding more defects for hard to automate scenarios. It also helped us push for “Shift Left” the testing.

“Improves QA + Dev collaboration”

With developers writing more tests we(QA’s) would collaborate with developers to come-up with scenarios for a particular feature. This helped both us and the developers understand the functionality better and think of more scenarios. Our tests were more focused and improved the automation coverage.

The conversations with developers also helped us understand different ways to simulate a particular scenario while testing.

Apart from the above mentioned takeaways by following Test Pyramid we were really able to deploy quality builds early to different environments with good confidence.

I recommend teams to try to get closer to Test Pyramid as it helps in imbibing Quality Mindset for the entire team.

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

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