(We interrupt the previously-scheduled—and long—series on oracles for a public service announcement.) Over the last year James Bach and I have been refining our ideas about the relationships between testing and tools in Rapid Software Testing. The result is this paper. It’s not a short piece, because it’s not a light subject. Here’s the abstract: There are many wonderful ways tools can be used to help software testing. Yet, all … Read more
This article was originally published in the February 2015 edition of Testing Trapeze, an excellent online testing magazine produced by our testing friends in New Zealand. There are small edits here from the version I submitted. Once upon a time, before I was a tester, I worked in theatre. Throughout my career, I took on many roles—but maybe not in the way you’d immediately expect. In my early days, I … Read more
A New Agile Testing Ecosystem – EuroSTAR – Michael Bolton
Over the last several years, a set of ideas and activities have been dumped into a steamer trunk called Agile software development. Agile development has hit mainstream recognition, even though there is often uncertainty and turmoil around what “Agile development” means, in theory and in practice—and that uncertainty and turmoil affects Agile projects and the people in them.
Commenting on testing and checking, one correspondent responds: “To be honest, I don’t care what these types of verification are called be it automated checking or manual testing or ministry of John Cleese walks. What I would like to see is investment and respect being paid to testing as a profession rather than arguing with ourselves over semantics.” My very first job in software development was as a database programmer … Read more
Over the last two days, I’ve published the premises of the Rapid Software Testing classes and methodology, as developed by James Bach and me. The first set addresses the nature of Rapid Testing’s engagement with software development—an ambitious activity, performed by fallible humans for other fallible humans, under conditions of uncertainty and time pressure. The second set addresses the nature of testing as an investigative activity focused on understanding the … Read more
Yesterday I published the first three premises that underlie the Rapid Software Testing methodology developed and taught by James Bach and me. Today’s two are on the nature of “test” as an activity—a verb, rather than a noun—and the purpose of testing as we see it: understanding the product and imparting that understanding to our clients, with emphasis on problems that threaten the product’s value. 4. A test is an … Read more
In February of 2012, James Bach and I got together for a week of work one-on-one, face-to-face—something that happens all too rarely. We worked on a number of things, but the principal outcome was a statement of the premises on which Rapid Software Testing—our classes and our methodology—are based. In deference to Twitter-sized attention spans like mine, I’ll post the premises over the next few days. Here’s the preamble and … Read more
Accompanying slides can be found here: http://lets-test.com/wp-content/uploa…
Jerry Weinberg tells a story (yes, it’s me; I’m telling yet another Jerry Weinberg story) of meeting an old friend who looked distraught. “What’s the matter?” Jerry asked. The fellow replied, “Well, I’m kind of shellshocked. My wife just left me.” “Was that a surprise?” “Yes, it really was,” the fellow said. “I mean, we had had some problems, but I thought they were all settled.” Jerry paused for a … Read more
My colleague and friend Eric Jacobson, who recently (as I write) did a bang-up job on his first conference presentation at STAR West 2011, asks a question in response to this blog post from 2006. (I like it when people reflect on an issue for a few years.) Eric asks: You are suggesting it may not make sense for testers to give time-based estimates to their teams, but what about … Read more