Test plan: how to create a test plan with successful, failure, and boundary cases
The 'Test plan' tool generates a textual test plan based on your description: you specify a function and platform, and receive a list of checks including success cases, failure cases, and boundary conditions. This is convenient for quickly drafting a plan and for training: you learn to formulate requirements, notice missing scenarios, and critically evaluate the resulting list. Below are practical techniques for working with the tool, analysis of typical errors, and exercises that help develop testing planning skills.
Open tool: Test plan builder ↗What the tool actually generates
'Test plan' is a text generator, not a test execution environment. It does not run code, does not connect to your system, and does not check the actual behavior of the program. Its result is a structured description of checks, which you then analyze and, if necessary, supplement manually.
Input is provided in two fields: 'Your text or idea' and 'Platform or application'. The first field accepts up to 8000 characters, the second up to 1000. This is enough to describe a function, its input parameters, expected behavior, and key constraints. The more specific the description, the more useful the draft.
The result is output in a separate panel as plain text. It can be copied or downloaded in TXT format. There are no other export methods, so plan your work accordingly: save the necessary fragments immediately or transfer them to your working document manually.
Example description: 'Password reset form: email field, Send button. After sending, the email with a link is valid for 24 hours'. Platform: 'Web application'.
How to describe a function to get a useful plan
Start by assigning the function: what it does and why it is needed. Then list the input data and their valid values. After that, describe the expected behavior with correct and incorrect data. Such a structure helps the tool more accurately determine check classes.
Specify the platform consciously. For a web application, important checks include forms, sessions, and navigation; for an API - response codes, data formats, and error handling; for a mobile application - behavior on interruption, notification handling, and gestures. The same function on different platforms requires different checks.
Do not overload the description with secondary details, but do not omit constraints that affect checks: maximum field length, allowed characters, link validity period, attempt limit. If a constraint is not specified, the tool may not account for it, and you may receive an incomplete list.
Supplement the description: 'Email must contain @ and a dot, length up to 254 characters, resend not more than once per minute'. Such text provides more material for boundary cases.
Success cases, failure cases, and boundary conditions
Success cases describe standard behavior: correct data, expected result, no errors. There are usually few of them, and they serve as a base for checking main functionality. Make sure there is at least one such case for each use scenario.
Failure cases check the system's response to incorrect data or impermissible actions: empty field, wrong format, lack of permissions, exceeding the limit. A good plan contains not only the fact of an error, but also the expected message or response code.
Boundary conditions are at the intersection of permissible and impermissible: minimum and maximum length, first and last permissible value, empty string, value one unit above the limit. This is precisely where defects are most often discovered, so boundary cases deserve special attention.
For an email field, boundary cases will be: address of minimum permissible length, address 254 characters long, address 255 characters long, address without @ symbol, address with a leading space.
How to analyze the generated plan
First, read the plan in its entirety and mark points that correspond to your description. Then check if there are cases contradicting the described logic: the tool may propose a check that makes no sense for your function. Such points should be discarded or reformulated.
Compare the generated list with your own, pre-generated list. Discrepancies are useful in both directions: they show which scenarios you missed and which redundant ones the tool added. Analyze each discrepancy and decide what really needs to be checked.
Pay attention to formulations. A useful item contains a condition, action, and expected result. If the output has general phrases without specificity, clarify the input data and regenerate the plan - often this gives a more accurate result.
The item 'Check email' is too general. Better: 'Enter an address without @ and click Send - expect a format error message, email is not sent'.
Exercise for training the skill
Choose a small function and describe it manually. Create your own list of checks: success cases, failure cases, and boundary conditions. Then generate a plan using the tool and compare both lists. Mark matches, omissions, and extra items.
For each discrepancy, determine the cause. If the tool suggested a case you didn't consider, verify if it is really important for your function. If it missed an obvious check, your description was probably insufficient - supplement it and regenerate the plan again.
Repeat the exercise with different functions: registration, authentication, search, filtering, order placement. Gradually you will learn to faster identify equivalence classes and boundary values, and the tool's draft will become only a starting point for your own analysis.
Take the 'search by catalog' function. Describe it, create your plan, then compare with the tool's plan and add missing checks: empty query, query from one character, query with special characters, very long query.
Limitations and typical errors
The tool does not replace a tester and does not know the details of your system. If the description lacks information about internal constraints, security requirements, or business logic features, these aspects may not end up in the plan. Responsibility for completeness of checks remains with you.
The model may make mistakes: propose irrelevant cases, duplicate items, or use imprecise formulations. The result should always be checked manually and correlated with the real system behavior. Do not make critical decisions based solely on generated text.
The tool has no integrations, automatic saving, or export to office formats. Only TXT export is available. Take this into account when planning: if you need a document in another format, transfer the text manually. Also remember that queue and service availability may change.
If you do not specify that a password reset link is one-time use, the plan may not include a check for reusing the link.
How to integrate working with the tool into regular practice
Allocate short regular sessions: choose a function, describe it, generate a plan, analyze the result, and record conclusions. Keep an exercise journal - so you will see what types of checks come easily to you and which you systematically omit.
Discuss results with colleagues or groupmates. Sharing plans for the same function helps notice blind spots and compare approaches to decomposing requirements. Collective review typically uncovers more discrepancies than individual work.
Remember that the tool's value lies in supporting the planning and learning stage. It helps faster obtain a draft and see possible check directions, but does not execute tests and does not guarantee completeness. Use it as an auxiliary means, not a replacement for real testing.
Group exercise: each participant describes the same function and creates a plan, then the team compares results and selects the most comprehensive set of checks.
'Test plan' helps quickly obtain a test planning draft with checks for success, failure, and boundary conditions. It brings the most benefit when you do not simply copy the result, but analyze it: compare it with your list, refine the function description, and add missing cases. Consider limitations: the tool does not run tests, has no integrations, and has no automatic saving; the result is available only as text with TXT export. The model can make mistakes, so check the output manually. With regular practice, the tool becomes a convenient trainer for developing testing planning skills.
Open tool: Test plan builder ↗Interface translations are machine-assisted and may need refinement.