Designing Acceptance Tests with Copilot Chat: Separating Boundary Values from Undefined Specifications

About This Article
This article was created using an automated generation workflow leveraging generative AI. Official Microsoft documentation was reviewed on November 3, 2026, and the procedure for designing acceptance tests from a fictional reservation specification was organized. Copilot execution results have not been verified.

Verification Status: 📘 Official Information Verified, Prompt Execution Unverified

Try It First in 3 Steps

1. Open the organization-approved Copilot Chat and paste the prompt provided under "Creating a Test Table from a Small Fictional Specification" below.

2. Check whether the generated table correctly distinguishes the headcount boundary values "0, 1, 10, 11" from the "undefined" status of S4.

3. Change the upper limit of S1 to "12 people" and try it in a new conversation, then compare how 12 and 13 people are handled.

What to Look for After Operation:We expect 0 and 11 people to be categorized as out-of-bounds, 1 and 10 people as within bounds, and duplicate reservation S4 to be organized as undefined. Actual Copilot outputs are unverified, and AI-generated expected results must not be used as pass records for executed tests.

Supported Environments, Capabilities, and Limitations (Official Verification: November 3, 2026)

When creating test items from specification notes, relying solely on valid inputs makes it difficult to detect defects. Conversely, if you define unwritten behaviors as expected results, the testing process ends up creating new specifications. We will ask Copilot Chat to separately output verifiable expected results and cases where specification clarification is required.

Creating a test matrix from a small fictitious specification

The target is a fictitious equipment reservation form. No actual screens are accessed, and no code is executed. What we are creating here is a draft for test design. We arrange input values and expected results in a format that allows humans to verify consistency with the specifications.

次の架空仕様だけから、受入テストの候補を作ってください。
列：ID／観点／入力／期待結果／根拠仕様／仕様確認が必要な点。
正常系、境界値、異常系を含めてください。
期待結果が仕様にない場合は「未定義」とし、動作を創作しないでください。
自動テストコードや実行済み結果は出さないでください。

S1：予約人数は整数で、1人以上10人以下。
S2：予約名は必須で、30文字以内。
S3：受付完了後、予約番号を画面表示する。
S4：同じ時間帯で重複予約できるかは未決定。

One person and ten people represent the boundaries of the permitted range. Zero people and eleven people are out of range. For the reservation name, 30 characters and 31 characters serve as comparison candidates. However, whether inputs consisting only of spaces should be treated as a violation of required fields, or how many characters an emoji counts as, cannot be determined from this note alone.

Boundary values are not limited to the upper limit

Boundary value analysis is an approach that compares the edges of the permitted range with the values just outside them. For the number of people, we check not only 1 and 10, but also 0 and 11. Even if the AI generates many examples of "the usual 5 people," that does not mean the boundary perspectives have been covered.

This table does not define error message wording or display positioning, as they are not specified. If the AI introduces UI behaviors such as disabling the save button or displaying an error message in red, these are reverted to verification candidates rather than treated as implementation facts.

Isolate the cause by changing conditions one by one

Making both the headcount and name invalid at the same time makes it difficult to determine which condition caused the failure. First, keep the name at a valid value and change only the headcount. Next, keep the headcount at a valid value and change only the name length. This approach makes the results easier to interpret rather than simply increasing the number of test cases.

It is not always necessary to test all combinations. While combination testing is required when conditions are interdependent, independent inputs can often be tested starting from individual boundary values. Humans determine the scope of testing based on the target risks and specifications.

Break down the expectation of successful registration into smaller details. Acceptance of the request, display of the reservation number, and the ability to reference the reservation later are distinct items. S3 specifies UI display only; email notifications and reflection in lists are not documented.

Do not finalize undefined specifications through testing

Duplicate reservations in S4 are undecided. Even if the AI writes "error in case of duplication," that expected result is not included in the approved tests. The expected behavior is defined only after clarifying the unit of duplication, exceptions, and user instructions.

