Memories of Founding AST

 I started in the industry as a programmer, on January 1st 1983. I had been hired away from my minimum wage job as a dogsbody and ostensible computer salesman at an office supply store in Fairfield, Iowa. The guy who hired me was an ex-kindergarten teacher named Dale Disharoon. He wanted someone cheap and trainable to help him write video games. I was perfect for that, because I already knew 6502 machine language. At the time I did not know about assembly language. I programmed by typing hex codes directly into memory. Dale showed me about assemblers and I felt like I was driving a race car.

I was 16, and recently dropped out of high school and become what is legally known as an "emancipated minor"; I had what I now would call a tester's personality: I enjoyed debate, puzzles, mathematics, and opportunities to say "that's not necessarily true"; I was biased against any idea held by a person in authority. I would have joined the military, except I was still too young, and anyway I didn't want to take orders. Unbeknownst to school and government authorities, I'd lived alone since being thrown out of my family home at 14. 

Dale taught me the basics of doing professional work. He would write the Atari and PC version of our games, and I would handle Apple II and Commodore 64. I once made a game fit into 16,384 bytes, but usually I had a luxuriant 240 thousand bytes to play with. So many bytes! Based on that experience, I was eventually hired as a test manager. I know: I had neither testing experience, nor management experience. But the guy who hired me wanted someone he could mentor, I think. Thus, I became the youngest manager in the R&D division at Apple Computer. It was the best thing ever to have happened to me, up to that point of my life. 

That's when I decided I was going to be good. I committed to a career in testing. That was 38 years ago. I found myself in a building with 400 testers. I assumed they knew what they were doing, yet, there was no curriculum for testers. There were testing books I could read, but I seemed to be the only guy reading them. Very soon I became more interested in finding out HOW to do testing than in actually doing it. All around me people were doing it, but it seemed none of them could explain what they were doing. I felt this stopped us from being true professionals. But as I immersed myself in research, while also learning how to be a manager, great forces were at work in the software industry. At the dawn of the 90's, I saw the first rumblings of what would become Agile. Everyone I knew was using an iterative and incremental approach to development. Waterfall was a joke, even then. But there was an ominous undercurrent, to it, whereby development groups didn't like having their work scrutinized by testers who were outside of their control. They concocted a plausible-sounding argument that testers would be more productive if they were "part of the team"; I objected then as I do now: this is nonsense.

Independent testers were already part of the team. But there were not under the THUMB of the development managers. Still, Apple decided to dissolve the testing department in 1990, and that also destroyed professional testing culture. Demoralized, I moved to Borland and took over debugger testing. Borland was locked in war with Microsoft to produce the best development environment, and it was winning. This was where I developed and experienced most of what I teach in my classes, today. The testers and developers worked closely together and respected each other-- even though we did not report to the same management chain. In the four years I worked there, I developed metrics and advanced test tools. I also began to codify my test methodology, which I now call Rapid Software Testing. Borland innovated because we were hungry, and managers encouraged it up and down the line. It's because of my experience at Borland that I know what
a highly productive team looks like.

Microsoft had only one option: they bought the team. That ended the war.  Throughout this period I was developing my ideas about risk-based testing and the use of
heuristics to guide testing. I was moving away from "test cases" as a way to think about testing, and moving toward an activity-centered approach. I was also discovering that automation was not a magic solution for testing. One of the most popular articles I ever wrote was Test Automation Snake Oil. I was also fighting the standards and certification people. I wrote "The Immaturity of the CMM"; and "Certification is Discrimination"; during this period. I joined-- and then subsequently resigned from-- every professional software engineering organization. I came to believe that they were all corrupt.

