Should we do peer reviewing with end-to-end tests?

Question

Should we as an end-to-end tester, peer review the tests from other testers in our team? The developers do that and it seems very useful. For example, only accepting pull requests if they have been validated by peers. But in the world of testing, I have the feeling it's not the case. But the testing projects look more and more like other code projects, with functions to reuse in other tests.

The only reason that makes me think it's not common, is because the testing tools most of the time use files that are difficult to compare in a git diff. But I want to know if there are other reasons. And I believe that we shouldn't avoid good practices from developers just because our tools do not use files that look like code.

Answer 1

Just add on to the answer, a peer review is not just about the code review. It helps in:

1. Identifying improvements in code logic

2. Identifying improvements or missed application logic in the test script.

3. Identifying easier test approaches to improve test coverage

4. Identifying better approaches to solve a problem.

and so on.

We all will have mind block and author bias when we code, so it is always good to have a second opinion. It doesn't make us look bad, but it gives an opportunity to learn.

For example, in the initial coding days I used to write test focused on features. For example, for a payment system I will test whether a field throws an error for invalid inputs and shows a proper message for valid inputs. But I missed to validate whether the payment works for all the valid inputs, and instead I was testing it with one valid input and assumed everything else will also worked.

I was just validating the message feature and not the actual flow.

During code review one colleague suggested testing the end-to-end flow for all valid inputs and guess what!?! The system was failing for one corner case.

Answer 2

From my experience, it's useful to do the peer review for the test cases (review the test design itself).

If you automate the e2e tests, the code should be reviewed as well. If you want to have a good test automation project - you should treat it like any other software project, and apply all of the best practices, including the code review.

The thing is that, since you are dealing with code (no matter what its intent is, the test automation framework, enterprise application, or pet project), you should follow the common industry practices if you want to avoid common issues since they can occur no matter what is the role of the code author - developer, QA, DevOps, BA.

Reviewing your tests would allow you to find the issues and fix them while it's easy to do.

Answer 3

But I want to know if there are other reason.

I can think of some that I have personally encountered:

• tight budget, so business people will not give you the necessary time for reviews even if it hurts the project in the long run and you keep explaining for weeks on end; you can perhaps work overtime for half a year, but they you don't have the energy, or you realise you make even more mistakes when you work 70 hours/week, so you stop doing it

• not enough people: small companies might have only one tester for a couple of projects, so there is not even anyone else to review your testing projects

• busy people: even if you have other testers somewhere in the company, they are busy with their own testing projects, so they are unlikely to spend time on reviews when business people are going round wondering when we deliver another feature from the backlog

• not enough people on your project: it goes with the previous point. If you work in an Agile team, chances are, you are the only tester for a certain project, therefore no other tester knows your project on the same level, on the level necessary to be able to review your work

These are mostly organisational and people problems, yet I wouldn't underestimate them. In my limited personal experience, I've encounter at least one of them, or some variantion of these, in every company I ever worked.

Answer 4

“Quality is free, but only to those who are willing to pay heavily for it.” – T. DeMarco and T. Lister

Being someone who has been doing test reviews from over a decade, would add couple of points on 'why' and 'what' on test reviews:

• Clarity: First of all, a test should actually test what it is supposed to test only and report it clearly.Each test should be very clear on what exactly it is testing and precisely what not.

• Readable : The code should be readable; it should be understandable just by reading it, even without any comments.If somebody has to explain it , it is not been designed correctly.

• Maintainable:In the event of bug fixing/functional change in the AUT, it should be easily changeable multiple times over a period of time. If one moderate change in application requires big changes in multiple places in automation , it is not efficient(DRY).