DevelopsenseLogo

xMMwhy

Several years ago, I worked for a few weeks as a tester on a big retail project. The project was spectacularly mismanaged, already a year behind schedule by the time I arrived. Just before I left, the oft-revised target date slipped by another three months. Three months later, the project was deployed, then pulled out of production for another six months to be fixed. Project managers and a CIO, among … Read more

Confusion as an Oracle

A couple of weeks back, Sylvia Killinen (@skillinen on Twitter) tweeted: “Seems to me that much of #testing relies on noticing when one is confused rather than accepting it as Something Computer Programs Do.” That’s a beautiful observation, near and dear to my heart since 2007 at least. The night I read Sylvia’s tweet, I wanted to blog more on the subject, but sometimes blog posts go in a different … Read more

Testing: Difficult or Time-Consuming?

In my recent blog post, Testing Problems Are Test Results, I noted a question that we might ask about people’s perceptions of testing itself: Does someone perceive testing to be difficult or time-consuming? Who? What’s the basis for that perception? What assumptions underlie it? The answer to that question may provide important clues to the way people think about testing, which in turn influences the cost and value of testing. … Read more

The Cooking Detector

A heuristic is a fallible method for solving a problem or making a decision. “Heuristic” as an adjective means “something that helps us to learn”. In testing, an oracle is a heuristic principle or mechanism by which we recognize a problem. Some years ago, during a lunch break from the Rapid Software Testing class, a tester remarked that he was having a good time, but that he wanted to know … Read more

Testing Problems Are Test Results

I often do an exercise in the Rapid Software Testing class in which I ask people to catalog things that, for them, make testing harder or slower. Their lists fit a pattern I hear over and over from testers (you can see an example of the pattern in this recent question on Stack Exchange). Typical points include: I’m a tester working alone with several programmers (or one of a handful … Read more

Can You Test a Clock in a Sealed Box?

A while ago, James Bach and I did a transpection session. The object of the conversation was to think critically about the common trope that every test consists of at least an input and an expected result. We wanted to go deeper than that, and in the process we discovered a number of useful ideas. A test can be informed by an expectation, but oracles can also be developed on … Read more

I Reject His Argument: A Buffet of Logical Fallacies

Testing is about not being fooled, and being fooled often starts with fooling yourself. A while back on Twitter, I posted some of these little examples of problems in argumentation, most of which include some logical fallacy or another. It’s a fun game; add your own! I reject his argument because 73.154% of the time, he uses misleadingly precise data. I reject his argument because he’s appealing to authority, and … Read more

The Undefinition of “Done”

Recently a colleague noted that his Agile team was having trouble with the notion of done. “Sometimes it seems like the rest of the team doesn’t get it. The testers know that ‘done’ means tested. And if you ask the programmers, they’ll acknowledge that, yes, done means tested. Everyone is acting in good faith. But during the sprint planning meeting, we keep having to remind people to include time and … Read more

The Best Tour

Cem Kaner recently wrote a reply to my blog post Of Testing Tours and Dashboards. One way to address the best practice issue is to go back to the metaphor and ask “What would be the best tour of London?” That question should give rise to plenty of other questions. Are you touring for your own purposes, or in support of someone else’s interests? To what degree are other people … Read more

Common Languages Ain’t So Common

A friend told me about a payment system he worked on once. In the system models (and in the source code), the person sending notification of a pending payment was the payer. The person who got that notice was called the payee. That person could designate somone else—the recipient—to pick up the money. The transfer agent would credit the account of the recipient, and debit the account of the person … Read more