Prompt Not Working? Check These 6 Essentials

1. Role: Tell AI Which Professional Viewpoint to Use

A role tells AI how to approach the work.

For example:

Act as a senior QA engineer reviewing a payment requirement.

This is more useful than saying:

Act as an expert.

The first prompt identifies the professional viewpoint and the type of work involved. The word “expert” alone does not provide this direction.

Different roles focus on different risks. A security tester may look for authentication problems, misuse and data exposure. An accessibility tester may look at keyboard use, focus order, labels and error messages. A test automation architect may focus on code structure, reliability and maintenance.

However, a role cannot provide missing product information. If the requirement does not state whether an account should be locked after three failed attempts or five, calling AI a “world-class testing expert” will not provide the answer.

Use a role to set the viewpoint. Do not expect the role to replace facts about the product.

Weak:

You are a testing expert.

Better:

Act as a senior API test engineer. Review an order-creation API for functional, validation and idempotency risks.

A role is useful when the work needs a particular type of QA knowledge. It may not be needed for a simple task such as correcting the grammar in a defect description.

2. Context: Explain the Situation

Context is the background information that helps AI understand the task correctly.

It may answer questions such as:

• What product or feature are we testing?
• Who will use it?
• Is it a web, mobile or API feature?
• Is the feature being discussed, developed or already released?
• Which business risks are important?
• What dependencies are already known?

Suppose we ask AI to create checkout tests. The important tests will be different for an e-commerce application, a subscription service and an internal purchasing system. Information about guest checkout, payment options, stock handling and payment retries will change the tests.

Weak:

Review this checkout requirement.

Better:

This requirement is for an Indian e-commerce website. Customers can check out as guests or registered users. This release adds UPI payments. The payment provider sends the final payment status later. Creating the same order twice is a major business risk.

Provide the background that can change the answer. Do not add information just to make the prompt longer.

For example, pasting a complete product manual may make it harder to identify the few rules that matter to the current feature. If a long document is necessary, tell AI which sections are relevant and which information it should rely on.

Also separate confirmed facts from assumptions. For example:

The requirement does not mention the account-locking limit. Do not choose a limit. Add it as a question that needs clarification.

This prevents AI from presenting an invented rule as a confirmed requirement.

3. Task: Say Exactly What AI Must Do

The task is the action you want AI to perform.

Use clear words such as analyse, identify, compare, classify, prioritise, review, rewrite or generate.

For example, “Help me with this requirement” is not a clear task. AI does not know whether it should summarise the requirement, find gaps, create tests or rewrite it.

Weak:

Check this user story and give me everything.

Better:

Review the user story. First, identify unclear or missing acceptance criteria. Next, list the main product risks. Finally, suggest test scenarios based only on the information in the story.

If you want AI to complete more than one activity, list the activities in the order in which they should happen.

Do not place too many different activities in one prompt. Asking AI to review a requirement, find gaps, generate tests, write Playwright code and design a CI pipeline at the same time can produce a confusing answer. Complete and review one stage before moving to the next when the work is complex.

Also tell AI what to do when the information is not enough:

If a test requires a business rule that is not provided, do not assume the rule. Add a question for the Product Owner.

This gives AI a clear action instead of leaving it to guess.

4. Input: Provide the Content or Data AI Needs

Input is the content or data AI needs to complete the task.

Examples of input include:

• a user story and its acceptance criteria
• an API specification
• a defect description
• application logs
• existing test cases
• automation code
• a test execution report
• a database table or sample data

The difference between context and input is important.

• Context explains the situation around the work.
• Input is the content or data AI will work with.

For example:

Context: This is a banking application. Password reset is a high-security feature.

Input: The password-reset user story and acceptance criteria shown below.

The input changes with the task. If the task is to review a requirement, the requirement is the input. If the task is to find the cause of a failed test, the error message, log and related code are the inputs. If the task is to improve existing test cases, those test cases are the input.

Clearly separate instructions from input. Headings or simple tags make the prompt easier to follow:

## Requirement
As a registered customer, I want to reset my password using a link sent to my registered email address.

