A middle-of-range example cannot demonstrate correct boundary behavior
The boundary should be agreed before the team chooses test files. Otherwise two implementations can reject different sizes while both claim to satisfy ten megabytes. The review needs the numeric unit, whether the limit includes metadata, and whether equality is allowed. It should also specify what the user sees when the limit is exceeded. The test set should use controlled sizes rather than approximate filenames such as large-file.pdf. A useful negative case checks that a rejected upload does not leave a misleading completed record. Another can test several attachments if the source distinguishes per-file and total limits. Those additions should follow actual scope rather than expand it automatically. Recording the boundary interpretation with the criterion lets future reviewers understand why an exactly-at-limit file passed or failed without reverse-engineering the implementation's arithmetic.
Working through the example
A specification allows attachments up to ten megabytes. A test uploads a small file and declares the requirement complete without checking the threshold. Define the unit and inclusive boundary, then test just below, exactly at, and above it. Preserve the accepted interpretation of the limit.
A discriminating check
Compare the expected response for all three boundary files under the same environment. Megabyte conventions can differ, so the source or owner must settle the numeric definition before testing. Trace-link research motivates connecting requirements with relevant checks. The project plan separately requires a criterion, an execution result, and applicability to the approved revision being assessed.