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 we can think of is having all the tests as UI tests

We’ll add UI tests here

But as we mentioned in previous blog UI tests are slower than the Unit tests we write.

So ensuring faster feedback we have introduced unit tests here

Here we’ll get to know if there is any defect due to code change on the calculations side when we run the Unit tests

If you look at the above repository you can actually see the difference in speed of execution.

What should go in Unit tests?

 As a QA when you come-up with tests cases we don't need to really put in an effort to figure out which tests will be covered in Unit tests. A QA should simply come-up with tests covering most of the scenarios.

Once we have all the tests identified we can have a conversation with Developers and walk them through all the test cases while doing so we can ask them which tests makes more sense be written as Unit test.

The aim here is to involve the developers into automation effort and help them understand what are the different scenarios we can think for a given feature.

Our conversations should focus on how can we have bulk of our tests at Unit level and give us faster feedback.

What should go in UI Tests?

Once we are clear with what things go in unit tests we now have a clear idea about tests which we need to cover in UI tests.

When we start automating the UI tests we might come-up with scenarios which are difficult to automate and we need to take a call do we need to put in effort to automate it or we can do it manually till we find a better way for automation.

The whole point of having tests at different layer is to have faster feedback and reduced effort on regression testing. Exploratory testing still plays a major role in giving us the confidence on quality of application under test.