Test plan: turning an idea into verifiable cases
A test plan is not a bureaucratic document, but a working tool that helps you not forget important checks and agree on success criteria in advance. The 'Test plan' tool accepts a textual description of an idea and a platform, then forms a structured list of cases: successful, failed, and boundary. In this article we’ll explore how to prepare input data, what exactly to write in the 'Your text or idea' and 'Platform or application' fields, what a realistic password reset example looks like, and how to check the result. We will also discuss tool limitations so you don't expect the impossible. The password scenario is fictional and shown only for illustration.
Open tool: Test plan builder ↗What is a test plan and why do you need it
A test plan is a list of checks you need to perform to ensure a function works correctly. Unlike a checklist, it includes not only successful scenarios but also failed ones, as well as boundary conditions. A successful case describes how the system should work with correct data: for example, a user enters a valid password and gains access. A failed case checks the reaction to an error: wrong password, empty field, expired link. Boundary cases are found at the intersection of permissible and impermissible: minimum password length, maximum number of attempts, the oldest valid token.
Why is this needed? Without a well-thought-out plan, testers often check only obvious scenarios, and errors hide precisely at the boundaries. The tool helps quickly generate such cases based on a textual description. You get a draft that you then refine for your system. This saves time at the test design stage and reduces the risk of missing an important check.
Important to understand: the tool does not run tests and does not check code. It only offers a structure. Everything it outputs must be adapted to real requirements, environment, and data.
Example request: 'Password reset form that sends a one-time link to email. Platform: web application'. Output — a list of 10–15 cases with explanations.
How to prepare input data for the tool
The first field — 'Your text or idea' — accepts up to 8000 characters. Here you need to describe a function or process you want to test. The more specific the description, the more useful the result. Indicate what the function does, what its inputs and outputs are, what known limitations exist. For example: 'User requests a password reset, enters email, receives a letter with a link, clicks it and sets a new password. The link works for 15 minutes and can be used only once'. Avoid generic phrases like 'make it well' — they give the tool no hooks.
The second field — 'Platform or application' — up to 1000 characters. Specify the platform type: web, mobile application, desktop, API. This affects case formulations: for mobile apps, interruptions matter; for APIs, response codes matter. If the platform is not specified, the tool may propose overly general checks.
You don't need to write a full technical specification. 3–5 sentences with key details are enough. If you have special requirements (e.g., 'password must contain at least 8 characters'), be sure to include them — this helps generate accurate boundary cases.
Good input: 'Password reset via email. User enters email, receives a link, goes to page and sets a new password. Link is single-use, valid for 15 minutes. Password 8 to 20 characters, must contain letters and digits. Platform: web application, Chrome and Firefox browser'.
Result structure: success, failure, boundaries
The tool generates three groups of cases. Successful cases describe expected behavior with correct data. For example: 'User enters a registered email, receives a letter, clicks the link, enters a new password matching requirements, and sees a success message'. Such cases help verify that the main scenario works.
Failed cases check error handling. Examples: 'Entered an unregistered email — system must not reveal whether the user exists, but must show a neutral message', 'Link already used — clicking it must lead to an error page and an option to request a new one', 'Entered a password shorter than 8 characters — form must show an error message and not save the password'. These cases are important for usability and security.
Boundary cases are at the limits of the permissible. For example: 'Password exactly 8 characters — should be accepted', 'Password exactly 20 characters — should be accepted', 'Link used after 14 minutes 59 seconds — should work', 'Link used after 15 minutes 1 second — should be rejected'. Such checks often reveal logic errors in conditions.
Output fragment: 'Boundary case: email with maximum length of 254 characters — should be accepted if domain exists. Failed case: email without @ symbol — form must show validation error'.
Realistic example: password reset
Suppose you are testing a password reset form. Enter the description: 'User enters email, clicks "Forgot password", receives a letter with a link. Link leads to a page where you need to enter a new password twice. Password 8 to 20 characters, contains letters and digits. Link valid for 15 minutes and single-use. Platform: web application'. The tool can output a plan.
Successful cases: 1) Registered email, correct new password — password changed, success shown. 2) Link opened in the same browser — form displayed. 3) Password entered with upper and lower case letters — accepted. Failed: 1) Unregistered email — neutral message, no letter sent. 2) Expired link — error page and button to request a new one. 3) Passwords do not match — error message. 4) Password contains only letters — error. Boundary: 1) Password exactly 8 characters — accepted. 2) Password exactly 20 characters — accepted. 3) Password 7 characters — rejected. 4) Link used after 14:59 — works. 5) After 15:01 — does not work. 6) Repeated link use — rejected.
This example shows how a short description turns into 12–15 specific checks. You can copy the result into a text file and use it as a basis for test cases.
Request: 'Password reset via email. Link single-use, 15 minutes. Password 8–20 characters, letters and digits. Web application'. Output: list of 14 cases with explanations.
How to verify and refine the result
After generation, carefully read each case. Make sure it corresponds to your system. The tool may propose checks that don't exist in your product, or miss specific limitations you have. For example, if you have a CAPTCHA, add cases with it. If the password must contain a special character but this wasn't in the description, the tool cannot account for it.
Check that boundary values are specified exactly. If the description says 'from 8 to 20', boundaries will be 8 and 20, as well as 7 and 21. Make sure for each case the expected result is clear. If the wording is vague, rewrite it in your own words.
Add cases related to security: for example, check that the link does not contain the open password, that after reset all active user sessions are terminated. The tool may not know all security requirements, so final responsibility rests with you.
After generation you add a case: 'After successful password reset all active user sessions must be terminated'. This requirement was not in the original description, but is important for security.
Tool limitations and typical errors
The tool is not a tester and does not know your codebase. It cannot guarantee that all cases are covered. Its output is a draft that needs adaptation. Do not blindly copy cases into a bug tracker without verification.
The tool does not support document upload, does not work with images, and does not generate audio. It is a text assistant. It does not check code, does not run tests, and does not connect to your system. All length limits are specified in the interface: 8000 characters for description and 1000 for platform.
Another mistake — too general a description. If you write 'test the form', the result will be superficial. The more details you give, the more precise the cases will be. Also do not expect the tool to propose non-standard checks that require domain knowledge. Your expert knowledge remains decisive.
Poor input: 'Login form'. Good input: 'Login form with email and password. Lockout after 5 failed attempts. Password minimum 8 characters. Platform: web'.
The 'Test plan' tool helps quickly create a structured list of checks for everyday tasks. It saves time at the test design stage, but does not replace analytics and a tester. Use it as an idea generator, then refine cases for your system. Remember the limitations: text format, no integrations, no guarantees. The password scenario is a fictional example showing how a short description can yield a useful plan. Start with a clear function and platform description, check the result, and supplement it with missing checks. Such an approach makes testing more systematic and predictable.
Open tool: Test plan builder ↗Interface translations are machine-assisted and may need refinement.