Test Plan: How to Get Meaningful Success, Failure, and Boundary Cases
The Test Plan tool helps developers and testers quickly draft a testing structure: successful scenarios, failed ones, and boundary conditions. It is a web form with two text fields: 'Your text or idea' (up to 8000 characters) and 'Platform or application' (up to 1000 characters). You select the output language, press Generate, and get one result in a separate panel — plain text that can be copied or downloaded as a TXT file. Below we will explain how to formulate queries to get practically applicable plans, and how to check the generated result manually. All examples in the article are fictional illustrations, not results of actual runs.
Open tool: Test plan builder ↗What the Test Plan Tool Actually Does
'Test Plan' is a text-based test planning generator. The input consists of two fields: a description of an idea or functionality and an indication of the platform or application. The output is a single text result in a separate panel. It can be copied or downloaded as a plain TXT file. The tool does not export to DOCX or PDF, does not perform batch processing, does not save history automatically, and does not integrate with task trackers. It is important to keep in mind: the result will have to be moved into your system manually.
The generation relies on a language model, so answers may contain errors, and queue and service availability may change. The tool does not know your codebase, business logic, or infrastructure. It does not check code and does not create test data. Its value lies in a quick draft of the structure: what checks are worth considering, where the boundaries are, what failures are possible.
Practical approach: treat the result as a first draft. Your task is to refine the formulations, add checks from your experience, and discard irrelevant ones. The more specific the input data, the more useful the draft.
Example query: 'Create a test plan for a password reset form that sends a one-time link to email. Platform: web application. Consider successful, failed, and boundary cases.'
How to Formulate a Query to Get Different Variants
The same functionality can be viewed from different sides. To get several drafts, change the emphasis in the query. The first option is functional: sending an email, following a link, changing a password. The second is security: link lifetime, re-use, attempt limits. The third is usability: clarity of messages, error handling, keyboard accessibility. Each emphasis will give its own set of checks.
A second lever is the level of detail. A general formulation will give an abstract plan, while specific parameters ('link valid for 15 minutes', 'password not shorter than 8 characters') will suggest more precise boundary cases. Specify the platform: web, mobile application, desktop — this changes the set of checks. If the platform is not specified, the model may offer universal, less useful items.
A third technique is to change the type of task. Instead of 'create a test plan' try 'list possible failure scenarios' or 'suggest boundary conditions for an email input field'. This shifts the generation focus and gives an alternative view. Save successful formulations to reuse for similar tasks.
Variant 1 (functionality): 'Test plan for password reset: successful email sending, link transition, password change'. Variant 2 (security): 'Test plan for password reset: link lifetime, protection against re-use, attempt limits'. Variant 3 (usability): 'Test plan for password reset: interface clarity, error messages, keyboard accessibility'.
How to Compare Generated Drafts
Compare plans by four criteria: coverage completeness, relevance to your task, clarity of formulations, and practical applicability. Start with the goal: if you are checking security, the most valuable option will be the one with a protection focus. If user experience is more important, choose the plan with a usability focus. Do not focus only on length: a short but precise plan is more useful than a long and vague one.
Pay attention to intersections and unique items. Duplication is normal, but it is useful to highlight checks that appear only in one variant. For example, the security plan might have a check for using a link after a password change, while the functional one checks the correctness of entering a new password. Combining unique items gives a more complete picture.
Separately evaluate boundary cases. A good plan includes minimum and maximum values, empty fields, incorrect formats, expired validity. Compare how thoroughly these aspects are detailed in each draft. Perhaps one plan describes boundaries better, while another covers main scenarios better.
Thoughtful comparison: Variant 1 — 10 cases (6 successful, 2 failed, 2 boundary). Variant 2 — 8 cases (3 successful, 3 failed, 2 boundary). Variant 3 — 12 cases (5 successful, 4 failed, 3 boundary). Take Variant 3 as a basis, supplement with unique checks from Variant 2.
Choosing a Basis and Manual Refinement
Choose one plan as a basis — not necessarily the longest, but more important matching your tasks. If none of the drafts covers everything needed, combine the best parts: structure from the first, boundary cases from the second, formulations from the third. Such a hybrid is usually more practical than trying to improve one unsuccessful variant.
Refinement includes checking each point for implementability and unambiguity. Make sure steps are understandable, and expected results are specific. Vague formulations are clarified manually. Add checks that the model might have missed, relying on your experience and knowledge of the system. Special attention — boundaries: they are often described superficially.
Remember the limitations: the tool does not know your codebase, does not take infrastructure into account, and does not guarantee error-free results. The final plan should always be reviewed by the team. Generated variants save time on structure, but require expert refinement.
After combining three drafts, a plan of 15 cases was obtained: 7 successful, 4 failed, 4 boundary. Added checks: link validity (15 minutes), link re-use, passwords with spaces, sending a letter to a non-existent email.
Practical Example: Password Reset Form
Consider a fictional scenario. Password reset form: a user enters an email, presses 'Send', receives an email with a one-time link, follows it and sets a new password. Platform — web application. We generated three drafts, changing the query emphasis.
Variant 1 (functional): successful cases — sending a letter to a registered email, following a link, changing a password; failed cases — entering an unregistered email, incorrect format, empty field; boundary cases — maximum email length, link used twice, expired link. Variant 2 (security): successful cases — link valid for 15 minutes, after password change the old link does not work; failed cases — attempt to use a link after expiration, token picking; boundary cases — simultaneous password change from two devices, newly generated link. Variant 3 (usability): successful cases — clear success messages, ability to request a letter again; failed cases — absence of feedback on error, unreadable letter text; boundary cases — email with spaces at the beginning and end, different browsers.
After comparison we chose Variant 3 as a basis, supplementing with checks from Variant 2 on security and from Variant 1 on functionality. The final plan included 18 checks. This is a fictional scenario for illustration; in real work take into account the specifics of your project.
Fragment of the final plan: 1. Success: entering a correct email, receiving a letter, following a link, changing a password. 2. Failure: entering an email without an @ symbol, form submission, waiting for an error message. 3. Boundary: a link used 16 minutes after receipt must be invalid.
How to Check the Result and Account for Limitations
Checking starts with analyzing the structure: are there sections for successful, failed, and boundary cases? Then check each point for specificity: what is being tested, what steps, what expected result. Vague formulations are clarified. Make sure the plan covers main functions and possible exceptions, not just obvious scenarios.
Tool limitations: it does not test your code, does not have access to the database, and does not know business logic. The model may miss important checks or suggest irrelevant ones. The result can be copied or downloaded as TXT; DOCX or PDF export, auto-save and integrations are not supported. The tool works only with text and does not create images, audio, or video.
Practical technique: turn general points into verifiable ones. Instead of 'check link validity' write 'generate a link, wait 15 minutes, follow the link, ensure an expiration message is displayed'. Add checks for 14 minutes 59 seconds and 15 minutes 1 second — this makes the boundary measurable.
Refinement of a point: was 'Check that the link works for 15 minutes'. Became: 'Generate a link, wait 15 minutes, follow the link, ensure an expiration message is displayed. Repeat for 14 minutes 59 seconds and 15 minutes 1 second'.
The Test Plan tool helps quickly get a draft of checks with successful, failed, and boundary cases. By changing the query emphasis — functionality, security, usability — you get different sets of checks that can be compared and combined. The practical example with a password reset form showed how it works: three drafts gave different boundary cases, and the final plan was collected manually. Remember the limitations: the tool does not guarantee completeness, may make mistakes and does not take into account the specifics of your project. Check the result, clarify formulations and adapt the plan to your needs. Use generated variants as a basis, but do not rely on them blindly.
Open tool: Test plan builder ↗Interface translations are machine-assisted and may need refinement.