Test Plan: How to Create a Precise Task for the Tool

Why Precise Input Matters

The tool does not guess context. If you write 'test the form', the result will be generic: checking fields, buttons, error messages. But without specifying the goal, platform and limits the plan will remain superficial. The more specific the input, the more meaningful the cases: the tool can propose checks related to real risks, not just standard 'empty field' and 'wrong format'.

The 'Your text or idea' field accepts up to 8000 characters, the 'Platform or application' field up to 1000 characters. This is enough to describe a function, its purpose, key scenarios and special conditions. You do not need to write a full technical specification — enough compressed but precise description.

A good input answers the questions: what are we testing, why, in what environment, what are the limits and what counts as success or failure. If even one of these points is missing, the plan may be incomplete.

Bad: 'password reset form'. Good: 'Password reset web form: user enters email, receives a one-time link email, clicks it and sets a new password. Platform: web, desktop and mobile browsers. Limits: link valid for 15 minutes, resend not more than once per minute'.

What to Specify in the Input: Context and Goal

Context is the environment in which the function works. Specify the platform (web, mobile application, desktop), user type, integrations with external services. For example, if password reset sends an email via a third-party service, this affects checking delays and resend checks.

Goal — what exactly you want to check. Formulate it as a result: 'ensure the user can reset password without support help', 'check that the link does not work after the term expires'. The goal helps the tool prioritize cases between scenarios.

Do not mix goal and implementation. The tool does not know your codebase, so phrases like 'check that validateEmail function returns true' are useless. Describe behavior visible to the user or system.

Context: 'Taxi ordering mobile app, trip confirmation screen'. Goal: 'Ensure user can confirm trip, cancel it before driver arrival and receive correct message on network loss'.

Format and Limits: What to Add

Output format can be set in words: 'need separate blocks for successful, failed and boundary cases', 'add reproduction steps', 'specify expected result for each case'. The tool has no output settings, but textual format indication influences the answer structure.

Limits are rules that cannot be broken. For example: 'password must contain at least 8 characters, one digit and one uppercase letter', 'one-time link', 'maximum 5 code entry attempts'. Limits turn into boundary cases: exactly 8 characters, 7 characters, 9 characters, no digit, repeated link use.

If there are no limits, state it explicitly: 'no special limits, except standard email validation'. Otherwise the tool may invent non-existent rules, and the plan will contain unnecessary checks.

Limits: 'Confirmation code consists of 6 digits, valid for 10 minutes, allows 3 input attempts. After third failed attempt form blocks for 5 minutes'.

Example of Bad and Good Task

Bad task: 'Test system login'. There is no platform, goal, limits. The tool may output generic cases: empty login, wrong password, successful login. But it will not account for lockout after several attempts, password recovery, social login or behavior on expired session.

Good task: 'Web application, login with email and password. Goal: check successful login, errors with wrong data and lockout after 5 failed attempts. Limits: password 8 to 32 characters, lockout for 15 minutes, session expires after 30 minutes inactivity. Platform: desktop browsers Chrome and Firefox. Need successful, failed and boundary cases with reproduction steps'.

The difference is clear: in the second case the tool gets enough data to propose checks for password length, number of attempts, lockout time and session expiry. This does not guarantee completeness, but makes the plan specific and applicable.

Good input for the tool: 'Password reset web form. User enters email, receives one-time link email, clicks it and sets new password. Platform: web, desktop and mobile browsers. Limits: link valid for 15 minutes, resend not more than once per minute, new password minimum 8 characters. Need successful, failed and boundary cases'.

How to Check the Generated Plan

After generation read the plan and verify it covers three categories: successful cases (function works as intended), failed (errors, refusals, wrong data) and boundary (values on the limits of acceptable). If any category is missing or represented by one point, refine the input and generate again.

Cross-check cases with your limits. If the plan has a check for 7-character password but minimum is 8, that is a boundary case. If there is a check for 100 characters but maximum is 32, that is also a boundary. Make sure such cases do not contradict your rules.

Check reproduction steps: they should be executable without guessing. If a step sounds like 'enter correct data', it is too vague. A good plan specifies exactly what data and in what order. Remember the model may err, so final decision on including cases is yours.

Check: in the password reset plan there is a case 'click link after 15 minutes'. This boundary case matches the limit. If there was a case 'link valid for 24 hours', it would contradict the input.

Tool Limits and Typical Errors

The tool works only with text: it does not run tests, does not connect to your application and does not check real behavior. The result is a draft plan that needs adaptation to your project. It does not replace exploratory testing and does not guarantee detection of all defects.

A typical error — overloading the input with technical details that do not affect behavior. For example, specifying framework version or database structure does not help the tool propose better cases. Better to focus on user scenarios and rules.

Another error — expecting the tool to invent limits itself. If you do not specify that the link is one-time, it may propose a check for repeated transition, but will not know it should be an error. Always list key rules explicitly.

Remember limits: input field up to 8000 characters, platform field up to 1000 characters. If description is too long, shorten it to the essence. The tool does not save history and does not perform batch processing, so each request must be formed separately.

Error: 'Test everything'. Result will be generic. Fix: 'Test order form in online store: product selection, cart, address input, card payment. Limits: minimum order 500 rubles, delivery only to Russia. Need cases for successful payment, bank refusal and wrong address'.