Course Curriculum
MODULE 01 BDD Fundamentals & Core Concepts
WHY THIS MODULE

BDD is appearing on every QA job description — and interviewers always ask "have you worked with BDD?" without realising many testers only know it by name. Starting here means you understand the problem BDD was built to solve, which makes every technical decision in the framework make logical sense. You will never just copy-paste a feature file again — you will know why every word in it is the way it is.

Key Topics Covered
What is BDD Communication Gap Problem Customer / Developer / Tester Triangle BDD vs TDD Given / When / Then Gherkin Language Overview Cucumber vs pytest-bdd Three Amigos Concept
What You Will Be Able to Do
  • Explain the communication problem BDD solves — customer says "security", developer builds "auth", tester writes "login" — all the same feature, three different understandings
  • Describe how Given / When / Then creates one shared language for all stakeholders
  • Compare BDD with TDD and explain which approach suits which project context
  • Distinguish between Cucumber (Java) and pytest-bdd (Python) as equivalent BDD tools
MODULE 02 Gherkin Language & Feature Files
WHY THIS MODULE

The feature file is the heart of BDD — it is what a project manager, a business analyst, or a client can actually read and confirm is correct before a single line of Python is written. Writing good Gherkin is a skill on its own: too vague and it is useless, too technical and it defeats the purpose. Getting this right means your scenarios become living documentation that the whole team trusts.

Key Topics Covered
.feature file Feature: / Scenario: Given / When / Then / And Background: Scenario Outline: + Examples: Parameter Placeholders {} Data Table in Examples Cucumber Plugin (PyCharm)
What You Will Be Able to Do
  • Create .feature files with correct Gherkin syntax — Feature, Scenario, Given, When, Then
  • Use Background to define shared precondition steps that run before every scenario automatically
  • Write a Scenario Outline with an Examples table to run one test with multiple data rows
  • Use {username} style placeholders to pass Examples table values into scenario step text
  • Set up the Cucumber plugin in PyCharm for Gherkin syntax highlighting and navigation
MODULE 03 pytest-bdd Framework Setup
WHY THIS MODULE

A poorly structured project is one of the most common reasons BDD frameworks fail in real teams. Wrong folder layout, missing __init__.py files, or incorrect pytest.ini settings cause confusing errors that have nothing to do with your actual tests. Getting the structure right from day one means you can scale from 5 scenarios to 500 without restructuring everything — and your team can navigate the project immediately.

Key Topics Covered
pip install pytest pytest-bdd selenium pip install webdriver-manager features/ folder steps/ package (__init__.py) conftest.py pytest.ini bdd_features_base_dir Python Package vs Folder
What You Will Be Able to Do
  • Install all required packages: pytest, pytest-bdd, selenium, and webdriver-manager
  • Create the standard BDD project structure: features/ for Gherkin, steps/ for Python code
  • Understand why the steps folder needs an __init__.py to become a Python package
  • Configure pytest.ini with bdd_features_base_dir to remove repeated path strings
  • Run the first skeleton scenario end-to-end and confirm the whole setup is working
MODULE 04 Step Definitions & Parameter Handling
WHY THIS MODULE

Step definitions are where Gherkin meets Python — the bridge between plain English test scenarios and real executable code. Without understanding how decorators, parsers, and parameter extraction work, your step files become a mess of duplicate functions and hard-coded values. Mastering this module means you can write steps that are genuinely reusable across dozens of scenarios — a skill that sets professional BDD testers apart.

Key Topics Covered
@scenario() @given() / @when() / @then() parsers.parse() Curly Bracket Parameters {value} Multiple Parameters Reusable Step Definitions functools.partial() Step File Organisation
What You Will Be Able to Do
  • Bind Gherkin step text to Python functions using @given, @when, and @then decorators
  • Link a complete scenario from a feature file to a test function using @scenario
  • Extract parameter values from step text using parsers.parse() with curly bracket notation
  • Pass multiple parameters (username and password) from Scenario Outline Examples into step functions
  • Use functools.partial() to avoid repeating the feature file path on every @scenario decorator
  • Organise step definitions into separate files — one per feature area — for clean maintainability
