Mini-Test Format

Every mini-test must strictly follow this structure.

Template

ID: {original_id}-MT{N} Title: {short title — what exactly is being tested} Description: {what this mini-test verifies, 1–3 sentences} Priority: {High / Medium / Low} Preconditions:

{system state required before execution}
{or "None" if no preconditions}

Steps:

#	Action	Expected Result
1	{user or system action}	{expected behavior}
2	{action}	{expected result}

Final Expected Result: {overall outcome after all steps of this mini-test complete}

Link to Original Test Case:

Original test case: {original_id} — {original_title}
Original steps covered: {e.g. 1–3, 5}
Check type: functional | boundary | negative | scenario

Field Rules

ID

Format: {ORIGINAL_ID}-MT{N}, where N is a sequential number starting from 1. Examples: TC-1234-MT1, TC-1234-MT2.

Title

Must answer: "What is being tested?"
Format: verb + object. Example: "Login with valid credentials"

Description

1–3 sentences about the goal of this mini-test
Do not repeat steps — describe the essence of the check

Preconditions

List the system, user, and data state required before execution
Include setup steps from the original that are not part of the verification logic

Steps

Each step = one atomic action
Action: specific ("Click the 'Login' button"), not abstract ("Log in")
Expected result: measurable ("A 'Welcome' message is displayed")

Check Type

functional — verification of core functionality
boundary — boundary/edge values
negative — invalid input or error scenarios
scenario — end-to-end user journey

Autotest Readiness Markers

✅ Ready — all steps are atomic, expected results are unambiguous and measurable
⚠️ Needs clarification — vague wording or dependency on external/dynamic data

1.9 KiB Raw Blame History Unescape Escape