1

We have a big java based desktop application in our company that we are building test cases for. We want to follow test pyramid approach as:

1) We ask devs write a lot of unit tests (but don't verify where they have written good quality unit tests or not).

2) We write service tests where we go through each and every line of the code and write Junit tests to test every possible method and condition in the code.

3) We are planning to create UI tests to ensure the UI works correctly.

I read a lot of blogs about test pyramid approach and understood that we should invest much less time in writing the UI tests as they are not good with testing ROI because they generally take a lot of time to execute and they are brittle due to their dependency over the UI elements. I absolutely agree on these points.

But, the question is, when we say we need a much lower number of UI tests, do we mean we just need UI tests for priority-1 cases (or smoke tests)? On the contrary, the UI is the element the user interacts with so do we not need to make sure it is not broken in the first place? I mean, when we say we need to reduce number of UI tests, won't it affect the quality of the UI delivery? For example, I have written a lot of service tests and made sure the backend business logic is perfect but what if the UI is messed up? Is it not equally important?

Mate Mrše
  • 7,997
  • 10
  • 40
  • 77
Amit Jathar
  • 319
  • 3
  • 14

1 Answers1

0

I don't think the number of UI tests is that important.

What I think the Test Automation Pyramid means is that a single UI test case covers many of the lower level tests. For example, a single UI test case might make 5 API calls and invoke 10 methods. That makes UI tests more brittle and complex, so better write them after the API and unit layer has been sufficiently tested.

Mate Mrše
  • 7,997
  • 10
  • 40
  • 77
  • But, the test pyramid (as it narrows towards the UI tests) depicts less efforts on UI tests because of less ROI. As we know UI tests are brittle also due to the fact that UI changes a lot than the underlaying service layer. Every time devs make changes in the UI, you need to fix the failing tests. So, the question arise is: Our manual test team has 100's of test cases written to test the product, and we want to automate them to save manual efforts. Now, do we automate all the 100's of test cases or just automate Critical and P1 cases (referring to a test pyramid approach of less UI tests)? – Amit Jathar Apr 26 '19 at 14:54