Chapter 11 · Execution

Testing and Validation

7 min readBy Bob Churchill
Summary

Testing confirms improvements work through verification (building it right) and validation (building the right thing). Functional, integration, user acceptance, performance, and regression testing apply, alongside parallel operations, pilots, and simulation. Clear acceptance criteria and traceable test cases determine pass or fail, and process validation confirms the original problem is solved.

Key takeaways
  • Verification asks whether you built it right; validation asks whether you built the right thing, and both are necessary
  • Testing types include functional, integration, user acceptance, performance, and regression testing
  • Process improvement approaches include parallel operations, pilot testing, and simulation for risk-free experimentation
  • Every requirement needs at least one traceable test case, and acceptance criteria must be specific and measurable
  • Process validation compares before-and-after metrics to confirm the original problem is actually solved and sustainable

Before declaring victory, you need to know: Does it actually work? Testing and validation answer this question through systematic verification of your improvements.


Verification vs. Validation

These terms are often confused but mean different things:

ConceptQuestionFocus
VerificationAre we building it right?Did we follow the design?
ValidationDid we build the right thing?Does it solve the problem?
Process diagram
Rendering diagram…

Both are necessary:

  • Verification catches errors in execution
  • Validation catches errors in understanding

You can perfectly implement the wrong solution (passes verification, fails validation) or imperfectly implement the right solution (fails verification, might still meet needs).


Types of Testing

Functional Testing

Does each feature work as specified?

Approach:

  • Test each requirement independently
  • Verify expected outputs for given inputs
  • Check boundary conditions
  • Test error handling

Example:

RequirementTest CaseExpected Result
Orders over $5K need approvalSubmit $4,999 orderAuto-approved
Orders over $5K need approvalSubmit $5,001 orderRouted to manager
Orders over $5K need approvalSubmit $5,000 exactly??? (boundary—clarify requirement)

Integration Testing

Do the parts work together?

Process diagram
Rendering diagram…

Areas to test:

  • Data flows between systems
  • Handoffs between process steps
  • Timing and sequencing
  • Error handling across boundaries

User Acceptance Testing (UAT)

Do real users find it acceptable?

Key aspects:

  • Actual users test (not developers or analysts)
  • Real-world scenarios
  • Production-like environment
  • Final checkpoint before go-live

UAT success criteria should be:

  • Defined before testing begins
  • Agreed upon by stakeholders
  • Measurable and objective

Performance Testing

Does it work under real-world conditions?

Test TypeQuestionExample
Load testingCan it handle expected volume?Process 1,000 orders/hour
Stress testingWhat happens at breaking point?What if volume doubles?
Endurance testingDoes it work over time?Run for 48 hours continuously
Spike testingCan it handle sudden surges?Black Friday traffic

Regression Testing

Did improvements break something else?

When you change a process, other things might unexpectedly stop working. Regression testing verifies that existing functionality still works after changes.


Testing Approaches for Process Improvement

Parallel Operations

Run old and new processes simultaneously:

Process diagram
Rendering diagram…

When to use:

  • High-risk changes
  • Critical processes
  • Need confidence before cutover

Considerations:

  • Doubles workload temporarily
  • Need clear criteria for comparison
  • Must handle legitimate differences

Pilot Testing

Test with a subset before full rollout:

Pilot selection considerations:

  • Representative of full population
  • Willing participants
  • Ability to provide feedback
  • Manageable scope

Pilot success criteria:

  • Define what "works" means before starting
  • Include both functional and adoption metrics
  • Set clear decision points

Simulation

Test without affecting real operations:

"Simulation enables data-driven decision-making about which process modifications warrant investment and implementation."

Simulation benefits:

  • No risk to actual operations
  • Can test extreme scenarios
  • Repeatable experiments
  • Multiple configurations compared

Simulation limitations:

  • Only as good as the model
  • May miss real-world factors
  • Requires expertise to build and interpret

Creating Test Cases

From Requirements to Tests

Every requirement should have at least one test case:

