03.03.02 — Review Model: OMG → Try Again → Close Enough → Good Job

Lesson goal

This lesson introduces a practical review model for evaluating the quality of test cases in Salesforce projects.

After this lesson, you should be able to:

• quickly assess test case quality without overanalyzing,
• identify the main reason why a test case is weak,
• guide improvements in a structured and repeatable way.

Why test case reviews need a model

Reviewing test cases without a shared framework often leads to:

• subjective feedback,
• inconsistent quality standards,
• long review cycles with little improvement.

In Salesforce projects, where test cases are heavily context-dependent, reviews must focus on fitness for execution, not stylistic preferences.

A simple review model helps:

• align expectations,
• speed up feedback,
• improve quality incrementally.

The four review levels

The review model uses four quality levels:

1. OMG
2. Try Again
3. Close Enough
4. Good Job

Each level answers one question:

How usable is this test case right now?

Level 1 — OMG

An “OMG” test case cannot be executed reliably.

Typical characteristics:

• missing or vague Preconditions,
• unclear user context,
• steps that rely on assumptions,
• Expected Results that verify nothing meaningful.

Symptoms:

• different testers get different results,
• execution depends on tribal knowledge,
• failures cannot be reproduced.

Action:

Do not execute. Redesign required.

Level 2 — Try Again

A “Try Again” test case has a visible structure but is still unsafe to execute.

Typical characteristics:

• partial Preconditions,
• mixed setup and execution,
• UI-driven steps,
• incomplete verification.

The test case:

• might work for the author,
• fails during Dry Runs,
• exposes hidden assumptions.

Action:

Return for revision with targeted feedback.

Level 3 — Close Enough

A “Close Enough” test case is executable and mostly correct.

Typical characteristics:

• clear user and data context,
• stable High-Level Steps,
• meaningful Expected Results,
• minor clarity or maintenance issues.

This level is often sufficient for:

• internal testing,
• sprint validation,
• exploratory support.

Action:

Execute, but log improvement notes.

Level 4 — Good Job

A “Good Job” test case is production-quality.

Typical characteristics:

• explicit and complete Preconditions,
• clear separation of intent, context, and execution,
• durable step instructions,
• precise Expected Results,
• easy to review and maintain.

These test cases:

• survive system changes,
• support delegation,
• build long-term test assets.

Action:

Approve and reuse.

Using the model during reviews

The purpose of the model is not to label people.

It is to:

• quickly classify test cases,
• focus feedback on the biggest risk,
• avoid micro-optimizing weak foundations.

A review should answer:

What is the single biggest issue preventing this test case from being “Good Job”?

Common review traps

Avoid:

• debating formatting,
• enforcing personal writing style,
• over-focusing on step wording while Preconditions are weak.

Reviews should prioritize:

• execution safety,
• clarity of context,
• verification quality.

Improving test cases iteratively

Most test cases will not be “Good Job” on the first pass.

The model supports:

• fast feedback cycles,
• visible progress,
• shared quality standards.

A “Try Again” today can become “Good Job” tomorrow with focused changes.

Key takeaway

• Test case reviews require structure.
• The OMG → Try Again → Close Enough → Good Job model provides fast, practical guidance.
• Focus reviews on usability and risk, not personal preferences.

Consistent reviews create consistent quality.