Bird
Raised Fist0
Testing Fundamentalstesting~15 mins

Defect lifecycle in Testing Fundamentals - Build an Automation Script

Choose your learning style10 modes available
Verify Defect Lifecycle Status Transitions
Preconditions (2)
Step 1: Open the defect details page
Step 2: Change defect status from 'New' to 'Assigned'
Step 3: Save the defect
Step 4: Verify the status is updated to 'Assigned'
Step 5: Change defect status from 'Assigned' to 'Fixed'
Step 6: Save the defect
Step 7: Verify the status is updated to 'Fixed'
Step 8: Change defect status from 'Fixed' to 'Retest'
Step 9: Save the defect
Step 10: Verify the status is updated to 'Retest'
Step 11: Change defect status from 'Retest' to 'Closed'
Step 12: Save the defect
Step 13: Verify the status is updated to 'Closed'
✅ Expected Result: The defect status changes correctly through the lifecycle states: New -> Assigned -> Fixed -> Retest -> Closed, and each status update is saved and displayed properly.
Automation Requirements - Selenium with Python
Assertions Needed:
Verify defect status text matches expected status after each update
Verify defect status element is visible and enabled before interaction
Best Practices:
Use explicit waits to wait for elements to be clickable or visible
Use Page Object Model to separate page interactions
Use clear and maintainable locators (id, name, or CSS selectors)
Include meaningful assertion messages
Automated Solution
Testing Fundamentals
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
import unittest

class DefectLifecyclePage:
    def __init__(self, driver):
        self.driver = driver
        self.status_dropdown = (By.ID, 'defect-status')
        self.save_button = (By.ID, 'save-defect')
        self.status_text = (By.ID, 'current-status')

    def select_status(self, status):
        dropdown = WebDriverWait(self.driver, 10).until(
            EC.element_to_be_clickable(self.status_dropdown))
        dropdown.click()
        option = WebDriverWait(self.driver, 10).until(
            EC.element_to_be_clickable((By.XPATH, f"//select[@id='defect-status']/option[text()='{status}']")))
        option.click()

    def save_defect(self):
        save_btn = WebDriverWait(self.driver, 10).until(
            EC.element_to_be_clickable(self.save_button))
        save_btn.click()

    def get_status(self):
        status_element = WebDriverWait(self.driver, 10).until(
            EC.visibility_of_element_located(self.status_text))
        return status_element.text

class TestDefectLifecycle(unittest.TestCase):
    def setUp(self):
        self.driver = webdriver.Chrome()
        self.driver.get('http://defect-tracker.example.com/defect/123')
        # Assume user is already logged in for simplicity
        self.page = DefectLifecyclePage(self.driver)

    def test_defect_status_transitions(self):
        statuses = ['Assigned', 'Fixed', 'Retest', 'Closed']
        for status in statuses:
            self.page.select_status(status)
            self.page.save_defect()
            current_status = self.page.get_status()
            self.assertEqual(current_status, status, f"Expected status to be '{status}' but got '{current_status}'")

    def tearDown(self):
        self.driver.quit()

if __name__ == '__main__':
    unittest.main()

This script uses Selenium with Python and unittest framework to automate the defect lifecycle status changes.

The DefectLifecyclePage class represents the defect details page. It uses explicit waits to ensure elements are clickable or visible before interacting. This avoids timing issues.

The test_defect_status_transitions method changes the defect status through the lifecycle states one by one. After each change, it saves and verifies the status text matches the expected value.

Assertions include clear messages to help understand failures.

The setUp and tearDown methods handle browser start and cleanup.

This structure follows the Page Object Model for maintainability and uses best practices like explicit waits and meaningful assertions.

Common Mistakes - 3 Pitfalls
Using hardcoded sleep (time.sleep) instead of explicit waits
Using brittle XPath selectors with absolute paths
Not verifying the status after each update
Bonus Challenge

Now add data-driven testing with 3 different defect IDs to verify lifecycle transitions for multiple defects.

Show Hint

Practice

(1/5)
1. Which state in the defect lifecycle indicates that a bug has been found but not yet assigned to a developer?
easy
A. New
B. Fixed
C. Retest
D. Closed

