Bird
Raised Fist0
Testing Fundamentalstesting~15 mins

Smoke testing and sanity testing in Testing Fundamentals - Build an Automation Script

Choose your learning style10 modes available
Smoke and Sanity Testing for a Simple Calculator App
Preconditions (2)
Step 1: Verify the calculator app opens without errors (Smoke Test)
Step 2: Perform addition: enter 5, press '+', enter 3, press '='
Step 3: Verify the result displayed is 8 (Sanity Test)
Step 4: Perform subtraction: enter 10, press '-', enter 4, press '='
Step 5: Verify the result displayed is 6 (Sanity Test)
✅ Expected Result: Calculator app opens successfully. Addition and subtraction operations return correct results.
Automation Requirements - Selenium with Python
Assertions Needed:
Verify app launch by checking presence of calculator main screen element
Verify displayed result matches expected value after operations
Best Practices:
Use explicit waits to wait for elements
Use clear and maintainable locators (e.g., By.ID or By.ACCESSIBILITY_ID)
Separate test setup and teardown
Use assertions to validate results
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 CalculatorSmokeSanityTest(unittest.TestCase):
    def setUp(self):
        # Setup WebDriver for the calculator app (assuming Appium or similar)
        # For demonstration, using ChromeDriver to open a web calculator
        self.driver = webdriver.Chrome()
        self.driver.get('https://www.online-calculator.com/full-screen-calculator/')
        self.wait = WebDriverWait(self.driver, 10)

    def test_smoke_and_sanity(self):
        driver = self.driver
        wait = self.wait

        # Smoke Test: Verify calculator main screen loads
        calculator_frame = wait.until(EC.presence_of_element_located((By.ID, 'fullframe')))
        self.assertTrue(calculator_frame.is_displayed(), 'Calculator main screen did not load')

        # Switch to calculator iframe if needed
        driver.switch_to.frame('fullframe')

        # Sanity Test: Perform addition 5 + 3 = 8
        # Using keyboard input for simplicity
        body = driver.find_element(By.TAG_NAME, 'body')
        body.send_keys('5')
        body.send_keys('+')
        body.send_keys('3')
        body.send_keys('=')

        # Wait and verify result (the calculator shows result in the title attribute)
        # This is a simplification; real app may differ
        wait.until(lambda d: '8' in d.title)
        self.assertIn('8', driver.title, 'Addition result incorrect')

        # Sanity Test: Perform subtraction 10 - 4 = 6
        body.send_keys('C')  # Clear
        body.send_keys('1')
        body.send_keys('0')
        body.send_keys('-')
        body.send_keys('4')
        body.send_keys('=')

        wait.until(lambda d: '6' in d.title)
        self.assertIn('6', driver.title, 'Subtraction result incorrect')

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

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

This test script uses Selenium with Python's unittest framework to automate smoke and sanity tests for a calculator app.

setUp: Initializes the browser and opens the calculator webpage.

test_smoke_and_sanity: First, it waits for the calculator main screen to load (smoke test). Then it performs addition and subtraction operations by sending keys and verifies the results by checking the page title, which reflects the result (sanity tests).

tearDown: Closes the browser after tests.

Explicit waits ensure elements are ready before interacting. Assertions check that the app loads and calculations are correct.

Common Mistakes - 3 Pitfalls
Using hardcoded sleep instead of explicit waits
Using brittle locators like absolute XPath
Not verifying the app launch before proceeding
Bonus Challenge

Now add data-driven testing with 3 different sets of addition inputs and expected results.

Show Hint

Practice

(1/5)
1. What is the main purpose of smoke testing in software testing?
easy
A. To perform security testing on the application
B. To quickly check if the main features of a new build work
C. To verify the user interface design
D. To test detailed functionality of all features

Solution

  1. Step 1: Understand smoke testing purpose

    Smoke testing is done to quickly verify that the main features of a new software build are working and the build is stable enough for further testing.
  2. Step 2: Compare options with smoke testing definition

    To quickly check if the main features of a new build work matches this purpose exactly, while others describe different testing types.
  3. Final Answer:

    To quickly check if the main features of a new build work -> Option B
  4. Quick Check:

    Smoke testing = Quick main feature check [OK]
