Code review checklist

Photo by J. Kelly Brito on Unsplash

Hello guys! I like checklists. They help me to stay organized and not to forget things. I use a lot of checklists in my work. And I decided to share one of them for the code review. Also, you can use it as a self-check before putting on review which is good practice in my opinion. I created it mostly for QA, but I think developers will find something useful too. Let’s get started.

1. Check if the code follows the code standard. Of course, it depends on the language that you are using. For example, for python, it is PEP8 (If you still don’t know it, it’s the exact time to learn it). Also, it could be a company/co-workers convention.
2. Test Cases Coverage. Do tests have all test cases that you can automate? Do test cases guarantee wide coverage? Does this code test do what it is supposed to test? Check User Story requirements, Try to come up with test cases out of requirements. It’s a lot of options and ways how to test software.
3. Spelling. Check spelling mistakes and if all #TODO, comments, or redundant comments are cleaned up.
4. Sleeps and breakpoints. Is it possible to remove some sleeps? Sleeps are really BAD for testing, they slowing down your automation. You can say that it’s just 1/3/5 seconds, but can you imagine if you have a lot of tests and most of them contain sleep? And don’t forget to remove breakpoints. We don’t wanna the test gets stuck somewhere in the middle of Continuous Integration.
5. Test logs. Is it enough logs in case you or your colleagues would like to debug your test failure?
6. Comments. Is it enough comments for other people to understand how code works? I’m working on legacy products with legacy QA code. And trust me you don’t wanna end up with a repo full of tests but you have no idea what they do.
7. Simplify your code. Can the test code be simplified? Almost everything can be simplified.
8. OOP. Does this code follow Object-Oriented Analysis and Design Principles?
9. Broken Code. Can you think about something that can break the test code? You don’t wanna get a bunch of broken tests right before release or during the next regression.
10. Clear functions and variables. Was the code easy to understand? Could it be improved by smaller name functions, by removing some test steps into functions? Can we give a better name to variables?

Write in the comments what would you add to the review checklist and what kind of checklist you would like me to create?

Don’t forget to clap! 👏

Check my other accounts on social media: https://linktr.ee/anna.the.shark