Success factors for reviews

Implementing (formal) reviews is not easy as there is no one way to success and there are numerous ways to fail.

A champion is needed, one who will lead the process on a project or organiza-tional level. They need expertise, enthusiasm and a practical mindset in order to guide moderators and participants.
The authority of this champion should be clear to the entire organization.
Management support is also essential for success.
They should, amongst other things, incorporate adequate time for review activities in project schedules.

Select the documents for review that are most important in a project. Reviewing highly critical, upstream documents like requirements and architecture will most certainly show the benefits of the review process to the project.
These invested review hours will have a clear and high return on investment.
In addition make sure each review has a clear objective and the correct type of review is selected that matches the defined objective.
Don't try and review everything by inspection; fit the review to the risk associated with the document.
Some documents may only warrant an informal review and others will repay using inspection.
Ofcourse it is also of utmost importance that the right people are involved.

To ensure that reviews become part of the day-to-day activities, the hours to be spent should be made visible within each project plan.
The engineers involved are prompted to schedule time for preparation and, very importantly, rework.
Tracking these hours will improve planning of the next review.
As stated earlier, management plays an important part in planning of review activities.

It is important that training is provided in review techniques, especially the more formal techniques, such as inspection.
Otherwise the process is likely to be impeded by those who don't understand the process and the reasoning behind it.
Special training should be provided to the moderators to prepare them for their critical role in the review process.

Reviews are about evaluating someone's document.
Some reviews tend to get too personal when they are not well managed by the moderator.
People issues and psychological aspects should be dealt with by the moderator and should be part of the review training, thus making the review a positive experience for the author.
During the review, defects should be welcomed and expressed objectively.

Follow all the formal rules until you know why and how to modify them, but make the process only as formal as the project culture or maturity level allows.
Do not become too theoretical or too detailed.
Checklists and roles are recommended to increase the effectiveness of defect identification.

Continuous improvement of process and supporting tools (e.g. checklists),based upon the ideas of participants, ensures the motivation of the engineers involved.
Motivation is the key to a successful change process.
There should also be an emphasis, in addition to defect finding, on learning and process improvement.

Report quantified results and benefits to all those involved as soon as possible, and discuss the consequences of defects if they had not been found this early.
Costs should of course be tracked, but benefits, especially when problems don't occur in the future, should be made visible by quantifying the benefits as well as the costs.

The process is simple but not easy.
Each step of the process is clear, but experience is needed to executethem correctly.
So, try to get experienced people to observe and help where possible. But most importantly, start doing reviews and start learning from every review.

Software Testing