Search this site
Embedded Files
Scrum Pattern Group
  • Scrum PLoP
    • Scrum Tulip PLoP 2021 - Enkhuizen Netherlands
    • Scrum PLoP 2019
    • Scrum PLoP 2018, Quinta da Pacheca, Portugal
    • ScrumPLoP 2017, Quinta da Pacheca, Portugal
    • ScrumPLoP 2016, Porto, Portugal
    • ScrumPLoP 2015, Porto, Portugal
    • ScrumPLoP 2014, Helsingør, Denmark
    • ScrumPLoP 2013, Helsingør, Denmark
    • ScrumPLoP 2012, Helsingør, Denmark
    • ScrumPLoP 2011, Helsingør, Denmark
    • ScrumPLoP 2010, Stora Nyteboda, Sweden
  • Original Org Patterns Site
    • Organizational Patterns of Agile Software Development
      • Book Outline
        • Preface
        • History and Introduction
          • An Overview of Patterns and Organizational Patterns
          • What Are Patterns?
          • What Are Pattern Languages?
          • Organizational Pattern Languages
          • How the Patterns Came to Us
          • Gathering Organizational Data
          • Creating Sequences
          • History and Related Work
          • Introspection and Analysis of Organizations
          • Shortcomings of State of the Art
          • Analyzing Roles and Relationships
          • How to Use this Book
          • Reading the Patterns
          • Applying the Patterns
          • Updating the Patterns
          • Who Should Use This Book?
          • Size the Organization
          • The CRC-Card Methodology
        • The Pattern Languages
        • Organizational Design Patterns
          • Project Management Pattern Language
          • Community of Trust
          • Size the Schedule
          • Get On With It
          • Named Stable Bases
          • Incremental Integration
          • Private World
          • Build Prototypes
          • Take No Small Slips
          • Completion Headroom
          • Work Split
          • Recommitment Meeting
          • Work Queue
          • Informal Labor Plan
          • Development Episode
          • Implied Requirements
          • Developer Controls Process
          • Work Flows Inward
          • Programming Episode
          • Someone Always Makes Progress
          • Team per Task
          • Sacrifice One Person
          • Day Care
          • Mercenary Analyst
          • Interrupts Unjam Blocking
          • Don't Interrupt an Interrupt'
          • Piecemeal Growth Pattern Language
          • Size the Organization
          • Phasing It In
          • Apprenticeship
          • Solo Virtuoso
          • Engage Customers
          • Surrogate Customer
          • Scenarios Define Problem
          • Firewalls
          • Gatekeeper
          • Self-Selecting Team
          • Unity of Purpose
          • Team Pride
          • Skunkworks
          • Patron Role
          • Diverse Groups
          • Public Character
          • Matron Role
          • Holistic Diversity
          • Legend Role
          • Wise Fool
          • Domain Expertise in Roles
          • Subsystem by Skill
          • Moderate Truck Number
          • Compensate Success
          • Failed Project Wake
          • Developing in Pairs
          • Developing in Pairs
          • Engage Quality Assurance
          • Application Design is Bounded by Test Design
          • Group Validation
        • Organization Construction Patterns
          • Organizational Style Pattern Language
          • Few Roles
          • Producer Roles
          • Producers in the Middle
          • Stable Roles
          • Divide and Conquer
          • Conway's Law
          • Organization Follows Location
          • Organization Follows Market
          • Face-to-Face Before Working Remotely
          • Form Follows Function
          • Shaping Circulation Realms
          • Distribute Work Evenly
          • Responsibilities Engage
          • Hallway Chatter
          • Decouple Stages
          • Hub Spoke and Rim
          • Move Responsibilities
          • Upside-Down Matrix Management
          • The Water Cooler
          • Three to Seven Helpers per Role
          • Coupling Decreases Latency
          • People and Code Pattern Language
          • Architect Controls Product
          • Architecture Team
          • Lock 'Em Up Together
          • Smoke Filled Room
          • Stand Up Meeting
          • Deploy Along the Grain
          • Architect Also Implements
          • Generics and Specifics
          • Standards Linking Locations
          • Code Ownership
          • Feature Assignment
          • Variation Behind Interface
          • Private Versioning
          • Loose Interfaces
          • Subclass Per Team
          • Hierarchy of Factories
          • Parser Builder
        • Foundations and History
          • Organizational Principles
          • Priming the Organization for Change
          • Dissonance Precedes Resolution
          • Team Burnout
          • Stability and Crisis Management
          • The Open-Closed Principle of Teams
          • Team Building
          • Building on the Solid Core
          • Piecemeal Growth
          • Some General Rules
          • Make Love Not War
          • Organizational Patterns are Inspiration Rather Than Prescription
          • It Depends on Your Role in Your Organization
          • It Depends on the Context of the Organization
          • Organizational Patterns are Used by Groups Rather Than Individuals
          • People are Less Predictable than Code
          • The Role of Management
          • Anthropological Foundations
          • Patterns in Anthropology
          • Beyond Process to Structure and Values
          • Roles and Communication
          • Social Network Analysis
          • Distilling the Patterns
          • CRC Cards and Roles
          • Social Network Theory Foundations
          • Scatterplots and Patterns
        • Case Studies
          • Borland QuattroPro for Windows
          • A Hyperproductive Telecommunications Development Team
      • Appendices
        • Summary Patlets
        • Organization Book Patlets
        • Bibliography
        • Photo Credits
      • Mysteriously Missing
      • Supporting Pages
        • Common Pattern Language
        • Organizational Patterns
        • Diversity of Membership
  • Original Scrum Patterns Site Archive
    • Scrum as Organizational Patterns
    • Scrum Patterns Summary
    • Software Scrum Patterns
    • First-Level Scrum Patterns
  • The ScrumPLoP Mission
  • What is a PLoP?