Solution

  1. Step 1: Understand the meaning of 'New' state

    The 'New' state means the defect is just reported and has not been assigned yet.
  2. Step 2: Compare with other states

    'Fixed' means the bug is corrected, 'Retest' means testing the fix, and 'Closed' means the bug is resolved and accepted.
  3. Final Answer:

    New -> Option A
  4. Quick Check:

    New = Bug found but unassigned [OK]
Hint: New means just found, not assigned yet [OK]
Common Mistakes:
  • Confusing 'New' with 'Open' or 'Assigned'
  • Thinking 'Fixed' means bug is new
  • Mixing 'Retest' with initial bug discovery
2. Which of the following is the correct order of states in a typical defect lifecycle?
easy
A. New -> Assigned -> Open -> Fixed -> Retest -> Closed
B. Fixed -> New -> Assigned -> Open -> Retest -> Closed
C. New -> Open -> Assigned -> Fixed -> Closed -> Retest
D. Assigned -> New -> Open -> Fixed -> Retest -> Closed

Solution

  1. Step 1: Recall the standard defect lifecycle sequence

    The typical order is New (reported), Assigned (developer assigned), Open (work started), Fixed (bug fixed), Retest (testing fix), Closed (bug resolved).
  2. Step 2: Match the options with this sequence

    New -> Assigned -> Open -> Fixed -> Retest -> Closed matches the correct order exactly; others have states out of order.
  3. Final Answer:

    New -> Assigned -> Open -> Fixed -> Retest -> Closed -> Option A
  4. Quick Check:

    Lifecycle order = B [OK]
Hint: Follow the bug from report to closure in order [OK]
Common Mistakes:
  • Mixing 'Assigned' and 'Open' order
  • Placing 'Fixed' before 'Assigned'
  • Confusing 'Retest' and 'Closed' positions
3. Consider this defect lifecycle snippet:
defect_states = ['New', 'Assigned', 'Open', 'Fixed', 'Retest', 'Closed']
current_state = 'Fixed'
next_state = defect_states[defect_states.index(current_state) + 1]
print(next_state)

What will be the output?
medium
A. Fixed
B. Retest
C. Open
D. Closed

Solution

  1. Step 1: Find the index of 'Fixed' in the list

    'Fixed' is at index 3 in defect_states list.
  2. Step 2: Calculate next_state using index + 1

    Index 3 + 1 = 4, so next_state = defect_states[4] which is 'Retest'.
  3. Final Answer:

    Retest -> Option B
  4. Quick Check:

    Next after Fixed = Retest [OK]
Hint: Index +1 gives next lifecycle state [OK]
Common Mistakes:
  • Choosing 'Closed' instead of 'Retest'
  • Confusing index positions
  • Assuming current_state prints itself
4. A tester reports a defect and marks it as 'Closed' immediately without retesting. What is the likely issue in this defect lifecycle process?
medium
A. Opening defect after fixing
B. Assigning defect before it is New
C. Reopening defect without fixing
D. Skipping the Retest phase

Solution

  1. Step 1: Understand the defect lifecycle phases

    After fixing, the defect should be retested before closing to confirm the fix.
  2. Step 2: Identify the problem with skipping Retest

    Marking as 'Closed' without retesting skips verification, risking unresolved bugs.
  3. Final Answer:

    Skipping the Retest phase -> Option D
  4. Quick Check:

    Retest must happen before Close [OK]
Hint: Always retest before closing a defect [OK]
Common Mistakes:
  • Closing defect without verification
  • Confusing 'Closed' with 'Fixed'
  • Ignoring defect assignment order
5. A defect is marked as 'Reopened' after failing retest. Which of the following best describes the next correct step in the defect lifecycle?
hard
A. Mark the defect as 'New' again and wait for retest
B. Close the defect immediately as it failed retest
C. Assign the defect back to the developer for fixing
D. Skip fixing and move to 'Retest' again

Solution

  1. Step 1: Understand 'Reopened' state meaning

    'Reopened' means the defect was fixed but failed retesting, so it needs fixing again.
  2. Step 2: Determine the next lifecycle step

    The defect should be assigned back to the developer to fix the issue properly before retesting.
  3. Final Answer:

    Assign the defect back to the developer for fixing -> Option C
  4. Quick Check:

    Reopened = Assign to developer [OK]
Hint: Reopened defects go back to developer for fix [OK]
Common Mistakes:
  • Closing defect after failed retest
  • Resetting defect to 'New' incorrectly
  • Skipping fix and retesting again
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