MODULE 05 Selenium Integration & WebDriver Management
WHY THIS MODULE

BDD without browser automation is just documentation. Selenium is what turns your Gherkin scenarios into real tests that open a browser, click through a real web application, and verify actual results. webdriver_manager removes the most common maintenance pain — manually updating Chrome drivers — so your tests never break due to a browser update. This module is where your framework comes alive for the first time.

Key Topics Covered
from selenium import webdriver from selenium.webdriver.common.by import By ChromeDriverManager().install() driver.get(url) find_element(By.ID / By.XPATH) send_keys() / click() Implicit Wait WebDriverWait + ExpectedConditions driver.title / driver.quit()
What You Will Be Able to Do
  • Initialise ChromeDriver using webdriver_manager — no manual driver downloads ever again
  • Open a URL, maximise the window, and navigate using step definitions
  • Locate elements using By.ID, By.XPATH, and By.CSS_SELECTOR and interact with them
  • Implement explicit waits with WebDriverWait so tests never fail due to page load timing
  • Verify page state using assertions on driver.title and element text or visibility
  • Close the browser cleanly at the end of every test run
MODULE 06 Fixtures & Dependency Injection
WHY THIS MODULE

The target_fixture pattern in pytest-bdd is one of the most confusing things for new BDD users — and one of the most powerful. Without it, you end up initialising the browser in every single step (slow and messy) or using global variables (fragile and unprofessional). With fixtures and dependency injection, the browser is created once, shared cleanly across all steps in a scenario, and closed automatically. This is the technique that makes your framework production-grade.

Key Topics Covered
@pytest.fixture target_fixture="driver" Return driver from @given step Dependency Injection concept Driver as function argument conftest.py shared fixtures yield fixture Fixture Scope
What You Will Be Able to Do
  • Create a @given step that opens the browser and returns it as a named fixture using target_fixture="driver"
  • Inject the driver into any @when or @then step simply by adding "driver" as a function parameter
  • Understand dependency injection: pytest automatically resolves and provides fixture values
  • Place shared fixtures in conftest.py so all step files in the project can use them without importing
  • Use yield inside a fixture to open the browser before the test and close it after — automatically
MODULE 07 Advanced BDD Patterns
WHY THIS MODULE

A framework that works for 5 scenarios will collapse under 50 if it was not built with scalability in mind. Background stops you repeating the same "navigate to login page" step in every scenario. Scenario Outline removes the need to write ten near-identical scenarios for ten sets of test data. These patterns are what make a real-world BDD project maintainable by a whole team — not just the person who built it.

Key Topics Covered
Background: keyword Scenario Outline: + Examples: Data-driven BDD testing Multiple Feature & Step Files bdd_features_base_dir functools.partial() Tags & Selective Execution Shared vs Feature-specific Steps
What You Will Be Able to Do
  • Use Background so common preconditions (like navigating to a page) run before every scenario automatically
  • Write one Scenario Outline that runs with 10 different data rows — not 10 separate scenarios
  • Organise a growing test suite into multiple feature files and corresponding step files by area
  • Configure pytest.ini to eliminate repeated feature folder path strings across all step files
  • Apply functools.partial() to create clean @scenario wrappers without path repetition
  • Tag specific scenarios with @pytest.mark and run only tagged tests with a single command option
MODULE 08 Hooks, Screenshots & Error Handling
WHY THIS MODULE

When a test fails at 2 AM in a CI/CD pipeline, nobody can manually check what went wrong. A screenshot taken the instant of failure — named with the scenario name, step name, and timestamp — tells the full story in seconds. Hooks are what make this happen automatically, with zero code in the actual test scenarios. This is the difference between a prototype framework and a production-ready one that your whole team relies on.

Key Topics Covered
@pytest.fixture(autouse=True) pytest_bdd_step_error() before_scenario / after_scenario request.getfixturevalue('driver') driver.save_screenshot(filename) datetime.now().strftime() Dynamic Screenshot Naming Scenario Name Extraction Browser Closure on Failure
What You Will Be Able to Do
  • Implement before and after scenario hooks using autouse fixtures that run without being called explicitly
  • Use the pytest_bdd_step_error hook to automatically capture a screenshot the instant any step fails
  • Name screenshots dynamically using the scenario name + current timestamp so they are always unique
  • Access the driver inside a hook using request.getfixturevalue('driver') without adding it as a parameter
  • Extract the failing step name, feature name, and exception details from hook arguments for detailed logs
  • Guarantee the browser closes after every test — pass or fail — so no orphaned browser processes remain