Scrum Pattern Group

Engage Quality Assurance

FSA (Farm Security Administration) supervisor and farmer-client examining quality of silage from trench silo. Sheridan County, Kansas

...you have a development organization mature enough that roles have been congealed and a customer has been engaged (EngageCustomers). You need some filter between the two to both facilitate and regulate interactions between them.

✥ ✥ ✥

Customer engagement is a key element of quality assurance. Though developers feel they get everything right, a good dose of customer reality helps bring the perspective that perfect software is hard.

Too many organizations defer quality until "later" or equate quality assurance with the late activity of testing. Yet success depends on high quality, and early feedback is important to address fundamental quality problems.

It's important to do testing, and most developers do their own testing. But individuals easily get blindsided by their own design thinking in terms of what needs to be tested. And they may use testing as their quality criterion; yet, you can't test quality into a product: you can only build a product and test its quality.

Therefore:

Make QA a central role. Couple it tightly to development as soon as development has something to test. Test plan development can proceed in parallel with coding, but Developers declare the system ready for test. 

Quality Assurance (QA) was central to the development of Borland's Quattro Pro for Windows: 

The QA organization should be outside the context of the project: the planning and reporting of tests should not be accountable to the development organization. The development organization develops a sense of accountability for delivering quality product, since their own view of their reputation is linked to minimizing the bugs that "those people in QA" find. 

QA should be engaged with marketing to understand the needs and challenges a system will face. 

QA people have skills and perspectives that allow them to view customer needs from a perspective that may not be reflected in requirements or other articulations of needs. A good example is security companies that develop security software utilities for commercial operating; their own probing of the operating system often uncovers security holes, and then they work with the vendor to fix the problems. 

✥ ✥ ✥

Having engaged QA, the project will be ready to approach the Customer. With QA and the Customer engaged, the quality assurance process can be put in place (use cases gathered, etc.). 

There are at least two reasons for making QA a separate organization from that holding Developers' allegiance. First, test development shouldn't be blind-sided by the Developer perspective. If both the Developer and QA perform their own tests, testing becomes a double-blind experiment with the software as a subject. Second, QA should be put outside the domain of influence by the development organization in the interest of objectivity. This is an obvious pattern in QPW. 

Indeed, EngageQualityAssurance requires a separate QA organization. This is in contrast to the ideals espoused in Extreme Programming. XP advocates extensive unit testing, but in the words of Kent Beck, "documentation, design, formal review, separate QA; it's all a waste of our time." [BibRef-Waters2000] This may be a reaction to organizations that have a separate QA organization, but do not engage it. That's a recipe for disaster: you have the overhead of a separate organization, but not the benefits. In order for a separate QA organization to be effective, it must have frequent and positive interaction with development. 

Note that quality assurance should be engaged early in the project; by the time testing starts it is too late to build the trust needed for quality assurance to happen smoothly. This is spelled out in GetInvolvedEarly [BibRef-Delano1998]. It is not just the developers' responsibility to engage the testers; the testers must reach out to the developers as well (see DesignersAreOurFriends [BibRef-Delano1998].) 

See also ApplicationDesignIsBoundedByTestDesign.

Copyright © 2026 The Scrum Patterns Group
Report abuse
Page details
Page updated
Report abuse