How to Ask

3 min read

There is no syntax to learn, which makes the useful advice less about phrasing than about what to do with the answer you get.

Say It the Way You Would Out Loud

Oracle is built for the sentence you would say to a colleague, not for a query language wearing English clothes. 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 do not need to name fields, match your own capitalisation, or know that “blocker” and “critical” are two separate severities. Write the thought; Oracle resolves the vocabulary.

Start Broad, Then Narrow

The instinct with a search box is to write the most precise question possible on the first try. With Oracle it is faster to do the opposite.

Ask the broad version — Open defects.
Read the count and the conditions it applied.
Narrow it — Open critical or blocker defects, then Open critical defects with no test case linked.

A broad question that returns too much still tells you the shape of your data. A precise question that returns nothing tells you almost nothing — you cannot see whether the answer is genuinely empty or whether one condition was read differently than you meant.

Correct It With the Conditions, Not the Question

This is the habit worth building. Every answer prints Understood as — the conditions Oracle applied, in resolved terms.

When something is wrong, remove the condition rather than retyping the question. Select its × and the answer re-runs immediately, calling no model. Retyping asks Oracle to plan the whole thing again from scratch and may resolve something else differently on the way.

The same holds for sorting a column, asking for more rows, changing a chart type or its window. All of it re-runs on the plan you already have.

Let It Ask You Back

A question that is answerable but underspecified comes back as one short question 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 is a full re-ask: Oracle plans the original question again, now settled by your reply. That is unlike removing a condition, and it is why an underspecified question is worth avoiding rather than worth relying on.

Ask for Records, Not Arithmetic

Oracle returns records or counts them. It does not sum, average or group — those are Observatory’s job, and a question that needs them comes back as unanswerable rather than approximated.

Ask Oracle	Ask Observatory
`How many automated test cases are there?`	Average execution time by folder
`Open defects that are overdue`	Defect count trended by week
`Releases that are risky`	Pass rate rolled up per team

Use Your Own Words for Your Own Things

Folder names, labels, release titles, custom field options and team members are read fresh from your project each time you ask, so anything you created is immediately askable:

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 — “There is no member called Sarah” — rather than returning an empty table you would have read as good news.

Questions Worth Asking Regularly

Some questions are worth a habit rather than a one-off. These are the ones teams come back to:

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 feeling untidy

The Question Cookbook groups more of these by the job they belong to.