MODULE 09 Page Object Model with BDD
WHY THIS MODULE

In any real application, locators change constantly — developers rename IDs, restructure pages, move buttons. Without Page Object Model, a single locator change means hunting through every step file to find and fix it. With POM, you update one line in one class and every scenario that uses that page still works. This is the design pattern that makes a BDD framework maintainable for years, not just for the week it was built.

Key Topics Covered
pages/ package Page Class with Private Locators Public Action Methods Public Verification Methods __init__(self, driver) LoginPage / HomePage classes Import Page Classes in Steps Page Object via target_fixture
What You Will Be Able to Do
  • Create a pages/ folder with a dedicated Python class for each page of the application
  • Store all locators as private class attributes — never scattered across step files
  • Write readable action methods (enter_username, click_login) and verification methods (verify_home_displayed)
  • Pass the driver into a Page class through its constructor so it always controls the right browser
  • Import and instantiate Page classes cleanly in step definition files
  • Return a page object as a target_fixture from a @given step so all following steps can use it automatically
MODULE 10 Allure Reporting & Interview Prep
WHY THIS MODULE

A framework that cannot present its results clearly is invisible to the people who matter — managers, clients, and stakeholders. Allure turns your raw test output into a beautiful, interactive report with pass/fail charts, step-by-step breakdowns, and failure screenshots all in one place. This is what you show in a demo or a job interview to prove your framework is professional. And the interview prep in this module ensures you can explain every part of it with confidence.

Key Topics Covered
pip install allure-pytest pytest --alluredir=allure-results allure generate allure-results allure serve allure-results allure.attach() System PATH for Allure CLI Screenshot in Allure Report Framework Architecture Explanation Generic Method Pattern
What You Will Be Able to Do
  • Install allure-pytest and add the Allure CLI to the system PATH so it works from any terminal
  • Run your test suite and save raw results with pytest --alluredir flag
  • Generate and open a full interactive Allure report in the browser with one command
  • Attach failure screenshots directly to Allure report entries using allure.attach()
  • Generate an HTML report alternative using pytest-html for quick sharing
  • Walk through your entire framework architecture — feature files, steps, fixtures, POM, hooks, reporting — in an interview

Interview Preparation Tips

What is BDD and why use it?

BDD fixes the gap between what business wants and what tech builds. Tests in Gherkin (Given/When/Then) are readable by non-technical stakeholders, ensuring everyone is testing the same understanding of a requirement — not three different interpretations.

How does target_fixture work?

Adding target_fixture="driver" to a @given decorator makes the step's return value become a named pytest fixture. Any later step that lists "driver" as a function argument receives that browser instance automatically — no global variables needed.

Scenario vs Scenario Outline

Scenario runs once with fixed hardcoded values. Scenario Outline runs multiple times — once per row in the Examples table. One Scenario Outline can cover valid login, invalid credentials, and empty fields without writing three separate scenarios.

What does Background do?

Background defines steps that run automatically before every Scenario in a feature file. Use it for common setup like "Given I navigate to the login page" so you do not repeat the same Given step at the top of every scenario.

Why POM with BDD?

Step definitions call page methods (login_page.click_submit()) rather than repeating locator strings. When a locator changes — which happens constantly in real projects — you fix it in one class and all scenarios keep working without touching any step file.

How are screenshots captured on failure?

pytest_bdd_step_error fires automatically when any step fails. Inside it, request.getfixturevalue('driver') retrieves the browser, save_screenshot() captures it with a timestamped name, and allure.attach() embeds it in the report.

Python Selenium BDD — Revision Topics
  • pytest basics recap
  • Selenium locators quick reference
  • Gherkin keyword summary
  • @given / @when / @then usage
  • parsers.parse() syntax
  • conftest.py fixture scope
  • POM structure review
  • Allure CLI commands