Use it as a planning assistant. The output is a proposed test selection; application results only exist after someone executes the checks against a named build.
Follow the changed behavior beyond its first caller
This original fictional application has a shared name normalizer. It currently removes spaces at both ends of a string. A proposed revision also collapses repeated internal spaces. The profile display calls it to tidy visible names. A CSV import calls the same function before matching a supplied name to an existing record.
For the input shown below, the proposed normalizer collapses two internal spaces to one.
Input: "Ada Li"
Output: "Ada Li"
That is a visible formatting change in the profile. In the import, it may change which key is compared with stored data. Whether that merge is correct depends on the import's matching rule, which the change description has not supplied.
The American Software Testing Qualifications Board's maintenance-testing guidance, checked October 24, 2026, connects change impact with identifying other affected areas. A dependency map helps make that reasoning inspectable; it does not prove that the map is complete.
Select a check for a reason
| Proposed check | Why it belongs | What is still needed |
|---|---|---|
| Unit examples for leading, trailing and repeated internal spaces | Directly exercises the changed normalizer | Agreed treatment of tabs and nonbreaking spaces |
| Profile name display | Direct caller should show the agreed display value | Approved display expectation |
| CSV matching with two records that differ only in internal spacing | Indirect workflow may collapse distinct keys | Owner's decision on identity and collision behavior |
| An unrelated report export | No dependency supplied in this exercise | Confirm whether it calls the same function before excluding it |
Do not mark the import check Passed while its expected behavior is unresolved. Keep it as a specification question. If the normalizer must have different semantics for display and identity, that is a design discussion rather than a reason to guess the desired test output.
The requirements-to-test-cases guide shows how to create concrete cases once those rules are agreed. Here, decide which behavior needs that work and why.
Ask for an impact-based test proposal
Help select regression checks for this change.
Change description and exact diff: [PASTE PERMITTED MATERIAL]
Old behavior and intended new behavior: [PASTE]
Known callers, shared data and integrations: [PASTE]
Existing tests with IDs and what they assert: [PASTE]
Recent relevant failures and important user workflows: [PASTE]
Build/environment and available execution time: [ENTER]
Trace direct and indirect effects using only supplied dependencies.
For each proposed test, name the affected behavior, existing test ID
if available, reason for inclusion and required starting data.
Separate missing expectations from executable tests. Show exclusions
with reasons and dependencies that need a maintainer's confirmation.
Do not invent callers, mark tests passed, claim complete coverage,
approve a release, run commands or modify code.
OpenAI's prompting documentation supports supplying the task, relevant context and output boundaries. Give the model the dependency evidence; asking it to imagine a whole application produces assumptions you must then untangle.
Record what you ran and what remains uncertain
Have the maintainer confirm the normalizer's callers and settle the import identity rule. Then execute the accepted checks with separate fixtures. Record the build, actual result and evidence against each selected test.
If time prevents a relevant check, retain it as Not run with the reason. Passing the display check cannot stand in for the import workflow. Keep the untested risk visible when the team makes its release decision.