CTFL-AT Testing Techniques in Agile: TDD, BDD, and Exploratory Testing

Parul Dhingra13+ Years ExperienceHire Me

Senior Quality Analyst

Updated: 1/25/2026

Agile development demands testing techniques that keep pace with rapid iteration and continuous delivery. The ISTQB CTFL-AT syllabus emphasizes several key testing approaches that enable teams to maintain quality while moving fast. This guide explores the essential testing techniques every Agile tester must master.

From developer-focused practices like Test-Driven Development to tester-led approaches like exploratory testing, understanding when and how to apply each technique is crucial for exam success and real-world effectiveness.

Test-Driven Development (TDD)

What is TDD?

Test-Driven Development is a developer practice where tests are written before the code that makes them pass. It follows a strict cycle known as Red-Green-Refactor.

The TDD Cycle

Step 1: Red (Write a Failing Test)

• Write a test for functionality that doesn't exist yet
• Run the test and watch it fail
• The failing test defines the expected behavior

Step 2: Green (Make the Test Pass)

• Write the minimum code to make the test pass
• Don't worry about elegant solutions yet
• Focus only on passing the test

Step 3: Refactor (Improve the Code)

• Clean up the code while keeping tests green
• Remove duplication
• Improve design and readability

   +---------+
   |   RED   | Write failing test
   +----+----+
        |
        v
   +---------+
   |  GREEN  | Write minimal code to pass
   +----+----+
        |
        v
   +---------+
   |REFACTOR | Clean up the code
   +----+----+
        |
        +------> (Repeat)

Benefits of TDD

TDD Example

Requirement: Create a function that calculates order total with 10% discount for orders over $100.

Step 1 - Red:

// Test (fails - function doesn't exist)
test('applies 10% discount for orders over $100', () => {
  expect(calculateTotal(120)).toBe(108);
});

Step 2 - Green:

// Minimal implementation
function calculateTotal(amount) {
  if (amount > 100) {
    return amount * 0.9;
  }
  return amount;
}

Step 3 - Refactor:

// Refactored with constants
const DISCOUNT_THRESHOLD = 100;
const DISCOUNT_RATE = 0.10;
 
function calculateTotal(amount) {
  if (amount > DISCOUNT_THRESHOLD) {
    return amount * (1 - DISCOUNT_RATE);
  }
  return amount;
}

Acceptance Test-Driven Development (ATDD)

What is ATDD?

ATDD extends TDD to the business level. The team collaboratively defines acceptance tests before implementation, using these tests to guide development.

The ATDD Process

1. Discuss

• Team discusses the user story
• Product owner explains business value
• Developer considers implementation
• Tester identifies test scenarios

2. Distill

• Extract concrete examples
• Define acceptance criteria
• Create executable specifications
• Agree on edge cases

3. Develop

• Implement feature to pass acceptance tests
• Use TDD for unit-level implementation
• Integrate and test continuously

4. Demo

• Show working feature to stakeholders
• Validate acceptance tests pass
• Gather feedback for refinement

ATDD vs TDD Comparison

ATDD Example

User Story: As a customer, I want to receive free shipping on orders over $50.

Acceptance Tests (defined before development):

• Order of $49.99 has standard shipping charge
• Order of $50.00 has free shipping
• Order of $50.01 has free shipping
• Shipping type displays correctly on checkout

Behavior-Driven Development (BDD)

What is BDD?

BDD uses natural language to describe system behavior through examples. It bridges the communication gap between technical and non-technical team members.

Gherkin Syntax

BDD specifications typically use Gherkin syntax:

Feature: Shopping Cart
  As a customer
  I want to manage items in my cart
  So that I can purchase products I want
 
  Background:
    Given I am logged in as a customer
    And the cart is empty
 
  Scenario: Add item to cart
    When I add "Laptop" priced at $999 to cart
    Then the cart should contain 1 item
    And the cart total should be $999
 
  Scenario: Remove item from cart
    Given the cart contains "Laptop" priced at $999
    When I remove "Laptop" from cart
    Then the cart should be empty
    And the cart total should be $0
 
  Scenario Outline: Quantity discounts
    When I add <quantity> of "Widget" to cart
    Then the discount should be <discount>%
 
    Examples:
      | quantity | discount |
      | 1        | 0        |
      | 5        | 10       |
      | 10       | 20       |

BDD Keywords

BDD Tools

Benefits of BDD

• Shared understanding: Everyone reads the same specs
• Living documentation: Tests document behavior
• Collaboration: Three amigos create scenarios together
• Business focus: Features described in business terms
• Test automation: Specifications become executable tests

