Ask Marilyn
Sign In
Module 10

The Test Design Template

A comprehensive taxonomy for organizing your test suite. Use this template to ensure complete coverage and logical structure.

Blueprint-style template with organized test categories
The master blueprint for test organization

Dear Marilyn: I have been asked to create a test plan for a new application. Where do I even begin? There are so many things to test that I feel paralyzed.

— Paralyzed in Phoenix

Dear Paralyzed: The secret to comprehensive test coverage is not to think of everything at once, but to think systematically. I will give you a template that organizes tests into eight categories. Work through each category methodically, and you will have complete coverage without the paralysis.

The Eight Test Categories

#1Business Objects

Tests organized around the core entities of your system

Example Test Modules

CustomerInvoiceOrderProductAccount

Coverage Checklist

  • Create (with valid data)
  • Create (with invalid data)
  • Read/View (single item)
  • Read/List (multiple items)
  • Update (all fields)
  • +5 more...

#2Business Flows

End-to-end processes that span multiple business objects

Example Test Modules

Order-to-CashProcure-to-PayHire-to-RetireQuote-to-Order

Coverage Checklist

  • Happy path (complete flow)
  • Alternate paths (branches)
  • Exception handling
  • Cancellation at each stage
  • Timeout/expiration
  • +2 more...

#3Features

Specific functionality that cuts across objects

Example Test Modules

SearchExportImportReportingNotifications

Coverage Checklist

  • Basic functionality
  • Advanced options
  • Edge cases (empty, max)
  • Error handling
  • Performance under load

#4Interoperability

Integration with external systems and APIs

Example Test Modules

Payment GatewayEmail ServiceCRM IntegrationERP Sync

Coverage Checklist

  • Connection establishment
  • Data exchange (send)
  • Data exchange (receive)
  • Error handling (timeout)
  • Error handling (invalid data)
  • +2 more...

#5Data Handling

Data integrity, validation, and transformation

Example Test Modules

Data MigrationBulk ImportData CleanupArchive/Restore

Coverage Checklist

  • Valid data acceptance
  • Invalid data rejection
  • Boundary values
  • Special characters
  • Unicode/internationalization
  • +2 more...

#6Non-Functional

Performance, security, and reliability requirements

Example Test Modules

Load TestingStress TestingSecurity TestingAccessibility

Coverage Checklist

  • Response time (normal load)
  • Response time (peak load)
  • Concurrent users
  • Memory usage
  • Authentication/Authorization
  • +2 more...

#7User Interface

Visual and interaction testing

Example Test Modules

FormsNavigationResponsive DesignAccessibility

Coverage Checklist

  • Layout correctness
  • Cross-browser compatibility
  • Mobile responsiveness
  • Keyboard navigation
  • Screen reader compatibility
  • +2 more...

#8Security

Authentication, authorization, and data protection

Example Test Modules

LoginRole-Based AccessData EncryptionAudit Trail

Coverage Checklist

  • Valid credentials
  • Invalid credentials
  • Account lockout
  • Password policies
  • Session management
  • +2 more...

The Test Design Process

1

Inventory Business Objects

List every entity in your system: Customer, Order, Invoice, Product, etc. Each becomes a test module with CRUD coverage.

2

Map Business Flows

Identify end-to-end processes that span multiple objects. These become integration test modules.

3

Catalog Features

List cross-cutting features: search, export, notifications, etc. Each feature gets its own test module.

4

Identify Integrations

Document all external system connections. Each integration point needs send, receive, and error handling tests.

5

Define Non-Functional Requirements

Specify performance, security, and accessibility requirements. Create dedicated test modules for each.

6

Apply Coverage Checklists

For each test module, apply the relevant coverage checklist to ensure no scenarios are missed.

Example: E-Commerce Test Plan

E-Commerce Test Suite

├── Business Objects/

│ ├── Customer (CRUD, profile, preferences)

│ ├── Product (CRUD, inventory, pricing)

│ ├── Order (CRUD, status transitions)

│ ├── Cart (add, remove, update quantity)

│ └── Payment (methods, processing, refunds)

├── Business Flows/

│ ├── Browse-to-Buy (complete purchase)

│ ├── Return-and-Refund (full cycle)

│ └── Subscription-Renewal (recurring)

├── Features/

│ ├── Search (basic, advanced, filters)

│ ├── Recommendations (personalized)

│ └── Reviews (create, moderate, display)

├── Integrations/

│ ├── Payment-Gateway (Stripe, PayPal)

│ ├── Shipping-Provider (FedEx, UPS)

│ └── Email-Service (transactional)

├── Non-Functional/

│ ├── Performance (load, stress)

│ ├── Security (auth, data protection)

│ └── Accessibility (WCAG compliance)

└── UI/

├── Responsive (mobile, tablet, desktop)

└── Cross-Browser (Chrome, Firefox, Safari)

Concurrency Testing: The Lead Deputy Pattern

Dear Marilyn: Our application is used by multiple people simultaneously. How do we test what happens when two users try to edit the same record at the same time?

— Racing in Raleigh

Dear Racing: You have identified one of the trickiest areas of testing: concurrency. When multiple users (or processes) work on the same data simultaneously, race conditions can cause data loss, corruption, or unexpected behavior.

ABT supports a feature called "Lead Deputy" that allows testers to design tests simulating two or more users working concurrently. Since such tests require multiple machines (physical or virtual), it is best to dedicate separate test modules specifically for concurrency testing.

The Race Condition Problem

Classic scenario:

User A

1. Opens form (balance: $100)

2. Changes field

3. Saves form

→ Balance: $150

User B

1. Opens form (balance: $100)

2. Changes different field

3. Saves form

→ Balance: $100 (overwrites A!)

User B's save overwrote User A's changes because B still had the old version of the record. This is called a "lost update" problem.

Lead Deputy Test Structure

# Test Module: Concurrent_Invoice_Edit

# Requires: 2 machines (Lead + Deputy)

# LEAD actions (Machine 1)

login_as_user(user: "clerk_a")

open_invoice(id: "INV-001")

edit_amount(value: "$500")

signal_deputy(checkpoint: "ready_to_save")

wait_for_deputy(checkpoint: "deputy_saved")

click_save()

check_conflict_warning(expected: true)

# DEPUTY actions (Machine 2)

wait_for_lead(checkpoint: "ready_to_save")

login_as_user(user: "clerk_b")

open_invoice(id: "INV-001")

edit_notes(value: "Updated by B")

click_save()

signal_lead(checkpoint: "deputy_saved")

Common Concurrency Tests

  • Simultaneous edits to same record
  • One user deletes while another edits
  • Multiple users creating same unique item
  • Inventory updates during checkout

Infrastructure Requirements

  • Two or more test machines (physical or virtual)
  • Network connectivity between machines
  • Synchronized clocks for timing
  • Dedicated test modules for concurrency

Module Summary

  • Organize tests into 8 categories: Business Objects, Business Flows, Features, Interoperability, Data Handling, Non-Functional, UI, and Security.
  • Use coverage checklists to ensure no scenarios are missed within each category.
  • Follow the 6-step process: inventory objects, map flows, catalog features, identify integrations, define NFRs, apply checklists.
  • Use the Lead Deputy pattern to test concurrency scenarios with multiple users or processes working simultaneously.
  • The template provides structure without rigidity—adapt it to your specific application.

Congratulations!

You have completed all 10 modules of the ABT course. You now have a comprehensive understanding of Action-Based Testing methodology.

Download Cheat Sheet

Three-layer architecture, anti-patterns, test life-cycle, and decision tables