In software development, quality doesn’t happen by accident. It’s the result of discipline, collaboration, and a structured approach to catching issues early — before they become expensive problems.

One key quality practice is reviews — a systematic examination of work products (like code, requirements, and test plans). Whether you’re reviewing a line of code or a comprehensive design document, following a defined review process ensures that the outcomes are meaningful and productive.

Let’s explore the Review Process Activities as outlined in the ISO/IEC 20246 standard — and why you should care about each one.

🔍 What Is the ISO/IEC 20246 Review Process?

ISO/IEC 20246 defines a generic yet flexible review framework. This means whether you’re doing a lightweight peer review or a formal inspection, this framework can be tailored to fit your needs.

Since some work products are too large to be reviewed in a single session, the process can be repeated across sections. Think of it as modular quality control.

🛠️ 1. Planning the Review

This is where everything begins.

You define:

• ✅ The scope and purpose of the review
• 📄 The work product to be reviewed
• 🔍 Quality characteristics to be evaluated
• 🎯 Areas to focus on
• 🏁 Exit criteria (when the review is considered complete)
• 📆 Timeframes and review effort

A well-planned review saves time later. It sets expectations and ensures everyone’s aligned.

🚀 2. Review Initiation

Here, the review is officially kicked off. This involves:

• Distributing the work product
• Ensuring every reviewer understands their role and responsibilities
• Providing access to supporting materials (e.g., standards, templates)

The goal? Make sure everyone is prepared to start strong.

👀 3. Individual Review

Each reviewer examines the work product on their own. They:

• Use techniques like checklist-based or scenario-based reviewing
• Log all anomalies, recommendations, and questions

This phase is critical — no groupthink, no distractions. Just focused attention to detail.

🤝 4. Communication and Analysis

Now, it’s time to discuss what reviewers found.

• Not every anomaly is a defect. Some may be stylistic or preference-based.
• Discussions help determine:
• ✅ If something is a real issue
• 📌 Who owns it
• 🔧 What action is needed

A review meeting typically happens here. Teams might also assess the overall quality of the product and decide on follow-ups.

🧹 5. Fixing and Reporting

Once decisions are made:

• Defect reports are filed
• Corrective actions are assigned
• Exit criteria are checked
• The review results are reported for transparency

When all exit criteria are met, the work product can move forward with confidence.

✅ Final Thoughts

A solid review process does more than find defects — it promotes shared understanding, improved communication, and higher quality deliverables.

Whether you’re reviewing code, user stories, or test cases, following these five review activities helps you catch issues early, reduce rework, and build better products.

So next time you’re tempted to skip a review or rush through it, remember:

“A good review today is worth a thousand bug reports tomorrow.”

✍️ Found this useful? Follow me for more insights on QA, testing standards, and building high-quality software.