Test Plan: How to Create a Test Plan with Successful, Failed, and Boundary Cases
The Test Plan tool helps you quickly create a structured test plan. You describe an idea or functionality, specify the platform or application, choose the output language, and press Generate. A single result appears in a separate panel -- a list of test cases including successful, failed, and boundary scenarios. The result can be copied or downloaded as a plain text TXT file. The tool does not execute tests, does not analyze code, and does not guarantee the absence of errors. It merely offers possible checks based on your description. The generated plan is a draft that needs adaptation and enhancement. All examples in the article are fictional and provided to demonstrate working with the tool.
Open tool: Test plan builder ↗How to Describe Functionality to Get a Useful Plan
The more specific the description, the more precise the test cases will be. Instead of "login form," write: "Login form with email and password fields, login button, password recovery link. Password from 8 to 32 characters, email must contain the @ symbol." Specify constraints, states, and transitions between screens.
In the "Platform or application" field, specify the environment if it is important: "Web application (browser)", "Android mobile app" or "Website (desktop and mobile version)." This helps the tool take platform specifics into account.
Select the output language before generation. The tool supports different languages, but quality may vary, so check the result. The first field accepts up to 8000 characters, the details field up to 1000 characters.
Request: "Login form with email and password fields, login button, password recovery link. Password from 8 to 32 characters, email must contain the @ symbol." Platform: "Web application (browser)".
Example: Password Reset Form
Describe the process: "Password reset form: user enters email, a one-time link for password reset is sent to it. The link is valid for 24 hours. After following the link, the user enters a new password and confirmation." Specify the platform, for example "Web application (browser)."
The tool may propose successful scenarios (correct email, link transition, matching passwords), failed (invalid email, expired link, mismatched passwords) and boundary (email of maximum length, link used twice, password at the boundary of acceptable length).
Check that all important aspects are covered. For example, the tool may not include a check for reusing a link after a successful reset. Supplement the plan manually.
Request: "Password reset form: user enters email, a one-time link for password reset is sent to it. The link is valid for 24 hours. After following the link, the user enters a new password and confirmation." Platform: "Web application (browser)." Possible result: list of test cases including successful reset, invalid email, expired link, mismatched passwords, minimum and maximum password length.
Example: Shopping Cart
Enter description: "Shopping cart of an online store: user adds items, changes quantity, removes items, applies promo code, places order. Items may be in stock or out of stock. Promo code gives 10% discount when order total is 1000 rubles." Platform: "Website (desktop and mobile version)."
The tool may generate tests for successful addition of an item, changing quantity, removal, applying promo code when total is above the threshold, and placing an order. Failed: applying promo code when total is below the threshold, adding an out-of-stock item, placing an order with an empty cart. Boundary: order total exactly 1000 rubles, maximum item quantity, minimum quantity (1), removing the last item.
Pay attention to possible omissions: for example, the tool may not account for a promo code expiration scenario. Add such cases manually. Also check that tests cover different platforms if you specified multiple.
Request: "Shopping cart of an online store: user adds items, changes quantity, removes items, applies promo code, places order. Items may be in stock or out of stock. Promo code gives 10% discount when order total is 1000 rubles." Platform: "Website (desktop and mobile version)." Possible result: tests for addition, change, removal, promo code application, order placement, as well as boundary cases with total 1000 rubles and missing item.
Example: File Upload
Enter: "File upload: user selects a file, presses upload button. Supported formats: PDF, DOCX, JPG. Maximum file size 10 MB. After upload, the file appears in the list." Platform: "Web application."
The tool may propose tests for successful upload of a valid format and size file, display in the list. Failed: upload of unsupported format, size exceeding limit, upload interruption. Boundary: file exactly 10 MB, 0-byte file, file with maximum length name, uploading multiple files simultaneously.
Check if the plan includes virus checks or other security checks. If not, add them. Also ensure tests cover different browsers if important for your project.
Request: "File upload: user selects a file, presses upload button. Supported formats: PDF, DOCX, JPG. Maximum file size 10 MB. After upload, the file appears in the list." Platform: "Web application." Possible result: tests for successful upload, unsupported format, size exceeding limit, boundary cases with 10 MB and 0 bytes.
How to Check and Enhance the Generated Plan
Read each test case carefully. Make sure it corresponds to your functionality. The tool may interpret the description ambiguously, so check that there are no tests unrelated to the task.
Compare the plan with your requirements. If specific constraints were indicated in the description (for example, link validity 24 hours), make sure boundary tests include checking for 24 hours and slightly more or less.
Supplement the plan with missing cases. For example, if you are testing a form, add checks for entering special characters, spaces, very long strings. The tool may not consider all nuances, so your expertise is important.
After generation, review the test cases for a login form. Add tests for entering Unicode characters, pasting from clipboard, pasting into password field with masking enabled.
Tool Limitations
The tool does not execute tests and does not guarantee that your product will work without errors. It merely offers possible checks based on your description. The result may contain errors or omissions.
The tool does not analyze code and does not have access to your application. It works only with textual description, so the more detailed and accurate you describe the functionality, the more useful the plan will be.
There is no automatic integration with test management systems. You can copy the result or download it in TXT format. The tool does not support DOCX or PDF export, does not perform batch processing, and does not save history.
A generated plan for a cart may list tests but cannot connect to your actual cart system to run them; you must manually adapt and run them.
Tips for Crafting Prompts
Be specific. Instead of "login form," write "login form with email and password fields, login button, password recovery link." Specify constraints: minimum password length, email requirements.
Specify the platform if it is important. For example, "Android mobile application" or "desktop website." This helps the tool consider platform specifics.
If you want tests in multiple languages, select the output language. The tool supports different languages, but quality may vary. Check the result.
To get tests for a cart in English and Russian, first generate in English, then change the language setting and generate again, comparing the outputs.
The Test Plan tool is an assistant that saves time at the initial stage of test planning. The three provided scenarios show how it can quickly generate a draft of test cases for different types of functionality. However, remember: the generated plan requires checking and enhancement. Do not rely on it blindly. Use it as a starting point, supplement with your knowledge, and do not forget about manual testing. All examples are fictional and provided to demonstrate the tool's capabilities.
Open tool: Test plan builder ↗Interface translations are machine-assisted and may need refinement.