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.

  • The skill with reviewing is finding what has not been done, rather then finding small improvements with what has been done. Few people have that skill Commented Jun 16, 2020 at 10:01
  • +1 Good question, yes we should for the same reasons as dev code, to verify it is actually doing what it is intended to do , in the right way. Commented Jun 17, 2020 at 14:56

4 Answers 4


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.


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.

  • Had you to tackle tools files extension that are not pure code? In my case we use ReadyAPI and JMeter and both use xml files which are hard to compared with a diff. I feel bad to change the workflow of the company because I have the feeling I had to change all the tools. But if you had the issue I would be curious how you handle to switch from tools which are not very compliant with versioning tools.
    – Ice-Blaze
    Commented Jun 15, 2020 at 8:11
  • 1
    Don't let the tools to drive the process, adjust the tools according to the process. I perform (or performed) code review using the web-based platforms like GitLab/BitBucket/Azure DevOps. The changes are listed within the merge request. For the files itself - there might be an issue since the changes might not be listed correctly. Unfortunately, I don't have an easy solution for that. That's the downside of using the tools that don't allow us to review the changes easily. Commented Jun 15, 2020 at 8:35
  • 3
    In other words, the inability to review the changes within the files might be a serious point to consider migration from existing toolset into alternative. But that fact needs to be carefully evaluated. Commented Jun 15, 2020 at 8:38

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.


“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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.