What is a good strategy for Q/A Engineers peer reviewing Unit tests as part of the software development life cycle?

I think that there are, indeed, things that I should check regarding the unit test made by the devs (like making sure that critical part are well tested).

So, what should I be looking for in those peers reviews? How do I avoiding micro-managing and how do I make sure I don't spend to much time doing the reviews (as I have my own UI and integration test to write)?

  • 2
    start simple and work up. Are there unit tests? Do they run? Do they pass?
    – Ewan
    Nov 30 '18 at 9:29
  • 1
    Don't check if the tests pass - check if they fail when they should.
    – Doc Brown
    Nov 30 '18 at 9:45
  • 1
    As the question currently stands, I'd say it's "seeking career or education advice" and so is off topic here.
    – David Arno
    Nov 30 '18 at 9:47
  • @DavidArno I strongly disagree. This is squarely in the Software Development Life Cycle category of on topic questions. Nov 30 '18 at 9:50
  • 1
    @candied_orange While questions about QA can be on topic, this particular question seems to be more about “how should I prioritize my work?” or “how does my role fit into the company?”. Asking for a list of things to look out for is also too broad. I'll be happy to vote to re-open if an edit clarifies what concrete software engineering concepts it is asking about.
    – amon
    Nov 30 '18 at 10:02

For a unit test the review is easy: Will it pass the test if the software is written correctly? Will it fail in at least some failure cases of the software, and will it fail in the failure cases it is expected to check?

If there are all yesses the review is done, and if there are no’s you inform the author, and review again when the problems are fixed. In either case, it shouldn’t take more than a few minutes per unit test. Less for small and obvious things.

“Do they pass” is not part of the review of a unit test. If a unit test fails, but the test is testing correctly, someone will have to fix the failing software. That has nothing to do with the unit test, the unit test has actually done its job.


It's a bit weird to call your review of code a peer review if you're QA and not a peer developer. Not that I wouldn't welcome you at the peer review table so long as you act like a peer and review all the code, not just the tests. Heck forget the table, you can come sit by my monitor so we can fix things fast.

Don't limit yourself to just peer reviewing the tests or the code. One of the best things you can do is look at the code, the requirements, and the current tests and add your own tests. If you've spotted an issue that needs fixing writing tests is sometimes the best way to explain the problem. I wouldn't consider doing that stepping on my toes.

Indeed this is a way I'm used to working. Having that kind of hands on QA lets me go fast because I know you've got my back. Be sure your shop feels the same way.

One thing I beg you not to do is create a pile of manual test documents. As that pile gets taller and taller releases get delayed longer and longer. If you do create a manual test get it automated as soon as you can.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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