Module 6 · Test scenarios & test cases

Test Case Priority

By the Mutqan Soft QA team · · 17 min · Beginner

Test case priority is the relative importance of a test case: it decides which test cases run first and which may be left out when time is short. The ISTQB Foundation syllabus calls this test case prioritization.

For example, a release adds card payment to a clinic booking app. "Pay the deposit and receive a confirmed booking" is P1 and runs on the first morning; "the help page links open" is P3 and runs only if time is left.

Why it matters

Exhaustive testing is impossible, so time runs out before the test cases do. Without priorities, cases run in the order they were written, and the ones covering payments or personal data may still be waiting on release day. With priorities, cutting scope is a decision rather than an accident: what remains untested is the least dangerous part, and everyone knows what it is.

Priority is also a reporting tool: "All 4 P1 cases passed; 1 P3 case was not run" tells a product owner in one line what the release decision rests on.

What priority decides and what shapes the order

Priority sets the order of execution and the order of cutting, and it is reviewed every cycle, because risk depends on what changed in that build. As the lesson on test implementation introduced, the ISTQB Foundation syllabus (v4.0) describes three ways to order test cases in the test execution schedule, and two constraints that adjust them:

  • Risk-based: cases covering the most important risks run first. This lesson uses this method.
  • Coverage-based: cases achieving the most coverage run first, or each next case adds the most coverage not yet achieved.
  • Requirements-based: the order follows the priorities stakeholders gave to the requirements the cases trace to.
  • Dependencies: if a high-priority case needs a lower-priority one first, for example to create its data, the lower-priority one runs first.
  • Resources: an environment, device or person available only in a time window moves cases earlier or later.

Try it: Requirements → Test Cases

Priority, severity and criticality

Severity belongs to defects: the ISTQB glossary defines it as the degree of impact a defect has on the development or operation of a component or system. Priority is the level of business importance given to an item; for a test case, it says how soon to run it and whether it may be skipped.

A test case has no severity, because nothing has failed yet. It has criticality: how bad a failure in the area it covers would be. Some teams loosely call this "severity". Priority combines that impact with the likelihood of failure in this build, so the two can differ:

  • High criticality, lower priority: password reset is critical, but it is unchanged and its automated check passed on this build, so the manual case can be P2.
  • Low criticality, higher priority: a reworded SMS reminder is minor if wrong, but the template is new and error-prone, so its case is P2, not P3.

Risk-based ordering: impact × likelihood

Rate each test case, or the risk it covers, on two written scales, multiply the ratings and map the score to a priority. Three levels are enough to start; the risk-based testing guide uses four for whole features. Use one written scale per project.

Impact × likelihood, each rated 1 to 3, gives a test case a score from 1 to 9: a score of 6 to 9 makes it P1, 3 or 4 makes it P2, and 1 or 2 makes it P3.
LikelihoodImpact
1 Low2 Medium3 High
3 HighP2score 3P1score 6P1score 9
2 MediumP3score 2P2score 4P1score 6
1 LowP3score 1P3score 2P2score 3
  • P1: score 6–9, runs first in every cycle
  • P2: score 3–4, runs in every full cycle after P1
  • P3: score 1–2, runs if time allows and is cut first
Impact
3 High — money, personal data, legal exposure or a core flow broken for many users
2 Medium — a feature degraded or a workaround exists
1 Low — cosmetic or rarely used
Likelihood
3 High — new or changed code, complex logic, a new integration or a history of defects
2 Medium — touched indirectly by the change
1 Low — unchanged and stable

An illustrative three-level scale: each team writes its own definitions and bands into the test plan.

  • Impact: High means money, personal data, legal exposure or a core flow broken for many users; Medium, a feature degraded or a workaround exists; Low, cosmetic or rarely used.
  • Likelihood: High means new or changed code, complex logic, a new integration or a history of defects; Medium, touched indirectly by the change; Low, unchanged and stable.
Text version
Score = impact x likelihood, each rated 1 Low, 2 Medium, 3 High

                                IMPACT
                      1 Low     2 Medium  3 High
LIKELIHOOD  3 High  | 3   P2  | 6   P1  | 9   P1  |
            2 Medium| 2   P3  | 4   P2  | 6   P1  |
            1 Low   | 1   P3  | 2   P3  | 3   P2  |

Score 6-9 -> P1      Score 3-4 -> P2      Score 1-2 -> P3

Try it: Risk-Based Test Generator

P1, P2 and P3 conventions

No standard fixes these labels: teams and tools use P1 to P3, P0 to P3, or Critical, High, Medium and Low. What matters is a written definition in the test plan. A common convention:

  • P1, must run: core business flows and high-risk changes. Run first in every cycle; a failure usually blocks the release.
  • P2, should run: important functions at medium risk. Run in every full cycle after P1; skipped only with the product owner's agreement.
  • P3, could run: low-risk, stable or cosmetic areas. Run when time allows or in rotation; cut first, and the cut is recorded in the test report.
  • Some teams add P0 for the few smoke checks that decide whether a build is testable at all.
  • A P1 test case is not a P1 defect: on a defect the label says how soon to fix it; on a test case, how soon to run it.

Try it: Test Case Generator Try it: Regression Scenario Generator

Worked example: a clinic booking release