Exploratory Testing in Agile

What is Exploratory Testing?

Exploratory testing combines test design and execution simultaneously. The tester learns about the system while testing, using insights to guide further exploration.

Key Characteristics

When to Use Exploratory Testing

Ideal Situations:

• New features needing initial exploration
• Risk areas requiring deep investigation
• Usability and user experience validation
• Areas where scripted tests may miss issues
• Time-constrained testing situations
• Integration point validation

Less Suitable:

• Compliance/regulatory testing requiring documentation
• Performance testing requiring precise measurement
• Tests that must be repeated identically

Exploratory Testing Techniques

Charter-Based Exploration: Define a mission statement guiding the session:

Explore [target area]
With [resources/techniques]
To discover [information sought]

Example Charter:

Explore the checkout process
With invalid payment methods
To discover error handling issues

Touring Metaphor:

• Feature Tour: Visit every feature
• Complexity Tour: Focus on complex areas
• Claims Tour: Verify marketing claims
• Variability Tour: Try different configurations
• User Tour: Follow typical user journeys

Session-Based Test Management

What is SBTM?

Session-Based Test Management (SBTM) structures exploratory testing through time-boxed sessions with defined charters and documented results.

Session Structure

Session Sheet Contents

Session Information:

• Session ID and date
• Tester name
• Charter/mission
• Time box duration

Session Metrics:

• Time on testing vs. setup vs. investigation
• Number of issues found
• Coverage areas explored

Results:

• Bugs found (brief descriptions)
• Questions raised
• Areas needing more testing
• Risks identified

Debriefing Sessions

After each session, conduct a debrief:

Questions to Answer:

• What did you learn?
• What issues did you find?
• What areas need more testing?
• What risks emerged?
• Any impediments faced?

The Test Automation Pyramid

Understanding the Pyramid

The test automation pyramid guides automation strategy:

            /\
           /  \
          / UI \
         /------\
        /  API   \
       /----------\
      /   UNIT     \
     /--------------\

Pyramid Layers

Why This Shape?

Unit Tests (Base - Many):

• Fastest execution
• Lowest maintenance cost
• Most stable
• Quick feedback
• Run on every commit

API Tests (Middle - Medium):

• Test integration points
• Faster than UI tests
• More stable than UI tests
• Validate business logic

UI Tests (Top - Few):

• Slowest execution
• Highest maintenance cost
• Most fragile
• Test end-to-end flows
• Focus on critical paths

Anti-Patterns

Ice Cream Cone (Inverted Pyramid):

• Too many UI tests
• Few unit tests
• Slow feedback
• High maintenance

Cupcake (No Base):

• No unit tests
• Some integration tests
• Unstable foundation
• Hard to diagnose failures

Continuous Integration Testing

CI/CD Pipeline Testing

Automated tests run at different pipeline stages:

Commit Stage:

• Unit tests (all)
• Static analysis
• Fast feedback (< 10 minutes)

Integration Stage:

• API tests
• Integration tests
• Component tests

Acceptance Stage:

• UI tests (critical paths)
• E2E scenarios
• Performance baselines

Fast Feedback Principles

Test Execution Strategy

Commit -> Unit Tests -> Build -> Integration Tests ->
    Deploy to Test -> Acceptance Tests -> Deploy to Staging

Regression Testing Strategies

Regression in Agile Context

With frequent releases, regression testing must be efficient:

Automation Priority:

• Automate stable, repeating tests
• Focus on critical business paths
• Cover areas frequently changing
• Validate integration points

Risk-Based Regression

Not all areas need equal regression coverage:

Regression Test Selection

When time is limited:

• Run smoke tests (critical path)
• Tests for changed areas
• Tests for areas impacted by changes
• High-risk area tests

Maintaining Regression Suites

• Remove obsolete tests
• Update tests with requirement changes
• Fix flaky tests immediately
• Review coverage regularly
• Refactor duplicate tests

Selecting the Right Technique

Technique Selection Matrix

Combining Techniques

Effective Agile testing combines multiple approaches:

Sprint Testing Strategy:

1. Before Development: ATDD to define acceptance tests
2. During Development: TDD for unit tests, BDD for behavior specs
3. After Development: Exploratory testing for discovery
4. Continuous: Automated regression in CI/CD

Balancing Scripted and Exploratory

Test Your Knowledge

Continue Your Learning

• CTFL-AT Complete Study Guide
• CTFL-AT Agile Testing Fundamentals
• CTFL-AT Practice Questions
• CTFL Test Analysis and Design

Frequently Asked Questions

Frequently Asked Questions (FAQs) / People Also Ask (PAA)