Bird
Raised Fist0
Testing Fundamentalstesting~20 mins

Automation maintenance challenges in Testing Fundamentals - Practice Problems & Coding Challenges

Choose your learning style10 modes available
Challenge - 5 Problems
🎖️
Automation Maintenance Master
Get all challenges correct to earn this badge!
Test your skills under time pressure!
🧠 Conceptual
intermediate
2:00remaining
Common cause of flaky automated tests

Which of the following is the most common cause of flaky automated tests that sometimes pass and sometimes fail without code changes?

ATests run only on local machines without parallel execution
BTests use hardcoded wait times that are always sufficient
CTests depend on external systems or network calls that are unstable
DTests use fixed data that never changes
Attempts:
2 left
💡 Hint

Think about what can cause unpredictable delays or failures outside the test code.

❓ assertion
intermediate
2:00remaining
Assertion to detect UI element disappearance

You want to verify that a loading spinner disappears after a page finishes loading in an automated UI test. Which assertion best checks this?

Aassert element.is_displayed() == True
Bassert element.is_displayed() == False
Cassert element.exists() == True
Dassert element.text == 'Loading'
Attempts:
2 left
💡 Hint

The spinner should not be visible after loading completes.

🔧 Debug
advanced
2:00remaining
Debugging intermittent test failure due to timing

Given this test code snippet, what is the most likely cause of intermittent failure?

Testing Fundamentals
button.click()
assert message.text == 'Success'
AThe test does not wait for the message to update after clicking the button
BThe assertion syntax is incorrect and causes a syntax error
CThe button variable is not defined before clicking
DThe message element is not visible on the page
Attempts:
2 left
💡 Hint

Think about what happens immediately after clicking a button in UI tests.

❓ framework
advanced
2:00remaining
Best practice for test data management in automation

Which approach is best to maintain test data for automated tests to reduce maintenance effort?

AStore test data externally in files or databases and load it dynamically during tests
BHardcode all test data directly inside test scripts
CManually update test data in each test script whenever requirements change
DUse random data generation without control or tracking
Attempts:
2 left
💡 Hint

Think about how to avoid changing many test scripts when data changes.

❓ Predict Output
expert
3:00remaining
Output of test retry logic with flaky function

What is the output of this Python test retry code when the flaky_function fails the first time and passes the second time?

Testing Fundamentals
def flaky_function():
    flaky_function.counter += 1
    if flaky_function.counter < 2:
        raise Exception('Fail')
    return 'Pass'

flaky_function.counter = 0

for attempt in range(3):
    try:
        result = flaky_function()
        print(f'Attempt {attempt+1}: {result}')
        break
    except Exception as e:
        print(f'Attempt {attempt+1}: {e}')
else:
    print('All attempts failed')
AAll attempts failed
BAttempt 1: Pass
C
Attempt 1: Fail
Attempt 2: Fail
Attempt 3: Pass
D
Attempt 1: Fail
Attempt 2: Pass
Attempts:
2 left
💡 Hint

Count how many times flaky_function raises an exception before returning 'Pass'.

Practice

(1/5)
1. Why is it important to update automated tests when the software changes?
easy
A. Because updating tests slows down the development process
B. Because tests never need updates once created
C. Because outdated tests may fail even if the software works correctly
D. Because automated tests do not depend on software changes

Solution

  1. Step 1: Understand the relationship between software and tests

    Automated tests check software behavior, so if software changes, tests must reflect those changes.
  2. Step 2: Identify the effect of not updating tests

    If tests are not updated, they may fail incorrectly, causing confusion and wasted effort.
  3. Final Answer:

    Because outdated tests may fail even if the software works correctly -> Option C
  4. Quick Check:

    Update tests when software changes = Avoid false failures [OK]
Hint: Tests must match software changes to avoid false failures [OK]
Common Mistakes:
  • Thinking tests never need updates
  • Believing tests run independently of software
  • Assuming updates slow development unnecessarily
