# 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