Release 3.2 of a clinic booking web app adds a card deposit when booking, redesigns the reschedule screen and rewrites the Arabic SMS reminder template; nothing else changed. The table at the end of this section lists the eight rated test cases in execution order.

  • The shared payment sandbox is open only from 09:00 to 13:00, so the two payment cases run first.
  • TC-BOOK-02 books a visit that needs no deposit. Its own logic is unchanged, but it runs through the booking flow the deposit change touched: Medium likelihood, and with High impact still P1.
  • TC-SCH-01 has High impact but is unchanged: P2, not P1. TC-SMS-02 has Low impact but is new: P2, not P3.
  • TC-SMS-02 needs the phone number that TC-PRO-05 sets up, so TC-PRO-05 runs just before it and stays P3: a constraint changes the order, not the label.
  • If the cycle is cut from two days to one, TC-HLP-01 is dropped and reported as not run, with the product owner's agreement.
Release 3.2: test cases in execution order

#  ID          Test case                             Impact  Likelihood  Score  Pri
1  TC-PAY-01   Deposit paid, booking confirmed       High    High        9      P1
2  TC-PAY-04   Card declined: no booking, no charge  High    High        9      P1
3  TC-BOOK-02  No-deposit booking (indirect change)  High    Medium      6      P1
4  TC-RES-03   Reschedule on the new screen          Medium  High        6      P1
5  TC-SCH-01   Doctor's free slots are listed        High    Low         3      P2
6  TC-PRO-05   Update profile phone number           Medium  Low         2      P3
7  TC-SMS-02   Reminder SMS, new Arabic template     Low     High        3      P2
8  TC-HLP-01   Help page links open                  Low     Low         1      P3

Common mistakes

  • Marking almost everything P1, so the label no longer says what to run first or what to cut.
  • Copying a defect's severity or priority onto a test case as its priority.
  • Rating only impact: a critical but stable, unchanged area can wait behind a medium-impact area that was just rewritten.
  • Setting priorities once and never reviewing them, although risk moves with every change.
  • Ignoring dependencies and environment windows, so a P1 case cannot run when its turn comes.
  • Dropping P3 cases silently instead of recording what was not run and who agreed.

The QA perspective

The tester usually proposes priorities: the product owner or business analyst supplies the impact, developers say what changed, and the test lead owns the definitions in the test plan. Record impact and likelihood next to the label, so anyone can see why a case is P2 and re-rate it next cycle.

During execution, report progress by priority, for example "P1: 4 of 4 run, 1 failed". Re-rate when the facts change: a cluster of defects in one screen raises the likelihood for every case that touches it.

Practice exercise

Prioritise a grocery shop release

Your task

Release 2.8 of a grocery web shop adds a promo-code field at checkout; nothing else changed. Rate each test case in the material, assign P1, P2 or P3 with this lesson's matrix, and write the execution order.

Then decide what you would drop if the cycle were cut in half, and how you would report it.

Material
Release 2.8: new promo-code field at checkout. Nothing else changed.

TC-01  A valid promo code reduces the order total correctly
TC-02  An expired promo code is rejected and the total is unchanged
TC-03  Place an order and pay by card (payment unchanged; uses the changed checkout)
TC-04  Order history shows the discount line
TC-05  Save a new delivery address (unchanged)
TC-06  Search products by name (unchanged)

Constraints
- The payment sandbox is available only in the morning.
- TC-03 needs a saved delivery address, created by TC-05.
Steps
  1. Rate impact and likelihood for each case.
  2. Multiply and map each score to P1, P2 or P3.
  3. Order the cases around the dependency and the sandbox window, without changing any label.
  4. Mark what you would cut first and write one line for the test report.
Show the model answer
Model answer

TC-01: High impact (wrong totals cost money) × High likelihood (new code) = 9, P1. TC-02: High × High = 9, P1; an expired code that is accepted is an unauthorised discount. TC-03: High × Medium (the payment code is unchanged; the order only passes through the changed checkout) = 6, P1. Rating its likelihood High gives 9 and the same P1.

TC-04: Medium × Medium (it reads the changed order data) = 4, P2. TC-05: High × Low = 3, P2; unchanged, but no address means no order. TC-06: Medium (customers can still browse the shop without search) × Low = 2, P3.

Order: TC-05 as setup, TC-03 in the morning sandbox window, then TC-01, TC-02, TC-04 and TC-06. TC-05 runs early only because TC-03 needs it; it stays P2.

With half the time, cut TC-06 first, then TC-04 if needed, never a P1, and report it: "P3 case TC-06 not run; risk accepted by the product owner."

Frequently asked questions

Who decides the priority of a test case?

The tester usually proposes it, because the tester knows the test cases. The inputs come from others: the product owner or business analyst for impact and developers for what changed. The test lead or test manager owns the definitions in the test plan and settles disagreements.

Is test case priority the same as defect priority?

No. Both express business importance, but of different things. Defect priority says how soon a known defect should be fixed. Test case priority says how soon a test case should run and whether it can be skipped this cycle. A failing P1 test case can produce a defect of any priority.

Can I use the Risk-Based Test Generator for the ratings?

Yes. It scores features by likelihood and impact on a 1 to 5 scale with its own Critical, High, Medium and Low levels, and produces a ranked plan. Rate on its scale instead of copying the 1 to 3 scores from this lesson, then map its levels to your team's P1 to P3 definitions.

Should P3 test cases be deleted?

Not because they are P3. A P3 case can become P1 when its area changes. Remove or merge a case only when it is obsolete or duplicates another one; the next lesson, on reusable and regression test cases, covers that maintenance.

References

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
  • ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
Tools

Practise with Mutqan tools

Risk-Based Test Generator

Score features by likelihood and impact, then generate a prioritised risk-based test plan.

Test Design

Requirements → Test Cases

Convert a list of numbered requirements into traceable test cases with a requirement-to-test matrix.

Test Design

Test Case Generator

Generate structured test cases (id, title, preconditions, steps, expected result, priority) from a feature description and field list.

Test Design

Go deeper

Your progress on this topic

Part of the QA Roadmap