A colleague wrote to me recently and asked about a problem that he’s had in hiring. He says… The kind of test engineers we’re looking for are ones that can think their way around a system and look for all the ways that things can go wrong (pretty standard, so far), and then code up a tool or system that can automatically verify that those things haven’t gone wrong (a … Read more
The Agile community (to the degree that such a thing exists at all; it’s a little like talking about “the software industry”) appears to me to be really confused about what “done” means. Whatever “done” means, it’s subject to the Relative Rule. I coined the Relative Rule, inspired by Jerry Weinberg‘s definition of quality (“quality is value to some person(s)”). The Relative Rule goes like this: For any abstract X, … Read more
There’s a mildly rollicking little discussion going on the in the Software Testing Club at the moment, in which Rob Lambert observes, “I’ve seen a couple of conversations recently where people are talking about red, green and yellow box testing.” Rob then asks “There’s the obvious black and white. How many more are there?” (For what it’s worth, I’ve already made some comments about a related question here.) At one … Read more
I have four or five blog posts in the hopper, each almost ready to go. I’m working on a whole book and a chapter of another one, and I’m on a deadline that I’m about to blow. The kids are still out of school, and I really should be cooking dinner right now. And yet… As I write, one of the best testers that I know is looking for work. … Read more
Eric Jacobson has a problem, which he thoughtfully relates on his thoughtful blog in a post called “How Can I Tell Users What Testers Did?”. In this post, I’ll try to answer his question, so you might want to read his original post for context. I see something interesting here: Eric tells a clear story to relate to his readers some problem that he’s having with explaining his work to … Read more
In a recent blog post, Rahul Verma suggests that all testing is confirmatory. First, I applaud his writing of an exploratory essay. I also welcome and appreciate critique of the testing vs. checking idea. I don’t agree with his conclusions, but maybe in the long run we can work something out. In mythology, there was a fellow called Procrustes, an ironmonger. He had a iron bed which he claimed fit … Read more
This is a followup to an earlier post, Questions from Listeners (2): Is Unit Testing Automated? The original question was Unit testing is automated. When functional, integration, and system test cannot be automated, how to handle regression testing without exploding the manual test with each iteration? Now I’ll deal with the second part of the question. Part One: What Do We Really Mean By “Automation”? Some people believe that “automation” … Read more
Gojko Adzic recently wrote a blog post called Let’s Change the Tune on some of our approaches in agile development. In changing the tune, some of the current words won’t fit so well, so he proposes (for example), “Specifying Collaboratively instead of test first or writing acceptance tests”. I have one more: I think we should change the label “acceptance tests”. “Acceptance tests” are given a central role in agile … Read more
In response to my previous blog post “Another Silly Quantitative Model”, Greg writes: In my current project, the product owner has assumed the risk of any financial losses stemming from bugs in our software. He wants to release the product to customers, but he is of course nervous. How do you propose he should best go about deciding when to release? How should he reason about the risks, short of … Read more
John D. Cook recently issued a blog post, How many errors are left to find?, in which he introduces yet another silly quantitative model for estimating the number of bugs left in a program. The Lincoln Index, as Mr. Cook refers to it here, was used as a model for evaluating typographical errors, and was based on a method for estimating the population of a given species of animal. There … Read more