State the test.See the outcome.

Conditions

Choose a person or role involved in the task. A system component is not a substitute for the person accepting the outcome.

Name one task and its purpose. A broad feature label hides the decision that the user actually makes.

Record the initial state only when it changes what should happen. Keep the setup separate from the action.

Describe one user action or event. Avoid implementation details that the user cannot observe.

State a result that a tester can compare with what actually appears or arrives.

An ambiguous rule stays open for clarification; a polished sentence cannot turn it into a verified requirement.

Private draftSources in contextVisible outcomes

01Person

Whose task?

02Action

What changes?

03Result

What can be observed?

A feature request becomes a useful criterion when these pieces connect.

Write the actor, starting condition, action and visible outcome. The frame exposes missing parts; it does not decide whether a product meets them.

Editable examples

Choose a person or role involved in the task. A system component is not a substitute for the person accepting the outcome.

A drafted test, an observed result and a release decision are different events. Keep each one tied to the product you actually checked.