014 – Live Project (Part 7) – Test Cases Template - rkb-sdet/SoftwareTesting GitHub Wiki
- Previous steps completed:
- Project Start & Application Exploration
- Test Plan creation
- Test Scenarios creation
- Focus in this session: Understanding and using the Test Cases Template before actual test case authoring.
- Ensures uniformity and consistency for all test cases created in the project.
- Defines key columns and data required for full coverage and traceability.
- Facilitates review, feedback, and versioning.
(Source: attached Excel; explained in class)
| Column Name | Description | Example / Notes |
|---|---|---|
| Test Case ID | Unique identifier for each test case (e.g., TC_001) | TC_001, TC_002, etc. |
| Test Scenario | Reference to the related scenario (e.g., TS_001 for Register Account) | Use scenario IDs from scenario document |
| Requirement ID | Reference to the business/requirements document (if available; else "Not Applicable") | Not used for this project (can delete for simplicity) |
| Test Case Title | Short, descriptive summary of what is tested | "Register account using mandatory fields only" |
| Pre-requisites | Setup steps to be done before executing the test | "Open app URL in browser" |
| Test Steps | Detailed, step-by-step actions for the test | "Click My Account", "Click Register", "Fill mandatory fields" |
| Test Data | Data required for inputs, user details, etc. | New user data for registration |
| Expected Result | What should happen if the test works correctly | "User account created, navigated to success page" |
| Actual Result | What happened in practice (filled after execution) | Recorded during execution |
| Priority | Criticality or testing order (High/Medium/Low or P0-P4) | Leave blank until full coverage; prioritize after authoring |
| Result | Status after execution (Pass/Fail/Blocked/Not Run) | "Pass" if Expected = Actual |
| Client Feedback | Reviewer/client suggestions/comments | Filled during review |
- Track who prepared the document, for which project, and the version number.
- Document reason for updates with comments (e.g., “Version 2.0 – added cases after client feedback”).
| Project Name | Prepared By | Version No. | Comments |
|---|---|---|---|
| TutorialsNinja Web Application | Solaytic (Arun Motoori) | 1.0 | Initial version |
| TutorialsNinja Web Application | Solaytic (Arun Motoori) | 2.0 | Client feedback incorporated |
| TutorialsNinja Web Application | Solaytic (Arun Motoori) | 3.0 | Added Netbanking feature test cases |
- Test Case ID: Use sequential, unique identifiers. For scenario TS_001, use TC_001, TC_002, etc.
- Test Scenario: Always cross-reference to enable coverage traceability.
- Requirement ID: Remove or leave blank if no requirements doc provided.
- Test Case Title: Write clear, concise titles for the test objective.
- Pre-requisites: List all conditions needed before test (e.g., app URL open, admin login).
- Test Steps: Detail each step as a new line; describe necessary UI actions thoroughly.
- Test Data: Provide sample or required data only if needed (e.g., email, name).
- Expected Result: Clearly state the outcome for each step or for the full test.
- Actual Result: Fill in during testing; use this for reporting defects.
- Priority: Assign after bulk authoring—P0 for must-have, P4 for optional.
- Result: Pass if Actual = Expected, otherwise Fail/Blocked/etc.
- Client Feedback: Use for review cycles, update test cases per feedback.
| Test Case ID | Test Scenario | Test Case Title | Pre-requisites | Test Steps | Test Data | Expected Result |
|---|---|---|---|---|---|---|
| TC_001 | TS_001 | Register with mandatory fields only | Browser open at app URL | 1. Click My Account menu 2. Click Register 3. Enter mandatory fields 4. Select Privacy Policy 5. Click Continue |
New user details | Account created, success page shown |
- Use multiline cells for steps; wrap and format for clarity.
- After writing test cases, send the document to the client for review.
- Use the Client Feedback column and Version History tab to track all suggested changes and new features (e.g., Netbanking).
- Maintain version increment (e.g., v1.0 → v2.0 after feedback, v3.0 after new features).
- Understand how to fill each column of your test case template for maximum clarity and traceability.
- Use the template for all functionalities, referencing the scenarios from your scenario document.
- Version your document and record client feedback for every major update.
- Full test coverage, clear documentation, and traceable review history are core to professional QA.
If you need a filled test case template example (Excel format) for interviews or real projects, let me know and I can create one based on session guidelines! ^1
⁂