The earlier you find a bug, the less time it takes to fix. It’ll also cost less and involve fewer people, so the sooner you can find and fix your bugs, the better. But did you know you can start hunting for bugs before a single piece of code has been written?

How is that possible?

Most people assume that testing begins with the first deployment of code into the test environments, but you can actually start much earlier.

Informal and formal reviews enable us to check for defects in software before the code has been written. They are the opposite of functional testing, which executes the tests once the code has been written.

A formal review usually takes the form of a structured walkthrough, involving line-by-line discussions of the requirements and/or user stories by the product owner, analyst, business rep, tester, developer and a project manager. An informal review can be carried out by just the quality assurance tester or analyst.

These processes help us review the project documentation step by step – whether it’s requirement documents or user stories (if following an agile methodology).

The reviewer will be looking out for:

• broken logic (do things follow on logically from one another?)
• assumptions about how things will function or be displayed
• lack of detail in the descriptions.

They want to make sure that all possible outcomes and user behaviours are accounted for on any given page.

Why should we bother?

The simple answer is that it saves both time and money, and drives up quality.

Fixing your bugs at this stage is far less work than correcting them once the code has been written. With continuous feedback from the reviewer, the document authors will become sharper and more adept at visualising their users’ journeys.

When Shell Oil brought in a formal walkthrough process for their web content, they recorded amazing results.

Informal reviews took no more time than having to fix bugs down the line – but saved the company money. Formal inspections were far more effective – for every hour spent in formal inspection, they estimated they saved 10 staff hours down the line. When you consider all the people it would take to fix a major problem – testers, developers, project managers and business analysts – this makes perfect sense.

Overall, their defect removal efficiency with inspections was 95-97% compared to roughly 60% for systems that didn’t use inspections.

Preemptive testing clearly has benefits, but many companies skip this important quality control step to save time, without realising that it’s both a time- and cost-saving activity.

How does it work?

Whether formal or informal reviews are right for you will depend on the time you have available and the size of your business.

A less established agile team might opt for formal reviews, before moving on to informal reviews once they are more used to working together.

Formal reviews

Decide who will perform the review and who will attend the review meeting. Meetings produce strong discussion and generate ideas, which are hard to get from isolated reviews.

Then create a review checklist so that the feedback received is uniform each time. Next assign a scribe to the meeting: in small companies, this is often the author themselves so they can quickly update the user stories to iron out any bugs or assumptions.

At the meeting itself, go through the user stories step by step and discuss any issues you find. Once the requirements are updated, your developers can begin to write the code, knowing they have strong foundations to work from.

Informal reviews

Here no formal method is applied. The reviewer just checks the documents and provides commentary. The purpose is to improve the quality of the documentation from the earliest possible stage so that developers and testers have fewer basic issues to deal with.

If the person reviewing documentation is a also a tester, they will be thinking about how to test usability later on and this often uncovers omissions in the logic. However, an informal review can be performed by anyone on the project.

 

Once you have your chosen process set up, you should see the number of reported bugs go down straight away. So start reviewing your user stories and requirements now, and you’ll be squashing those bugs before they even emerge!

Did you find this post useful? Let us know your thoughts on Facebook and Twitter.