Test Execution and Documentation

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:

This gives the team a quick picture of the current testing progress.

3. Expected vs Actual Result

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.

Example of an Execution Report:

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:

The question here is:

Have we tested all the requirements?

And if something fails:

Which requirement and test case are affected?

What I am Learning

Test execution shows that testing isn't finished wafter running all test because, good QA 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 was 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.

Notes can be found here

I'm learning QA and I'm taking you with me.