Planning technique

Quality Control Optimisation, Explained Properly

More checking does not mean better quality, it usually just means slower. Here is how to spend your checking where it pays, and what Orangescrum gives you to run it.

Start free trial See all features

What is quality control optimisation?

Quality control is the set of checks a team runs to find defects before a customer does: testing, review, approval, and inspection. Optimising it means getting the most prevention for the least delay, because every check costs time and not every check is worth its cost. The useful moves are nearly always the same three. Move checks earlier, because a defect found at the requirement stage costs a fraction of the same defect found in production. Make the standard explicit, so a reviewer is checking against something written down rather than against their mood. And measure what escaped rather than what you caught, because escaped defects are the only number that tells you whether the checking is working.

Where quality effort gets wasted

Everything is checked to the same depthA copy change and a payments change go through the same three approvals. The team gets slower without getting safer, and eventually people start routing around the process.
The standard lives in someone's headNobody wrote down what done means, so review is a matter of who is reviewing. Two people looking at the same work reach different conclusions and both are defensible.
Checking happens at the endAll the quality effort lands in the last week, which is the most expensive moment to find anything and the moment there is least time to fix it.
Success is measured by defects foundA rising bug count is reported as the testing working well. It might equally mean the work arriving is getting worse. Only escaped defects distinguish the two.

What Orangescrum actually gives you

Real features, named. Nothing here is an algorithm that decides for you.

Write the tests down and run themTest plans, suites, cases and steps, with test runs and execution history, so checking is a repeatable record rather than a memory of what somebody tried.Test case management Track what got throughDefects are logged, prioritised, and linked back to the task and release they came from, which is what makes an escaped defect count possible at all.Bug and issue tracking Make the standard explicitA checklist on the task turns a definition of done into something the person doing the work can actually see and tick, rather than something they were told once.Checklists Put the gate in the workflowCustom statuses let you model review and approval as real stages, so work cannot quietly skip a check that your process says is required.Custom status workflow Capture the fields that matter to youCustom fields hold severity, root cause, or environment on a defect, so you can group escapes by cause rather than argue about them.Custom fields Look at the pattern, not the anecdoteReports on defects by project, priority, and status turn a stream of individual bugs into a picture of where quality is actually leaking.Reporting

How to spend checking where it pays

Grade the work by what failure would costNot everything deserves the same scrutiny. Decide, once, which categories of change need full testing and approval and which need one reviewer, then apply it consistently.
Write down what done meansTurn the unwritten standard into a checklist attached to the work. It is a short exercise and it removes most of the variation between reviewers on its own.
Move a check earlierPick one check that currently happens at the end and move it to the start. Reviewing a requirement or a design costs an hour. Finding the same problem after build costs a fortnight.
Model the gates as statusesIf review and approval are real stages in the workflow, they cannot be skipped by accident and you can see how much work is queued waiting for them.
Count escapes, then act on the causesTrack defects that reached a customer, group them by cause using a custom field, and change one thing in the process each cycle. That loop is what optimisation here actually is.

What Orangescrum does not do here

Orangescrum is not a quality engine, and there is no feature called Quality Control Optimisation. It does not predict where defects will appear, score the quality of your work, analyse your code, run automated tests, or decide how much checking a change deserves. It has no risk based test selection and no quality gate that evaluates anything on its own. What it does is hold the structure: test cases and runs, defects linked back to the work, checklists that make a standard explicit, workflow statuses you can use as approval gates, custom fields to record cause, and reports over all of it. In the Self-Hosted edition the DevOps layer can also block a pull request until the linked work item reaches a status you allow, which is the closest thing to an automatic gate that ships, and it enforces your rule rather than forming one. The judgement about how much to check stays with your team.

Quality control optimisation <em>FAQ</em>

Does Orangescrum automatically optimise quality control?

No. There is no quality engine, no defect prediction, no quality score, and no feature that decides how much testing a piece of work needs. Orangescrum gives you test cases, defect tracking, checklists, approval statuses, and reporting. The decisions about what to check and how deeply are yours.

Does Orangescrum run automated tests?

No. Orangescrum manages test cases, test runs, and results. It does not execute tests. Your automation runs in your own CI system. In the Self-Hosted edition the DevOps layer can show the resulting build and pipeline status against the work item so the outcome is visible where the work is tracked.

Can Orangescrum stop work moving forward until it has been checked?

Partly. You can model review and approval as required statuses in a custom workflow, which stops a check being skipped by accident. In the Self-Hosted edition you can also gate a pull request so it cannot merge until the linked work item reaches an allowed status. Neither of these judges the quality of the work, they enforce the sequence you defined.

How do I measure whether quality is improving?

Count escaped defects, meaning the ones a customer found, rather than the total found. Log defects against the release or project they escaped from, record a cause in a custom field, and watch the trend. A falling escape rate with steady throughput is the only reliable signal.

Is more testing always better?

No, and this is the whole point of optimising. Checking costs time and delays feedback, so past a certain point another approval buys almost nothing and slows everything. The gain comes from moving checks earlier and matching the depth of the check to what failure would actually cost.

Does Orangescrum do code review or static analysis?

No. It does not read or analyse code. In the Self-Hosted edition it links to the repository and can show pipeline status on a work item, and there is a separate guide on scheduling code review so it does not become a bottleneck, but the review itself happens in your Git provider.

Which editions include the quality features?

Test case management is on the Cloud Premium plan and included in Self-Hosted. Bug and issue tracking, checklists, custom statuses, and custom fields are available across the paid Cloud plans and in Self-Hosted. Pull request gating is Self-Hosted only.

Put the checks where they pay

Free 14 day trial, no credit card. Every plan includes unlimited users.

Start free trial

Test case managementPlans, suites, runs, and results Bug and issue trackingDefects traced back to the work Code review schedulingStopping review becoming the bottleneck Custom status workflowApproval gates in the workflow itself