Hint: Smoke test = quick main feature check after build [OK]
Common Mistakes:
  • Confusing smoke testing with detailed testing
  • Thinking smoke testing checks UI design
  • Mixing smoke testing with security testing
2. Which of the following is the correct description of sanity testing?
easy
A. Checking specific functionality after small changes or bug fixes
B. Testing all features in detail after a major release
C. Performing load testing to check performance
D. Running automated tests for regression

Solution

  1. Step 1: Define sanity testing

    Sanity testing is a quick check of specific functionality or bug fixes after small changes to ensure they work as expected.
  2. Step 2: Match options to sanity testing

    Checking specific functionality after small changes or bug fixes correctly describes this focused testing, while others describe different testing types.
  3. Final Answer:

    Checking specific functionality after small changes or bug fixes -> Option A
  4. Quick Check:

    Sanity testing = Focused check after small changes [OK]
Hint: Sanity test = check specific fixes after small changes [OK]
Common Mistakes:
  • Confusing sanity testing with full regression testing
  • Thinking sanity testing covers all features
  • Mixing sanity testing with performance testing
3. Consider this scenario: A new build is deployed with multiple new features and bug fixes. Which testing should be done first to decide if detailed testing can proceed?
medium
A. Sanity testing on the fixed bugs only
B. Full regression testing on all features
C. Smoke testing on main features of the build
D. Performance testing under load

Solution

  1. Step 1: Identify testing purpose after new build

    After a new build with many changes, smoke testing is done first to quickly check main features and decide if the build is stable for further testing.
  2. Step 2: Evaluate options for initial testing

    Smoke testing on main features of the build matches this initial check. Sanity testing (Sanity testing on the fixed bugs only) is for small changes, not full builds. Full regression (Full regression testing on all features) and performance (Performance testing under load) come later.
  3. Final Answer:

    Smoke testing on main features of the build -> Option C
  4. Quick Check:

    New build? Start with smoke testing [OK]
Hint: New build? Start with smoke testing main features [OK]
Common Mistakes:
  • Starting with sanity testing on big builds
  • Skipping smoke testing and doing full regression immediately
  • Confusing performance testing as first step
4. A tester runs sanity testing after a small bug fix but finds unrelated features failing. What is the likely cause?
medium
A. Sanity testing scope was too narrow, missing regression tests
B. Smoke testing was done incorrectly
C. The bug fix introduced new unrelated bugs
D. Performance testing was skipped

Solution

  1. Step 1: Understand sanity testing scope

    Sanity testing focuses on verifying specific fixes or features, not the entire application.
  2. Step 2: Analyze failure of unrelated features

    If unrelated features fail, it means sanity testing missed broader checks. Full regression testing is needed to catch such issues.
  3. Final Answer:

    Sanity testing scope was too narrow, missing regression tests -> Option A
  4. Quick Check:

    Unrelated failures after sanity test? Need regression [OK]
Hint: Sanity test checks fixes only; unrelated fails need regression [OK]
Common Mistakes:
  • Blaming smoke testing for unrelated failures
  • Assuming bug fix always causes unrelated failures
  • Ignoring need for regression testing
5. A software team wants to improve testing efficiency after frequent small updates. Which approach best combines smoke and sanity testing?
hard
A. Perform performance testing before smoke or sanity testing
B. Skip smoke testing and run full regression after each update
C. Only run sanity testing on all features after every update
D. Run smoke testing on main features after every build, then sanity testing on specific fixes

Solution

  1. Step 1: Understand testing goals for frequent small updates

    To improve efficiency, quick checks are needed to catch major issues early, then focused checks on fixes.
  2. Step 2: Evaluate combined approach of smoke and sanity testing

    Running smoke testing on main features ensures build stability, followed by sanity testing on specific fixes ensures correctness of changes.
  3. Step 3: Eliminate other options

    Skipping smoke testing or running full regression every time is inefficient. Performance testing is unrelated to this goal.
  4. Final Answer:

    Run smoke testing on main features after every build, then sanity testing on specific fixes -> Option D
  5. Quick Check:

    Smoke then sanity for efficient small update testing [OK]
Hint: Smoke test main features, then sanity test fixes for efficiency [OK]
Common Mistakes:
  • Skipping smoke testing for faster results
  • Running full regression after every small update
  • Confusing performance testing with smoke/sanity
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