Another thread that was vital to the development of my ideas was meeting Jerry Weinberg, reading his books, and taking all his classes. Jerry was the first old man I had ever met that I wanted to BECOME (I am now almost as old as he was when I met him, and I feel like I've just about achieved that). Jerry was hard on me, at times, but he never tried to use his authority as a cudgel. He cured my chronic burnout. He taught me systems thinking. And he helped me make the transition from rules-based to heuristics-based work.

When I was invited to come to LAWST 1, I came thinking I would annoy everyone with my belief that GUI automation should be avoided. I was pleasantly surprised to find a roomful of people who were mostly in agreement about that! Turns out there were quite a few people who were unsatisfied with conventional wisdom. For me, the period from 1987 to 1997 was all about realizing how screwed up the testing industry was, and preparing myself to fix it. The next chapter would be about becoming an effective teacher.

Starting around 1995 I began to collaborate closely with Cem Kaner. In that year, we served on a committee to create the Certified Software Quality Engineer program for the ASQ-- and both of us resigned from it in protest of their low standards of scholarship. Our relationship grew through shared experiences and debate. Cem was anti-authoritarian. He had been a protester against the Vietnam way. He had an ambivalent and fraught relationship with power. This would have an impact on how he organized the AST. For instance, when Cem organized the first LAWST peer conference, in 1997, I was there. Cem said that LAWST did not belong to him, even though he called the meeting and named it, and we were all there because of him. He said he was not the leader; that this was a peer workshop (although he seemed to be in charge). We had a subject to discuss and it was not “his” meeting. Cem was the unelected leader of the community that formed around LAWST. He was a good leader in most ways. But sometimes his insistence that he was not leading got on my nerves. I like to analyze, challenge, teach, and speak out. Cem was the organizer and activist, between us. 

By 1999, it is fair to say that he was like an older brother to me. When I rage quit my job, that year, and started my own consultancy, Cem lent me the money to buy a laptop. I got my second big gig because Cem recommended me for it. At a dinner with Cem (and I think Doug Hoffman and Brian Marick), in November of 1999, we decided to declare the Context-Driven School of Testing. Some time not long after that Cem started musing about starting a testing association. The rest of us seemed to ignore him, for a simple reason, I think-- if he were serious about starting one he would just start it and the rest of the CDT community would go along with it.

In those days we had a clear vision of what excellent testing could be. Then Agile came along and muddied the waters. Later DevOps poisoned the waters. And today AI is vaporizing all the water. What I mean is: the nature and need for good testing is the same today as it has ever been, for responsible people and companies. But there is less and less need to behave responsibly. The narrative of "trust developers (now AI) to build things without any outsider checking to see if they work well"; has grown strong, at the expense of users, who are expected to tolerate bad software. I'm not saying that Agile, DevOps, and AI are all fake. They are not a scam. But their cultures all show contempt for people who doubt. Wishful thinking (literally wishful, in the case of vibe coding) is lauded. Testers, being professional doubters, are not popular with the kids. Our ideas about CDT clarified and deepened with the writing of Lessons Learned in Software Testing. After that, Cem began to get serious about starting a testing association.

Despite my closeness with Cem, I wasn't much involved with the logistics of starting the AST. I was interested in what the organization would actually do. But there was one thing that surprised me: Cem intended to start the organization but not guide it! His original bylaws were set up to make it pretty easy for a handful of people who were not CDT testers to take the organization in a different direction. I argued with Cem about this several times: Why start an organization to accomplish X and not give yourself the power of stewardship over it to be sure that it does actually work on X? Cem's response was almost martyr-like. He felt that if people got elected to the board who wanted to change the vision completely then that was just democracy in action. Several of us-- I believe Doug Hoffman was one-- eventually talked Cem around on that point and we modified the bylaws to at least enshrine the value that AST was explicitly CDT.

The AST was started with the hope to make a better world. It was started by a man who believed in the power of democracy and the rule of law to bring about a great society. But the lived history of the AST emphatically demonstrates that the value and meaning of the organizations we humans create cannot be enshrined in code. It must live in culture, which is rooted in our hearts, brains, and shared experiences and values. The AST is the people who choose to be involved with the AST. The leadership of the AST must wrestle with the reality of personal relationships and ethical dilemmas. This wrestling process is no side show, it's how every successful human enterprise works.