Question Cookbook

3 min read

Every question on this page is one Oracle answers.

Copy one as it is written, or use it as the shape for your own.

Repository Hygiene

The questions that find what has quietly gone stale. Most of these are hard to build as a filter and trivial to ask.

Ask	Finds
`Test cases that have never been executed`	Cases written and then forgotten
`Test cases that have never been added to any run`	Worse than never executed — never even scheduled
`Test cases not run in the last 10 days`	Coverage that has gone cold
`Test cases with no requirement linked`	Cases nobody can trace to a reason
`Labels nobody uses`	Vocabulary that has outlived its purpose
`Shared steps nobody uses`	The same, for shared steps
`Which labels do we use most`	Which of your labels actually carry meaning

Automation Drift

Where what a case says about itself and what a pipeline does have come apart.

Ask	Finds
`Automated test cases no pipeline has ever run`	Marked automated, never actually automated
`Test cases a pipeline runs that are not marked automated`	The reverse — real automation, wrong label
`Automated test cases created in the last 10 days that have never been executed`	New automation that has not proven itself yet
`Flaky test cases`	Cases that pass and fail without the code changing

These two are worth running as a pair. Each one finds a different half of the same problem, and a repository can have plenty of both.

Coverage Gaps

Ask	Finds
`Requirements with no test coverage`	Promises nothing tests
`Approved requirements with no test coverage`	The same, narrowed to what is actually agreed
`Requirements that have tests but nothing passing`	Covered on paper, unproven in practice
`Defects with no test case linked`	Bugs found once that could be found again
`Open critical defects with no test case linked`	The urgent half of that

Requirements that have tests but nothing passing is the one people do not think to ask. A coverage report counts the link; this counts the result.

Release Readiness

Ask	Finds
`Releases that are risky`	Anything not on track to ship
`Releases with open blocker or critical defects`	The specific bar that most often fails
`Releases where failures have no defect recorded`	Failures nobody wrote up
`Explain why the August release is not healthy`	The reason, in words, for one release
`Test runs signed off with unassigned work left in them`	Runs closed with work still unclaimed
`Test runs still in progress that are healthy`	What is going fine, so you can leave it alone
`Test runs that are failing heavily`	Where to look first
`Release executions that have stalled`	Started, then abandoned

See Readiness Questions for what these signals mean and how they are computed.

Defect Triage

Ask	Finds
`Open critical or blocker defects`	The queue that matters today
`Open defects that are overdue`	What has slipped its date
`Defects assigned to Priya`	One person’s load
`Defects with no test case linked`	Bugs with no regression guard

Counts, Broken Down

Ask per, by, each or which has the most and the answer is one line per value with its count, biggest first, instead of a list to tally.

Ask	Finds
`How many test cases per folder`	Where the repository is thick and where it is thin
`Defects by severity`	The triage shape, in one line each
`Failures per requirement in release 4.2`	Which requirement is taking the damage
`Releases by readiness verdict`	How many are ready, at risk, blocked
`Which gate fails most often across our releases`	The bar the team keeps missing
`How many never-executed test cases per folder`	Untested areas, ranked
`Open defects counted by assignee`	Where the queue actually sits
`Shared steps by scope`	How many are workspace-wide versus local to this project

Two things worth knowing before you read a total. Grouping is by one category — a status, a person, a folder, a linked record — so two fields crossed against each other is a chart instead. And when the thing you group by is a list, a record counts under every one of its values: a test case tracing to three requirements is a failure for all three, so the counts can add up to more than the records matched.

Your Own Work

Ask	Finds
`My open defects`	Yours, without naming yourself
`Test cases assigned to me that are blocked`	What you cannot move
`Recent test cases`	What you have opened lately — not what changed
`Test cases changed in the last week`	What actually moved, whoever moved it
`Test cases created this month`	What is new, rather than what was edited
`Test cases in the Reporting folder that I have looked at`	Narrowed to what you have actually opened

me and my resolve to you, so these work unchanged for everyone on the team.

Those last three are three different questions and are easy to confuse. Recent is what you opened; changed is when the record itself last moved; created is when it was written. A case nobody has touched since it was written has no change date at all, rather than one backfilled from its creation.

Finding Things by Your Own Vocabulary

Your folders, labels, releases and runs are all askable by name:

High priority test cases in the Checkout folder
Test cases labelled smoke
Test cases in the Smoke run
Test cases that are in a release / Test cases that are in no release
Test cases about signing in or out

That last one matches on the subject of a case rather than on a field, which is useful when your team has never agreed on a label for it.

Settings and Configuration

The records behind your project are queryable too, which makes them auditable.

Ask	Finds
`Which custom fields are required`	What your team is forced to fill in
`Custom fields shown on defects`	What a defect form actually asks for
`Custom fields that are not set up in this project`	Workspace fields this project never configured
`Workspace level parameters`	Parameters shared beyond this project
`Shared steps in this project only`	The ones not shared workspace-wide
`Shared steps by scope`	How many of each, counted — and every row now says which it is