Process diagram
Rendering diagram…

Test Case Template

ElementDescription
Test IDUnique identifier
RequirementWhat requirement is being tested
DescriptionWhat is being tested
PreconditionsSetup needed before test
StepsSpecific actions to take
Expected resultWhat should happen
Actual resultWhat did happen
StatusPass, Fail, Blocked
NotesAdditional observations

Example Test Case

Test ID: TC-042
Requirement: REQ-007 (Auto-approve orders under $1,000)

Description: Verify orders under threshold are automatically approved

Preconditions:
- Test user has order entry access
- No holds on test customer account
- Test product in stock

Steps:
1. Log in as test user
2. Create new order for test customer
3. Add product with total $999
4. Submit order
5. Check order status

Expected Result: Order status shows "Approved" without manual intervention

Actual Result: [To be completed during testing]
Status: [Pass/Fail]

Test Coverage

Ensure you test thoroughly:

Coverage TypeWhat It Means
Requirements coverageEvery requirement has tests
Happy pathNormal scenarios work
Error pathsErrors handled gracefully
Boundary conditionsEdge cases covered
Integration pointsConnections work
PerformanceMeets speed/volume needs

Acceptance Criteria

Clear acceptance criteria prevent arguments about whether testing passed.

Good Acceptance Criteria

Specific: "Response time under 2 seconds" not "fast enough"

Measurable: "Error rate below 1%" not "low errors"

Achievable: Based on realistic expectations

Relevant: Connected to actual business needs

Complete: Covers all important aspects

Example Acceptance Criteria

For an improved order processing system:

CategoryCriterionThreshold
FunctionalityAll requirements tested and passing100%
DefectsNo critical or high-severity defects0
DefectsMedium defects with workarounds≤ 5
PerformanceAverage processing time< 30 seconds
PerformancePeak capacity500 orders/hour
User acceptanceUAT sign-offAll key users
DocumentationUser guide completeYes
TrainingAll users trained100%

Handling Test Results

When Tests Pass

  • Document the results
  • Proceed to next phase or go-live
  • Archive test evidence
  • Celebrate (briefly)

When Tests Fail

Process diagram
Rendering diagram…

Failure analysis questions:

  • Is the test valid?
  • Is the requirement correct?
  • Is the design appropriate?
  • Was implementation faulty?
  • Is the environment set up correctly?

Defect Classification

SeverityDefinitionExampleResponse
CriticalSystem unusableCrashes on loginStop; fix immediately
HighMajor function brokenCan't submit ordersFix before go-live
MediumFeature impairedWorkaround existsPlan fix; go-live may proceed
LowMinor issueCosmetic defectFix when convenient

Validation in Process Improvement

Beyond system testing, validate that the improved process actually achieves its goals.

Process Validation Questions

  1. Does it solve the original problem?

    • Compare before and after metrics
    • Verify root causes are addressed
  2. Does it work in practice?

    • Observe actual operations
    • Gather user feedback
  3. Are stakeholders satisfied?

    • Customer/user satisfaction
    • Operator feedback
    • Management confidence
  4. Is it sustainable?

    • Can it be maintained?
    • Are controls in place?
    • Is documentation adequate?

Validation Example

Original problem: Claims processing takes 14 days average

Improvement goal: Reduce to 5 days

Validation:

  • Measured post-implementation average: 4.3 days ✓
  • Tracked for 4 weeks to confirm consistency ✓
  • Surveyed processors: 87% positive feedback ✓
  • Measured customer complaints: down 45% ✓
  • Reviewed with management: approved for full adoption ✓

Testing Checklist

Before declaring testing complete:

  • All requirements have test cases
  • Functional tests executed and passed
  • Integration points tested
  • User acceptance testing complete
  • Performance meets criteria
  • Regression testing shows no breaks
  • All critical/high defects resolved
  • Acceptance criteria met
  • Sign-offs obtained
  • Test results documented
  • Lessons learned captured

Want help applying testing and validation to your own operations? A free discovery call is the fastest way to find where to start.