fix
This commit is contained in:
@@ -0,0 +1,64 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user