Transform Your Development Process with Smarter Software Reviews

What is Software Review?

What is a review in software testing?

There are different types of reviews that happen at different points in the software development lifecycle (SDLC), and we’ll dive into them all in this article.

Reviewing throughout the entire software development process is key. You shouldn’t just test the final product at the end of development.

That’s far too late.

Reviewing in software ensures that you maintain quality, produce the right thing, and do so in a timely manner.

I’ve been in all stages of the software review process many many times over the years. It’s one of the key skills that a software engineer has to be comfortable with outside of writing code.

Objectives and Benefits of Software Review

Whenever I’m thinking of reviews, I have a few key things I’m trying to achieve.

The first purpose I think of for the review process, is to make sure you identify and issues as early as possible in the software development life cycle and fix them. In almost all cases, the earlier you find and fix a problem, the cheaper and easier it is.

Another main purpose I’m striving for in the software review is the make sure that you’re actually creating the software that your users are expecting.

In my experience, It’s pretty common for engineers to veer off from course a little and before too long you are creating quality software, but not the quality software that your user wanted.

A successful review at any point in the review process aims to ensure both the quality and direction of the product.

Types of Software Review

There are many types of software reviews, including, but not limited to:

• Code Review
• Peer Review
• Technical Review
• Pair Programming
• Management review

Peer Review / Code Review

The peer review is one of the earliest forms of formal review for the actual code to be checked for quality and direction.

Peer software developers (the reviewer, usually from the same development team) will look at the associated work item (Test Case, User Story, Documentation) and make sure that the code you’ve written matches the intent of that work item.

Once they are happy that the written code matches the intent of the work item, they will do code inspections to look for any bugs or code that could be written in a more efficient or easier to understand manner.

The peer review is usually a collaborative effort and can be picked up by one or more software engineers familiar with the software product and code base.

When I review code, I make sure that I am not just looking for basic technical faults (divide by zero bugs, etc), but that I am also looking for code structure, well named variables, well architeted solutions.

I am very picky with my code reviews as you I am a firm believer that code is written once and read a thousand times. Get it right before it gets merged to main.

Technical Review

A Technical Review is where a group of people from different roles get together to assess the overall state of may parts of the software project.

Participants include:

• Software Architects
• Senior Developers
• Business Analysts
• QA

This is a fairly formal review meeting where the group will cover topics such as:

• Project Scope
• Requirements documents and specifications
• Test Plans
• Prototypes or MVCs

The idea behind the technical review process is to verify the correctness of the requirements, the direction of the project and the technical roadmap. All of this is to look forwards to try and ensure a smooth project process.

Management Review

This part of the review process is to give high-level stakeholders high-level details about the status of the project.

Managers tend to want to know about whether deadlines are being met (if not, why not) and if the cost of the project is on target.

There’s no software inspections, no looking at source code and no worrying about testing in this review. The key phrase here is “status report”.

Software Audit Review

Software audit review is an exterior review where a single or multiple reviewers outside the development team inspect the software development processes to check compliance with standards, requirements, and specifications.

These tend to be infrequent and only really done at a high level.

The Role of Review in the Software Development Process

Each of the above review types is crucial in its own way to the success of a project.

Reviews highlight issues and miscommunications early on. They keep the project on track and in the right direction.

Whether formal or informal reviews, reviews get people talking. They gather stakeholders and knowledgeable people in the same place and get multiple minds solving and validating all of the work.

Reviews help companies ensure that their software complies with regulatory and industry standards.

Challenges and Solutions in Software Review

Admin and beurocreacy.

In my experience, these are the two most common complaints from engineers about the software review process.

I’ve worked in many companies with many smart people.

Unfortunately, smart engineers don’t often like many meetings. They don’t like doing Jira admin. They don’t like people scrutinizing their code.

Adding time and effort between a coder and writing code is rarely something you want to do.

However, going slower to get to the end goal faster is always a smart move.

Showing engineers that putting the effort in upfront on generating the correct specifications, and test cases and how reviews play a critical role in delivering what the client actually wants will make your life a lot easier.

Another issue is showing the people involved that the effort they are putting in to code reviews, technical reviews etc has a real world benefit is hard to do.

You can’t run A-B tests on this type of thing. All you can do is highlight the successes that this process has had in the past and how running projects without these processes have failed in the past.

Software development and the development process is about metrics. Prove how this type of project management has worked with stats from the past.

Best Practices for Effective Software Review

Let’s summarise some of the best practices I’ve mentioned throughout this post:

• Establish clear objectives and scope for the review.
• Assign roles and responsibilities to team members.
• Use a structured review process, such as entry evaluation, review process management, planning, preparation, and analysis and exit evaluation.
• Use tool-assisted reviews for efficient and asynchronous reviews.
• Track metrics to justify the time and brainpower required for code review.

Software Testing and Review: A Collaborative Approach

You should always have automated tests for your code. However, manual testing with QA is a vital step in creating a polished software product.

QA think differently to Engineers. QA look to break things, engineers tend to think about the “happy path”.

Once you as an engineering team have delivered and tested a vertical flow, hand it over to QA to do their thing.

They will bend and twist your software in ways you can’t imagine.

This is a vital step in the software review process.