RBCS Covid-19 response: Until further notice, all public training classes will be run virtually. Remote proctored certification exams are available (view details).
Back in the early days of computing, there was no such specific, separately identifiable activity known as “testing.” Developers debugged their code, and that was usually intertwined with some unit testing task. That didn’t work. My first job was as a programmer, and where I worked, this was exactly how we approached quality assurance. It was a quality disaster.
This approach by itself still doesn’t work. It does not work for those throwback, Neanderthal organizations that rely on this approach entirely. It does not work for those cutting-edge companies that think some fancy language or process or tool has solved the software quality problem at last. It does not work for anyone, unless we define “work” as “shift most costs of poor quality onto end users who are too stupid to know better or trapped in a monopolistic market without any real choice.” And those organizations that rely on stupid users or a monopoly position had better hope they are right.
With the widespread advent of independent test teams in the late 1980s and early 1990s, we saw improvements. I was working in an independent test lab in the late 1980s and as a test manager in the early 1990s, and we made great strides. However, we also saw the emergence of a new dysfunction, the “hurl it over the wall to the test guys and hold them responsible for delivered quality” mistake. Every now and then, we work with organizations that still suffer from this problem.
Let’s be clear. When quality matters—and shouldn’t it always—everyone must play a role. Good testing involves a series of quality assurance filters. Each team in the organization typically participates in and owns one or more of these filters.
Read this article → (PDF 229 kB)