Software review is an extremely important technique used to assure the quality, functionality, and other features of your software. Unlike many of the other techniques for assuring quality that I have talked about in this blog, software review doesn’t follow an exact formula or a standard. I believe it gives you more freedom and in many cases depends on the person coding and the reviewer. What software reviews enable is the opportunity for people in your team to test your code and tell you of possible errors, improvements, etc.
Some of the most common software review practices include:
- Code review: Systematic examination of the source code used to fix mistakes and remove vulnerabilities.
- Pair Programming: In this type of code review, two programmers work together on one workstation and develop code. More people working in one piece of code enables the opportunity to bring up ideas that only one person might not have and gives more than one point of view for solving problems which is always good.
- Walkthrough: For this review, a developer leads a team of software developers to go through a software product. Questions are asked and necessary comments are made about defects and errors.
- Technical review: A technical review is more formal, qualified personnel review the software product and examine if its suitable enough for its intended use.
- Inspection: This is another formal type of peer review in which experienced and qualified individuals examine software for bugs and defects using a defined process.
These were mainly software peer review techniques, there are other types of reviews used in later stages by management representatives. They are mainly used to evaluate work status and decisions regarding downstream activities are taken from there.
One final type of review I will talk about is audit reviews. These are external reviews in which one or more auditors that are not from the development team conduct an independent examination of your software product. Done by managerial level people.
A software product is not only comprised by code but includes everything related to the product itself like plans, requirements, design, etc. What I explained above is mainly focused on code review but there are also techniques you can use to review all the other key work products in your software. What is important to understand is that reviews will always (or at least should) come from people from that specific area that is being reviewed. You can’t ask someone from the design team to review someone’s back-end code. So reviewing these other key components of a software product is pretty much the same. Although I am sure there are other specific types of reviews, standards and techniques used to review them, the basic idea is to have someone else to help you find errors and improvements. Reviews don’t have to be as specific or strict as they are described above. A designer might have no use for “pair programming” but taking the core idea and using it from a design perspective would mean having someone help you design your software and make decisions as you start thinking about solutions for the product. Another example are technical reviews, people focused on the budget area might want to review your budget plan before moving forward. Does the fact that it doesn’t have code make it different from the technical review I talked about earlier? Not really, the core ideas are the same.
In conclusion, software reviews are extremely important when it comes to fixing errors and helping improve your software. They are not limited to code and the basic idea of most if not all the reviews can be translated into other areas to make sure that you are producing software to the best of you and your company’s ability.