I have learned how to design tests, and the next is how to actually document and run them.
I need to execute the tests, record what happened, report problems, and keep track of what has been tested.
1. Test Case Execution
A test case tells me what to test and how to test it.
During execution, I follow the steps and compare the actual result with the expected result.
For example:
Test: Login with valid credentials
Expected: User should be successfully logged in.
Actual: User is successfully logged in.
Result: PASS ✅
But what if the login fails?
Actual: Error message: "Invalid credentials"
Result: FAIL ❌
And here, documentation becomes important.
2. Test Status
Not every test will simply be Pass or Fail.
Common statuses include:
| Status | Meaning |
|---|---|
| Pass ✅ | Expected result was achieved |
| Fail ❌ | Actual result differs from expected result |
| Blocked 🚫 | Test cannot be executed because of a blocker |
| Not Run ⏳ | Test hasn't been executed yet |
This gives the team a quick picture of the current testing progress.
3. Expected vs Actual Result
One thing I'm learning is to keep these two separate.
Expected Result -> What should happen?
Actual Result -> What actually happened?
This difference is very important when reporting a bug.
Instead of saying:
"Login doesn't work."
I should be able to say:
Expected: User should log in with valid credentials.
Actual: User remains on the login page and receives an error message.
That's much easier for someone else to understand and investigate.
4. Bug Reporting
When a test fails because of a defect, I need to report it clearly.
A useful bug report usually contains:
- Bug ID
- Title
- Description
- Steps to reproduce
- Test data
- Expected result
- Actual result
- Severity
- Priority
- Environment
- Screenshots or other evidence
The goal isn't simply to say that there's a bug.
The goal is to give the developer enough information to reproduce and understand the problem.
5. Retesting vs Regression Testing
When a developer fixes a bug, I don't just assume it's fixed.
I retest it to know if the specific bug got fixed.
For example:
A login bug was reported.
The developer fixes it.
I run the same steps again to verify the fix.
Next, I do a Regression Testing to know if the fix broke anything else?
I test related or existing functionality to make sure the change hasn't introduced new problems.
So:
Retesting -> Check the fix
Regression -> Check for unintended impact
6. Test Execution Reports
As testing progresses, the team needs to know what's happening.
For example:
Total Tests: 50
Executed: 38
Passed: 32
Failed: 6
Blocked: 4
Not Run: 8
From this, we can calculate useful metrics such as:
- Test coverage
- Pass rate
- Fail rate
- Blocked tests
- Remaining tests
The numbers help communicate the current state of testing.
7. Requirements Traceability Matrix
Another useful document is the RTM - Requirements Traceability Matrix.
It connects requirements to test cases and, where applicable, defects.
For example:
| Requirement | Test Case | Result | Bug |
|---|---|---|---|
| User can log in | TC-LOGIN-001 | Fail | BUG-001 |
| User can search products | TC-SEARCH-001 | Pass | — |
This helps answer:
"Have we tested all the requirements?"
And if something fails:
"Which requirement and test case are affected?"
What I am Learning
Test execution has taught me that testing isn't finished when I click Run.
Good QA also means:
Execute → Observe → Compare → Document → Report → Retest → Verify
The quality of the documentation matters because testing is a team activity.
Someone else should be able to understand:
- What I tested
- What happened
- What failed
- Why it failed
- What has been fixed
- What still needs attention
I will start working on a small QA project, creating test scenarios, test cases, executing them, reporting bugs, and documenting the results.
I'm learning QA and I'm taking you with me.
Top comments (0)