Why Test case components (steps, expected, actual) in Testing Fundamentals? - Purpose & Use Cases

The Big Idea

What if your testing notes could instantly show exactly what works and what breaks?

The Scenario

Imagine you have a long list of things to check on a website by clicking buttons and typing text, but you write down everything in a messy notebook without clear order or results.

The Problem

Writing test steps and results by hand is slow and confusing. You might forget what you did, mix up what should happen, or miss recording what actually happened. This leads to mistakes and wasted time.

The Solution

Using clear test case components--steps to follow, expected results, and actual results--helps you organize testing like a recipe. It makes checking easy, repeatable, and shows exactly where things go wrong.

Before vs After

✗ Before

Open app, click button, see if it works, write notes

✓ After

Step 1: Open app
Expected: App opens
Actual: App opened
Step 2: Click button
Expected: New page loads
Actual: New page loaded

What It Enables

It enables clear communication and fast finding of problems so fixes happen quickly and confidently.

Real Life Example

When testing a shopping cart, clear steps say: add item, expect item count to increase, record if it does. This avoids guessing what happened and helps fix bugs fast.

Key Takeaways

Test case components organize testing into clear steps.

Expected and actual results show if software works as planned.

This method saves time and reduces errors in testing.

Practice

1. Which component of a test case describes the actions a tester must perform?

easy

A. Test steps

B. Expected results

C. Actual results

D. Test summary

Solution

1. Step 1: Understand test case components

   Test cases have steps, expected results, and actual results.

2. Step 2: Identify which describes actions

   Test steps tell the tester what to do, the actions to perform.

3. Final Answer:

   Test steps -> Option A

4. Quick Check:

   Actions = Test steps [OK]

Hint: Steps = actions to perform in test case [OK]

Common Mistakes:

• Confusing expected results with steps
• Thinking actual results describe actions
• Mixing test summary with steps

2. Which of the following is the correct way to write the expected result in a test case?

easy

A. User clicks the login button and waits.

B. Click the login button to open the login page.

C. Login page appears sometimes after clicking.

D. The system should display the login page after clicking the login button.

Solution

1. Step 1: Identify expected result format

   Expected results describe what should happen clearly and precisely.

2. Step 2: Compare options

   The system should display the login page after clicking the login button. clearly states the expected system behavior after an action.

3. Final Answer:

   The system should display the login page after clicking the login button. -> Option D

4. Quick Check:

   Expected result = clear system behavior [OK]

Hint: Expected result = clear, precise system behavior [OK]

Common Mistakes:

• Writing steps instead of expected results
• Being vague or uncertain in expected results
• Mixing user actions with expected outcomes

3. Given this test case snippet:

Steps: 1. Enter username 'user1'
2. Enter password 'pass123'
3. Click 'Submit'
Expected: User is logged in and dashboard appears
Actual: Error message 'Invalid credentials'

What does this test result indicate?

medium

A. Test failed due to incorrect actual result

B. Expected result is wrong

C. Test steps are incomplete

D. Test passed successfully

Solution

1. Step 1: Compare expected and actual results

   Expected is successful login; actual shows error message.

2. Step 2: Determine test outcome

   Mismatch means test failed due to unexpected actual result.

3. Final Answer:

   Test failed due to incorrect actual result -> Option A

4. Quick Check:

   Expected ≠ Actual = Fail [OK]

Hint: If actual ≠ expected, test fails [OK]

Common Mistakes:

• Assuming test passed despite different actual result
• Confusing steps with results
• Ignoring error messages in actual results

4. A tester wrote this test case:

Steps: 1. Open app
2. Click 'Settings'
Expected: Settings page opens
Actual: Settings page opens

But the test is marked as failed. What is the most likely error?

medium

A. Steps are missing details

B. Actual result was not recorded correctly

C. Expected result is unclear

D. Test case lacks test data

Solution

1. Step 1: Check expected vs actual results

   Both say settings page opens, so results match.

2. Step 2: Consider why test marked failed

   If test failed despite matching results, actual result might be recorded incorrectly or test status set wrongly.

3. Final Answer:

   Actual result was not recorded correctly -> Option B

4. Quick Check:

   Matching results but fail = recording error [OK]

Hint: Matching expected and actual means test should pass [OK]

Common Mistakes:

• Assuming missing steps cause fail here
• Confusing unclear expected with fail reason
• Ignoring test status errors

5. You have a test case with these components:

Steps: 1. Add item to cart
2. Proceed to checkout
Expected: Total price updates correctly
Actual: Total price remains unchanged

How should you update the test case to better capture the issue?

hard

A. Remove actual result to avoid confusion

B. Change expected result to match actual price

C. Add detailed steps to verify price calculation and record exact actual price

D. Skip the test since actual differs from expected

Solution

1. Step 1: Analyze test case problem

   Actual result shows a bug: price not updating as expected.

2. Step 2: Improve test case details

   Adding detailed steps and exact actual price helps reproduce and fix the bug.

3. Final Answer:

   Add detailed steps to verify price calculation and record exact actual price -> Option C

4. Quick Check:

   More detail = better bug capture [OK]

Hint: Add details and exact actual results to clarify bugs [OK]

Common Mistakes:

• Changing expected to hide bugs
• Removing actual results loses evidence
• Skipping tests hides problems