The Why - Founding AST

In early 1997, Cem Kaner invited me to attend the first Los Altos Workshop on Software Testing (LAWST). Initially, I declined, thinking of myself as a software quality process specialist with little to offer a gathering of top software testing experts. Cem persisted, pointing out my testing experience exceeded that of many participants. I accepted, and I’m very glad I did. That decision—and the workshops that followed—became the catalyst for forming the Association for Software Testing (AST).

Professional Background Before LAWST

Before LAWST, my career spanned a broad spectrum of industries, company sizes, and technologies. I considered myself a quality engineer and manager for any type of digital hardware, software, and networks. My work ranged from hardware drivers, operating systems, and microcode to CPU chips, high-voltage network systems, and desktop publishing software. I worked in environments from seven-person startups to large military contractors and major FDA-regulated manufacturers.

After earning a BACS degree, I spent a decade at Hewlett-Packard in varied roles:

manufacturing engineer, developer, QA engineer, Visiting Instructor of Electrical Engineering at Howard University (after earning an MSEE), technical support engineer, and technical support manager. After completing my MSEE, I began an MBA, finishing it around the time I left HP for a series of startups. In eight startups over eight years, I built and managed engineering functions—everything except development and sales—before realizing I had effectively been consulting all along.

Teaching was another constant in my career. After completing my MBA, I spent ten years as an instructor for the University of San Francisco while working full time, teaching courses in
IT Management, Organizational Development, Finance for Manufacturing, and Statistics. I later taught at UC Santa Cruz, UC Berkeley Extension, and in corporate programs, and began
co-teaching software testing with Cem Kaner.

After LAWST started, I recognized that no two consulting engagements ever produced the same solution. Test plans and SDLC documents varied from one page to seventy-five pages.
Tools and techniques shifted with the situation. Without naming it yet, I was tailoring my work to the specific context—a mindset that would soon align with LAWST’s emerging
philosophy.

The LAWST Experience

LAWST workshops were invitation-only, peer-to-peer events that addressed unresolved questions in software testing. Participation required first-hand, practical experience. LAWST 1 examined how to automate GUI testing. The surprising consensus was that none of us had succeeded with the most popular tools—and none of us knew of anyone who had. Each participant had solved GUI testing challenges with custom, project-specific solutions.

Workshops were intentionally limited to fewer than twenty participants to maintain effective facilitation. Speculation, theories, or unsupported claims were not allowed (unless introduced as such.) Only concrete, experience-based accounts were accepted. Over sixteen LAWST workshops, presenters described successes or failures, and the group probed with 'why'; and 'how'; questions to uncover the reasons for the differences.

LAWST was part of a broader ecosystem of workshops, including WTST (Teaching Testing), WHOSE (Self-Education in Software Testing), and WHET (Heuristic and Exploratory Testing). Each had a topic leader, facilitator, and scribe, responsible for guiding focus, managing discussion, and capturing main points.

I attended more than fifty workshops across these series, keeping extensive personal notes. They were incomplete—gaps occurred when I was speaking, distracted, or too slow—and I requested they not be shared beyond participants to avoid misquoting or misattribution.

The Emergence of Context-Driven Testing (CDT)

Across LAWST and other workshops, we compared experiences and found no universal testing tools or techniques. Some worked in certain contexts, others in none at all. This repeated finding led us to label situations as, 'contexts'. Late in the LAWST series, we began describing our shared approach as Context-Driven Testing—selecting tools and techniques based on the unique demands of the situation. [Note: I doubt that we coined the phrase.]

To be an effective tester, you must understand many different methods of testing. If you only know one tool or one way of testing, you’ll tend to apply it everywhere. CDT was never a single method, but a principle: how to test depends entirely on context. CDT was a codification of ideas that hundreds of us developed over 10 years of workshops. (LAWST alone had about 100 different participants.)

From Workshops to a Professional Society

We wanted to share CDT beyond the workshop circle, so we wrote papers, presented at conferences, integrated it into courses, and published books. A professional society seemed like the next logical step—a way to reach a larger audience and foster debate across all schools of testing. The aim was a 'big tent'; where all approaches could be examined and valued in the right contexts.

Ultimately, a small group of practitioners and academics formed AST. While CDT was not explicitly in the founding charter, it was implicitly present and became explicit several years
later.

AST's Impact

The workshop model inspired CAST, enabling us to engage ten times more people in a single event, and BBST, which scaled CDT-based education to much larger audiences. While other
projects came and went, CAST and BBST remain central to AST’s mission of advancing testing as a skilled discipline.