How to Ask

3 min read

There is no syntax to learn. The useful habits are about how you start and what you do with the answer.

Say It the Way You Would Out Loud

Write the sentence you would say to a colleague. All of these work as written:

Automated test cases created in the last 10 days that have never been executed
Open critical or blocker defects
Requirements that have tests but nothing passing

You don’t need to name fields, match capital letters, or know that “blocker” and “critical” are two separate severities. Write what you mean; Oracle matches it to your project’s fields and values.

Start Broad, Then Narrow

It is tempting to write the most precise question you can on the first try. With Oracle it is faster to do the opposite.

Ask the broad version, such as Open defects.
Read the count and the conditions it used.
Narrow it down: Open critical or blocker defects, then Open critical defects with no test case linked.

A broad question that returns too much still shows you the shape of your data. A precise question that returns nothing tells you very little: you can’t tell whether the answer really is empty or whether one condition was read differently from what you meant.

Correct It With the Conditions, Not the Question

This is the habit worth building. Every answer shows Understood as: the conditions Oracle used, each with the exact date, name or value it picked.

When something is wrong, remove the condition instead of retyping the question. Select its × and the answer updates straight away. It doesn’t use AI again, so it is instant and doesn’t count toward any limit.

Retyping makes Oracle work out the whole question again, and it may read some other part differently this time. Editing the conditions changes only what you touched.

The same goes for sorting a column, loading more rows, or changing a chart’s type or time window: none of these use AI again.

Let It Ask You Back

If a question can be answered but is too vague, Oracle asks one short question back, with two to four answers as buttons:

Show me the important ones Which did you mean? High priority test cases · Open critical defects · Releases at risk

Answering counts as asking again: Oracle works out your original question again with your answer added. Unlike removing a condition, this uses AI, so a clear question is better than relying on a follow-up.

Ask for Records, Not Sums

Oracle lists records, counts them, or counts them per group. It doesn’t add up or average a column. That is Observatory’s job, and a question that needs it gets a “can’t answer” instead of a rough guess.

The line is between counting and calculating. Defects by severity is a count per group, so Oracle answers it. Average time to close by severity averages a column, so it doesn’t.

Ask Oracle	Ask Observatory
`How many automated test cases are there?`	Average execution time by folder
`Defects by severity`	Defect count trended by week
`Open defects that are overdue`	Pass rate added up per team
`Releases that are risky`	Mean time to resolve, by assignee

Counting Per Group

A question with per, by, each or which has the most comes back as one line per value, with its count, biggest first.

How many test cases per folder
Defects by severity
Failures per requirement in release 4.2
Releases by readiness verdict
How many never-executed test cases per folder

Three limits apply, and Oracle tells you when you hit one:

One category at a time. A status, a person, a folder or a linked record. Not a title, not a date, and not two fields crossed against each other. Two fields crossed is a chart.
A record linked to several values counts under each. A test case traced to three requirements counts as a failure for all three, which is what failures per requirement means. So the counts can add up to more than the records matched.
No calculated columns alongside a group. Releases by verdict works; asking for each release’s readiness score as well doesn’t, because a group is a count, not one release.

Use Your Own Words for Your Own Things

Folder names, labels, release titles, custom field options and team members are read from your project each time you ask, so anything you created can be asked about straight away:

High priority test cases in the Checkout folder
Test cases labelled smoke
Defects assigned to Priya
Test cases in the Smoke run

If a name is wrong, Oracle says so, for example “There is no member called Sarah”, instead of returning an empty table that looks like good news.

Questions Worth Asking Regularly

Teams come back to these:

Test cases that have never been executed: before planning a run
Requirements with no test coverage: before closing a scope
Releases where failures have no defect recorded: before sign-off
Labels nobody uses: when the repository starts to feel untidy

The Question Cookbook groups more of these by task.