## Acceptance criteria
- The reset link expires after 15 minutes.
- The link can be used only once.
- The new password must follow the existing password policy.

This format tells AI exactly which text is the requirement and which text contains the acceptance criteria.

Clear separation is especially useful when the input comes from Jira tickets, customer messages, logs or documents written by other people. Some of that text may look like an instruction. Labels help show which text contains your instructions and which text is the material for the task.

The input must also contain enough information for the task. If you ask AI to create exact API tests but provide only the endpoint name, important details are missing. AI may also need the request fields, authentication rules, valid responses, error responses and business rules.

An answer may look complete even when important input is missing. Always check whether you provided the content and data needed for the task.

5. Constraints: Tell AI the Rules and Limits

Constraints explain the rules and limits AI must follow.

Examples include:

• Use only the supplied requirement. Do not create new business rules.
• Keep confirmed behaviour, assumptions and open questions separate.
• Cover positive, negative, boundary and state-change scenarios.
• Mark each scenario as High, Medium or Low priority.
• Explain why every High-priority scenario is important.
• Do not include visual-design checks.
• Use Playwright with TypeScript and the existing Page Object Model.
• Do not repeat passwords, tokens or personal information found in the log.
• Return only the 12 most important scenarios.

These instructions keep the response focused. For example, “Generate comprehensive test cases” may produce a long list that is difficult to review. “Return the 12 highest-risk scenarios” tells AI to focus on what matters most.

Tell AI what it should do, not only what it should avoid.

Less useful:

Do not hallucinate.

Clearer:

Create scenarios only from the supplied requirement. If information is missing, write “Not specified” and add a clarification question.

The second version clearly tells AI what to do when information is missing.

Prompts alone cannot guarantee that every rule will be followed. If the answer must use valid JSON, follow a fixed schema or exclude sensitive information, the system using the answer should check these conditions. Important AI-generated work still needs automated checks, human review or both.

Make sure the constraints do not conflict with one another. For a complex feature, asking AI to “cover every possible case,” “be brief” and “return no more than five scenarios” may be impossible. Decide which instruction is most important.

6. Expected Output: Explain How the Answer Should Be Presented

Expected output explains how AI should structure and present the answer, including the level of detail needed.

Without this instruction, AI may return useful information in a form that is difficult to use. One response may be a paragraph, another may be a checklist and another may be a large table.

For a test-design task, you could ask:

Return a Markdown table with these columns: ID, scenario, precondition, steps, expected result, priority and requirement reference.

For requirement analysis, you could request four sections:

1. Requirement summary
2. Missing or unclear information
3. Product risks
4. Questions for the Product Owner

If another tool will use the answer, a format such as JSON may be better. In that case, define the field names, the values allowed in each field and what AI should return when information is missing. The application should still validate the JSON before using it.

Expected output is not only about the format. It can also explain who will read the answer and how much detail they need:

Write for a QA lead preparing for a refinement meeting. Keep every clarification question to one sentence. For each question, explain why the answer matters to testing.

If the required style or classification is difficult to explain, provide one or two examples. Examples can show AI exactly what an acceptable answer looks like. They are useful when the output must follow a special format, tone or decision rule.

Putting the Six Essentials Together

Here is a complete prompt for reviewing a password-reset requirement:

## Role
Act as a senior QA engineer preparing for a requirement-refinement meeting.

## Context
This is a customer-facing banking website. Account security and personal-data protection are very important. The feature is still being discussed, and no test cases have been approved.

## Task
Review the requirement. Identify unclear or missing acceptance criteria, list the main quality risks and propose the most important functional test scenarios.

## Input
<requirement>
As a registered customer, I want to reset my password using a link sent to my registered email address.

Acceptance criteria:
- The reset link expires after 15 minutes.
- The link can be used only once.
- The new password must follow the existing password policy.
</requirement>

## Constraints
- Use only the information provided above.
- Do not assume how the system handles unknown email addresses, repeated requests or existing login sessions.
- Add missing information as clarification questions.
- Include positive, negative, boundary and security-related scenarios.
- Set priority based on customer and security risk.
- Return no more than 12 test scenarios.

