Test Plan: How to Create Checks for a Password Reset Form
The Test Plan tool transforms a textual description of a function into a structured set of checks: successful scenarios, failed and boundary conditions. In this article we will prepare input data using the example of a password reset form that sends a one-time link to email, and how to evaluate the quality of the generated plan. The example is fictional and provided only for illustration.
Open tool: Test plan builder ↗What is Input and How to Formulate the Task
The tool accepts two text fields: "Your text or idea" (up to 8000 characters) and "Platform or application" (up to 1000 characters). In the first field describe the function, its behavior and expected results. The more specific the description, the more accurate the cases will be. For example: "Password reset form: user enters email, system checks its existence, sends email with one-time link, link is valid for 15 minutes and can be used only once." In the second field specify the platform: "Web application, desktop browser".
Avoid generic phrases like "create a test plan for password reset". Instead list key elements: input fields, buttons, validation conditions, time limits, number of attempts. This helps the tool generate meaningful checks rather than templates.
Check that the description does not exceed the character limit. If the text is long, trim secondary details but keep all business rules. Remember: the tool does not analyze code and does not connect to a database — it works only with your textual description.
Field 1: "Password reset form: user enters email, system checks its existence, sends email with one-time link, link is valid for 15 minutes and can be used only once. After password reset all active sessions are terminated." Field 2: "Web application, desktop browser".
How the Tool Builds Successful, Failed and Boundary Cases
Based on your description the tool identifies three groups of checks. Successful cases describe correct behavior: entering an existing email, receiving the email, clicking the link, setting a new password. Failed cases check error handling: non-existent email, empty field, wrong format, repeated use of the link. Boundary cases explore edge values: minimum and maximum email length, link lifetime exactly 15 minutes, entering email with leading or trailing spaces.
The tool does not generate code and does not run tests. It creates a textual plan that you then adapt to your environment. For example, for checking link lifetime a case may be proposed "link used after 14 minutes 59 seconds" and "after 15 minutes 1 second". This helps identify errors at the boundaries.
Important: the tool does not know the specifics of your infrastructure, so some cases may be inapplicable. Your task is to filter out the unnecessary and supplement the plan with missing checks if necessary.
Generated fragment: "Boundary case: email length of 254 characters (maximum allowed length per RFC 5321). Expectation: system accepts email and sends email." "Failed case: repeated use of link after successful password reset. Expectation: system shows error message and does not allow password change".
Checking Accuracy and Completeness of the Result
After generation evaluate whether all key aspects of the function are covered. For a password reset form check for cases: email validation, email sending, link expiry, single-use, session termination, error handling. If any item is missing add it manually or refine the input data and regenerate the plan.
Accuracy is checked against correspondence to your description. If the text says the link is valid for 15 minutes and the plan says 10 minutes — that is an error. The tool may make mistakes, so always verify generated cases against the original requirements.
Completeness also depends on the detail of the input data. The more rules you describe the more checks you will get. Do not expect the tool to guess non-obvious conditions, such as limiting the number of requests from one IP. Such cases are better added manually.
Verification: the plan has a case "User enters email with a leading space". If your description did not specify how spaces are handled this case may be redundant or, conversely, useful. Decide whether it conforms to your requirements.
Using the Result in Real Testing
The generated test plan can be copied or downloaded in TXT format. Use it as a checklist for manual testing or as a basis for automation. Divide cases by priority: first successful, then failed, then boundary. For each case specify expected and actual result.
If you are testing a web application verify each case in a browser. For checking link lifetime you can change system time or use developer tools. Remember the tool does not run tests for you — it only offers a plan.
The result can be passed to a testing team or used for writing test cases in a test management system. Do not forget that the plan does not account for architecture specifics, so adapt it to your needs.
Downloaded TXT file contains a list: "1. Successful reset: entering existing email, clicking link, setting new password. 2. Failure: entering non-existent email. 3. Boundary: link used exactly at 15 minutes." You add steps and expected results.
Tool Limitations and Typical Errors
The tool does not analyze code, does not connect to a database and does not check the real behavior of the system. It does not guarantee that all cases will be correct or complete. The model may make errors and queue and availability may vary. Do not use the generated plan as the sole source of truth.
The tool does not support export to DOCX or PDF, does not perform batch processing, does not automatically save results and does not integrate with other systems. Maximum input text length is 8000 characters, second field — 1000 characters. Exceeding the limit will cause an error.
Do not try to use the tool for generating images, audio or video. It works only with text. Also do not expect it to account for all nuances of your domain — it is only a helper for drafting a test plan.
If you enter a description longer than 8000 characters the tool will return an error. Trim the text leaving only key rules.
How to Improve the Test Plan Quality
To obtain a more accurate plan add specific values to the input data: link lifetime, maximum number of attempts, email format. Avoid ambiguous formulations. If the function has several modes describe each separately.
After generation check for duplicate or conflicting cases. Remove those that are not relevant to your task. If necessary regenerate the plan with refined description.
Use the plan as a starting point for discussion with the team. Colleagues may notice missing scenarios. Joint work increases coverage completeness.
Instead of "link is valid for some time" write "link is valid for 15 minutes". Then the plan will contain boundary cases at 14:59 and 15:01.
The Test Plan tool helps quickly create a structured set of checks for a password reset form. Evaluate the result by accuracy of correspondence to your description and completeness of key scenarios coverage. Remember the limitations: the tool does not run tests and does not guarantee error-free output. Use it as a draft, supplementing and adapting to your needs. The example is fictional and provided for illustration.
Open tool: Test plan builder ↗Interface translations are machine-assisted and may need refinement.