Test plan: how to compose 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 a password reset form example 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.
Ouvrir l'outil: Constructeur de plan de test ↗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. For example: 'Password reset form: user enters email, system checks its presence, sends email with one-time link, link 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, not 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 presence, sends email with one-time link, link 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 existing email, receiving email, following the link, setting new password. Failed cases check error handling: non-existent email, empty field, wrong format, reusing the link. Boundary cases explore limit values: minimum and maximum email length, link validity 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, which you then adapt to your environment. For example, for checking link validity time 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 to understand: 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: reusing the 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, network error handling. If any item is missing, add it manually or refine the input data and regenerate the plan.
Accuracy is checked against matching your description. If the text says the link is valid for 15 minutes and the plan says 10 minutes — that's 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 get. Do not expect the tool to guess non-obvious conditions, e.g. limiting the number of requests from one IP. Such cases are better added manually.
Check: in the plan there is a case 'User enters email with a leading space'. If your description did not specify how spaces are handled, this case may be excessive or, on the contrary, useful. Decide whether it matches your requirements.
How to use 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, check each case in a browser. For checking link validity time you can change system time or use developer tools. Remember the tool does not run tests for you — it only suggests a plan.
The result can be passed to a testing team or used for writing test cases in a test management system. Remember the plan does not account for your architecture specifics, so adapt it to your needs.
Downloaded TXT file contains list: '1. Successful reset: entering existing email, following link, setting new password. 2. Failure: entering non-existent email. 3. Boundary: link used exactly after 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 system behavior. It does not guarantee that all cases will be correct or complete. The model may make mistakes, and queue and availability may vary. Do not use the generated plan as the sole source of truth.
The tool does not support DOCX or PDF export, does not perform batch processing, does not automatically save results and does not integrate with other systems. Maximum input text length — 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. Shorten the text, leaving only key rules.
How to improve test plan quality
To get a more accurate plan, add specific values to the input data: link validity time, 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 valid for some time' write 'link valid for 15 minutes'. Then the plan will have 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 based on accuracy matching your description and completeness of key scenarios coverage. Remember the limitations: the tool does not execute tests and does not guarantee error-free operation. Use it as a draft, supplementing and adapting to your needs. The example is fictional and provided only for illustration.
Ouvrir l'outil: Constructeur de plan de test ↗Les traductions de l'interface sont assistées par machine et peuvent nécessiter des améliorations.