## Expected output
Return four sections:
1. Requirement summary — no more than 80 words.
2. Clarification questions — a table with Question and Why It Matters.
3. Quality risks — a table with Risk, Impact and Priority.
4. Test scenarios — a table with ID, Scenario, Expected Result, Priority and Requirement Basis.

This prompt cannot guarantee a perfect answer. However, it makes the answer easier to review. We can check whether AI used the given requirement, followed the rules, identified missing information and returned the requested format.

From a Vague Prompt to a Useful QA Prompt

Compare these two prompts.

Vague prompt:

Generate API test cases for creating an order.

Clearer prompt:

Act as an API test engineer. We are testing POST /orders for an e-commerce application. The request contains a customer ID, one or more product IDs, quantity and shipping address. The API uses bearer-token authentication. Stock may change while the request is being processed, and clients may retry the request after a timeout. Review the supplied OpenAPI operation and generate the 15 highest-risk test scenarios. Cover request validation, authentication, authorisation, inventory, totals, repeated submissions and idempotency. Do not create response codes that are not present in the specification. List any missing response code as an API contract gap. Return a table with Scenario, Request Change, Expected Result, Risk and Automation Suitability.

The second prompt is not better simply because it is longer. It is better because it answers important questions that were left open in the first prompt.

A Good Prompt Should Be Tested

QA professionals already know how to check whether requirements and software behave as expected. We should apply the same thinking to prompts.

Do not decide that a reusable prompt is good after seeing one successful answer. Test it with different types of input:

• a clear requirement and an unclear requirement
• complete information and missing information
• a small document and a large document
• valid data and incorrectly formatted data
• a simple case and a case containing conflicting rules

Then review the answers using clear questions:

• Did AI use the information provided?
• Did it clearly separate facts from assumptions?
• Did it follow the requested format?
• Did it identify the important risks?
• Did it handle missing information without inventing an answer?

Different models, and even different versions of the same model, may respond differently. If a prompt is used regularly, keep a small set of sample inputs and expected checks. Run them again when the model, prompt, tools or source information changes.

Treat an important prompt like any other QA asset: give it an owner, keep versions and test it after changes.

Use the 3Cs as a Final Check

The six essentials help you build a prompt. The 3Cs help you review the completed prompt:

• Clarity: Is the task specific, and is the expected output clear?
• Context: Have you provided the background information and input AI needs for the task?
• Constraints: Have you explained the rules, limits and what AI should do when information is missing?

The 3Cs do not replace the six essentials. They provide a quick final check.

A prompt may contain a detailed user story and still fail this check. The task may be unclear. An important business risk may be missing. AI may not know whether to ask a question or make an assumption. The 3Cs help us find these problems before they appear in the answer.

Do You Need All Six Essentials Every Time?

No. A small request may need only a task and an input:

Rewrite these five defect titles so they are shorter without changing their meaning.

Add the other parts when the work becomes more complex or the risk of misunderstanding increases. A reusable requirement-review prompt needs more detail than a one-time grammar correction.

The goal is not to make every prompt long. The goal is to provide the information AI needs to give a useful answer.

Before using an important prompt, check:

• Role: Does AI need to approach the task from a particular professional viewpoint?
• Context: Have you provided the background information AI needs to understand the task?
• Task: Have you clearly stated what AI must do?
• Input: Have you provided all the content or data AI needs to complete the task?
• Constraints: Have you explained what AI must include, avoid and do when information is missing?
• Expected output: Have you clearly described how the answer should be structured and presented?

Finally, apply the 3Cs: Is the complete prompt clear? Does it provide enough context? Does it include the necessary constraints?

What Really Makes a Prompt Good?

A prompt is not good simply because it sounds technical. It is good when it produces an answer that is useful for the task and makes mistakes, assumptions and missing information easier to identify.

For QA professionals, the six essentials provide a practical structure. Give AI the right viewpoint. Explain the situation. State the task. Provide the content or data AI needs. Define the rules and limits. Describe how the answer should be presented.

The main idea is simple:

Do not make AI guess the testing assignment that you already understand. Explain the assignment clearly.

That is how prompting becomes a repeatable QA practice instead of a trial-and-error conversation.