Why documentation ensures repeatability in Testing Fundamentals - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to show how documentation helps repeat tests.

Testing Fundamentals

def test_login():
    # Step 1: Open browser
    open_browser()
    # Step 2: Enter username
    enter_text('username_field', [1])
    # Step 3: Enter password
    enter_text('password_field', 'pass123')
    # Step 4: Click login
    click_button('login')
    assert is_logged_in() == True

Drag options to blanks, or click blank then click option'

A'test'

B'random_user'

C'admin_user'

D'guest'

Attempts:

3 left

💡 Hint

Common Mistakes

Using random or changing usernames that break repeatability.

Documentation specifies exact inputs like 'admin_user' to ensure the test can be repeated exactly.

2fill in blank

medium

Complete the code to document the expected result for repeatability.

Testing Fundamentals

def test_add_item():
    add_item('apple')
    result = get_cart_items()
    assert result == [1]

Drag options to blanks, or click blank then click option'

A['banana']

B['apple', 'banana']

C[]

D['apple']

Attempts:

3 left

💡 Hint

Common Mistakes

Expecting wrong or extra items in the cart.

The documentation states the cart should contain only ['apple'] after adding it, ensuring repeatability.

3fill in blank

hard

Fix the error in the test to follow documented steps for repeatability.

Testing Fundamentals

def test_remove_item():
    add_item('orange')
    remove_item([1])
    result = get_cart_items()
    assert result == []

Drag options to blanks, or click blank then click option'

A'orange'

B'banana'

C'grape'

D'apple'

Attempts:

3 left

💡 Hint

Common Mistakes

Removing an item not added, causing test failure.

The documented test adds 'orange' and removes 'orange' to ensure repeatability and correct results.

4fill in blank

hard

Fill both blanks to document a test that checks login failure with wrong password.

Testing Fundamentals

def test_login_fail():
    enter_text('username_field', [1])
    enter_text('password_field', [2])
    click_button('login')
    assert is_logged_in() == False

Drag options to blanks, or click blank then click option'

A'admin_user'

B'wrong_pass'

C'guest_user'

D'123456'

Attempts:

3 left

💡 Hint

Common Mistakes

Using invalid usernames or correct passwords that break the test logic.

Documentation specifies using 'admin_user' with 'wrong_pass' to test login failure repeatably.

5fill in blank

hard

Fill all three blanks to document a test that verifies item quantity update.

Testing Fundamentals

def test_update_quantity():
    add_item([1])
    update_quantity([2], [3])
    result = get_item_quantity([2])
    assert result == 5

Drag options to blanks, or click blank then click option'

A'apple'

C5

D3

Attempts:

3 left

💡 Hint

Common Mistakes

Using different item names or quantities than documented.

Documentation uses 'apple' as item, updates quantity to 5, and checks that quantity for repeatability.

Practice

1. Why is documentation important for repeatability in software testing?

easy

A. It automatically fixes bugs found during testing

B. It makes the test run faster on all machines

C. It clearly describes test steps and expected results for others to follow

D. It reduces the need for testers to communicate

Solution

1. Step 1: Understand the role of documentation

   Documentation provides clear instructions and expected outcomes for tests.

2. Step 2: Connect documentation to repeatability

   Clear steps allow anyone to run the test the same way, ensuring repeatability.

3. Final Answer:

   It clearly describes test steps and expected results for others to follow -> Option C

4. Quick Check:

   Documentation = Clear steps = Repeatability [OK]

Hint: Documentation means clear steps and results for repeat tests [OK]

Common Mistakes:

• Thinking documentation speeds up tests
• Believing documentation fixes bugs automatically
• Assuming documentation replaces communication

2. Which of the following is the correct way to document a test step?

easy

A. Run the test and see what happens

B. Click the 'Submit' button and expect a confirmation message

C. Guess the expected result based on intuition

D. Skip writing steps if the test is simple

Solution

1. Step 1: Identify proper test step documentation

   Test steps should be clear actions with expected outcomes.

2. Step 2: Evaluate options for clarity and correctness

   Click the 'Submit' button and expect a confirmation message clearly states the action and expected result, making it correct.

3. Final Answer:

   Click the 'Submit' button and expect a confirmation message -> Option B

4. Quick Check:

   Clear action + expected result = Correct documentation [OK]

Hint: Document clear actions and expected results [OK]

Common Mistakes:

• Writing vague or incomplete steps
• Skipping expected results
• Assuming testers will guess outcomes

3. Consider this test documentation snippet:

1. Open login page
2. Enter username 'user1'
3. Enter password 'pass123'
4. Click 'Login'
Expected result: User dashboard appears

What is the main benefit of this documentation?

medium

A. It allows anyone to repeat the test exactly and verify the same result

B. It guarantees the test will find all bugs in the login feature

C. It makes the test run faster on different browsers

D. It removes the need for testers to check the dashboard manually

Solution

1. Step 1: Analyze the test steps and expected result

   The steps are clear and detailed, describing exactly what to do and expect.

2. Step 2: Understand the benefit of clear documentation

   Clear steps let anyone run the test the same way and check if the dashboard appears.

3. Final Answer:

   It allows anyone to repeat the test exactly and verify the same result -> Option A

4. Quick Check:

   Clear steps + expected result = Repeatability [OK]

Hint: Clear steps let anyone repeat and verify results [OK]

Common Mistakes:

• Assuming documentation finds all bugs
• Thinking documentation speeds up tests
• Believing manual checks are unnecessary

4. A tester wrote this documentation:

1. Click 'Submit'
2. Expect success message

What is the main problem here?

medium

A. The test will run too slowly

B. The documentation is too long and complicated

C. The expected result is incorrect

D. The steps are too vague and lack details for repeatability

Solution

1. Step 1: Review the test steps for clarity

   The steps do not specify which 'Submit' button or what success message exactly.

2. Step 2: Understand impact on repeatability

   Vague steps make it hard for others to repeat the test reliably.

3. Final Answer:

   The steps are too vague and lack details for repeatability -> Option D

4. Quick Check:

   Vague steps = Poor repeatability [OK]

Hint: Vague steps cause repeatability problems [OK]

Common Mistakes:

• Thinking test speed is affected by documentation
• Assuming expected result is always wrong if vague
• Believing longer docs are always bad

5. You have a test documented as:

1. Navigate to user profile
2. Update email to '[e-mail]'
3. Save changes
Expected: Confirmation message appears

Later, the app changes to require email verification after update. How should you update the documentation to keep repeatability?

hard

A. Add a step to check the verification email and confirm it

B. Remove the expected confirmation message

C. Keep the documentation as is because the test passed before

D. Skip the test since the app changed

Solution

1. Step 1: Identify the app change impact

   The app now requires email verification after update, changing expected behavior.

2. Step 2: Update documentation to reflect new steps

   Add steps to check and confirm the verification email to keep the test accurate and repeatable.

3. Final Answer:

   Add a step to check the verification email and confirm it -> Option A

4. Quick Check:

   Update docs with new steps = Maintain repeatability [OK]

Hint: Update docs when app changes to keep tests repeatable [OK]

Common Mistakes:

• Ignoring app changes in documentation
• Removing expected results without replacement
• Skipping tests instead of updating docs