Placing undefined items in a separate column highlights the questions that need to be answered during the design review. This memo also does not clarify whether "the same time slot" means matching start times or overlapping reservation periods. Replacing ambiguous terms with concrete input examples makes decision-making easier.

Length specifications are similar. The boundary may vary depending on whether 30 characters are counted by visual appearance on the screen, character encoding units, or storage constraints. Here, basic boundaries are verified by repeating "A", and complex character handling is left as a separate verification item.

Modify one line and investigate cases that need to be added

Change only the upper limit of S1 from ten to twelve, and generate a test table using a new conversation. The expected change is that boundary cases will appear, allowing twelve and treating thirteen as out of range. If ten remains invalid, it indicates that old conditions are still being carried over.

Here, rather than recreating test items from scratch, have the AI explain the impact of the changes. Outputting which IDs to modify, add, or delete allows you to verify correspondence with existing cases. However, the IDs assigned by the AI are not automatically reflected in the actual test management ledger.

There is no reason why changing the upper limit should also alter the reservation name length or reservation number display conditions. Checking whether unrelated expected results have been rewritten is also included in the revision review. Keeping the scope of diffs small makes the review scope clear.

Checking for Omissions and Duplications Based on Alignment with Specifications

Once the test table is created, group the corresponding cases for each specification number. S1 contains multiple person count boundaries, and S3 requires confirmation of the display after reception is complete. Even if there are many rows, if no items correspond to S3, that specification will not be verified. Having the AI generate a correspondence list by number narrows down the review scope.

Duplications are not determined solely by identical input values. Even with the same input of ten people, the case verifying the reservation number display and the case verifying the upper limit of people serve different purposes. While they can sometimes be combined and verified in a single operation, both perspectives must remain in the expected results column.

For invalid inputs, distinguish between the input being rejected and existing data remaining unchanged. Whether to include the latter in the test is determined by reviewing the persistence logic specifications and their impact. Items proposed by the AI as safety measures are managed separately from expected results based on approved specifications.

Case priorities should not be determined solely by automated scoring. The impact of making a reservation with an incorrect number of people differs in weight from a difference in message notation. Humans review business impact, likelihood of occurrence, and the relationship with modified sections to decide which areas to test first within limited time.

If a specification deficiency is found during execution, do not rewrite the expected results on the spot to pass the test. Record the questions and answers, and update both the specifications and the test table to reflect the same agreed-upon content. Before continuing testing, also check whether the changes affect other cases.

Separating Test Design and Execution Records

At the stage where the table is created, the tests have not been executed. Pass/fail judgments can only be made after recording the execution date, target version, operating environment, actual results, and evidence. Ensure that AI outputs stating "pass" are not treated directly as execution records.

When testing actual inputs, use a validation environment and dummy reservation names. This text does not imply that tests involving registering large amounts of data in the production business screen or monopolizing reservations should be performed immediately. First, check the usage rules and cleanup procedures for the target environment.

Pay attention to the input of specification documents as well. If unreleased screens, internal rules, or transaction information are involved, handle them within the scope permitted by the organization. A practical workflow is to test the table format using fictitious specifications and then confirm the input destinations and sharing recipients when providing actual information.

What is being evaluated is not the number of items. Check whether at least one verification corresponds to each specification, whether there are inner and outer boundaries, and whether undefined items have crept into the passing conditions. After increasing the candidates, humans organize duplications and priorities.

Acceptance tests are intended to verify whether the implementation satisfies the specifications. While Copilot plays a role in broadening the range of candidates, expected results are tied to agreed-upon specifications. If undefined items can be left as undefined, the test table can be used for both execution preparation and specification verification.

Official Information and Primary Sources

• Official Overview of Copilot Chat

• Prompt Objective, Background, Reference Information, and Expected Output

• Official Guide for Specifying Prompts

• Privacy and Protection in Copilot Chat

The product scope and input methods refer to the official documentation. The fictitious data, prompts, expected examples, and checklists are verification plans for this article and are not output examples guaranteed by Microsoft.