2. Which of the following is the correct way to write a locator for a button with id 'submitBtn' in Selenium WebDriver?
easy
A. driver.find_element(By.ID, 'submitBtn')
B. driver.find_element_by_id('submitBtn')
C. driver.find_element('id', 'submitBtn')
D. driver.find_element_by_name('submitBtn')

Solution

  1. Step 1: Recall the modern Selenium locator syntax

    In recent Selenium versions, locators use By class with find_element(By.ID, 'value').
  2. Step 2: Identify the correct syntax among options

    driver.find_element(By.ID, 'submitBtn'): driver.find_element(By.ID, 'submitBtn'), which is correct syntax in Python Selenium.
  3. Final Answer:

    driver.find_element(By.ID, 'submitBtn') -> Option A
  4. Quick Check:

    Use By.ID with find_element = Correct locator syntax [OK]
Hint: Use By.ID with find_element for correct Selenium locator [OK]
Common Mistakes:
  • Using deprecated find_element_by_id method
  • Passing locator type as string instead of By class
  • Confusing id with name locator
3. Consider this Python test snippet using pytest:
def test_sum():
    a = 2
    b = 3
    assert a + b == 6

What will be the test result when this runs?
medium
A. Test is skipped automatically
B. Test passes successfully
C. Syntax error stops the test
D. Test fails due to wrong assertion

Solution

  1. Step 1: Evaluate the assertion logic

    The assertion checks if 2 + 3 equals 6, but 2 + 3 equals 5, so the assertion is false.
  2. Step 2: Determine test outcome based on assertion

    Since the assertion is false, pytest will mark the test as failed.
  3. Final Answer:

    Test fails due to wrong assertion -> Option D
  4. Quick Check:

    2 + 3 != 6 means assertion fails [OK]
Hint: Check assertion math carefully to predict test pass/fail [OK]
Common Mistakes:
  • Assuming assertion is true without calculation
  • Confusing syntax error with assertion failure
  • Thinking test skips without skip decorator
4. You have this Selenium test code snippet:
element = driver.find_element(By.ID, 'login')
element.click()

But the test fails with NoSuchElementException. What is the most likely cause?
medium
A. The driver object is not initialized
B. The element with id 'login' does not exist on the page
C. The click() method is not supported on elements
D. The syntax of find_element is incorrect

Solution

  1. Step 1: Understand NoSuchElementException meaning

    This exception means Selenium could not find the element with the given locator on the page.
  2. Step 2: Analyze possible causes

    If the element does not exist or is not loaded yet, this error occurs. The syntax and click() method are correct, and driver is assumed initialized.
  3. Final Answer:

    The element with id 'login' does not exist on the page -> Option B
  4. Quick Check:

    NoSuchElementException = Missing element on page [OK]
Hint: NoSuchElementException means locator found no matching element [OK]
Common Mistakes:
  • Blaming click() method for element not found
  • Assuming driver is uninitialized without evidence
  • Ignoring page load or locator correctness
5. A test automation suite has many flaky tests that fail randomly due to timing issues. Which approach best reduces maintenance effort and improves reliability?
hard
A. Use explicit waits to wait for specific conditions before actions
B. Rewrite all tests in a different programming language
C. Ignore flaky tests and run only stable ones
D. Add fixed long waits (sleep) before every action

Solution

  1. Step 1: Understand flaky tests caused by timing

    Flaky tests often fail because the test tries to interact before the page or element is ready.
  2. Step 2: Evaluate maintenance-friendly solutions

    Using explicit waits waits only as long as needed for conditions, improving reliability without slowing tests unnecessarily.
  3. Step 3: Compare other options

    Fixed long waits slow tests and increase maintenance. Ignoring flaky tests risks missing bugs. Rewriting tests is costly and unrelated to timing issues.
  4. Final Answer:

    Use explicit waits to wait for specific conditions before actions -> Option A
  5. Quick Check:

    Explicit waits = Reliable, maintainable tests [OK]
Hint: Use explicit waits, not fixed sleeps, to fix flaky tests [OK]
Common Mistakes:
  • Using fixed sleeps causing slow, brittle tests
  • Ignoring flaky tests instead of fixing
  • Thinking rewriting tests solves timing issues
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard