“Our testing leaves a lot to be desired,” the Project Manager shot an accusatory glance at the QA Manager. The QA Manager glared back. I was seated between them at the conference table, and felt trapped in the middle.
“What makes you say that?” I asked, shifting my chair so I could see both managers at once.
“The software stays in test for too long. Our ship dates just slip and slip,” the PM shook his head. “Testing takes too long!”
“I see,” I replied. “And why is it that the software stays in test so long?”
The QA Manager cocked his head expectantly, apparently curious about the PM’s answer too.
“The testers find too many bugs!” complained the PM.
One of the reasons some organizations spurn Exploratory Testing is the notion that “All Testing Should Be Repeatable.”
To this, I say: “Bah.”
Repeatability is an overrated attribute for testing. Repeating a given test for a specific purpose, like for regression testing, is one thing. But insisting all testing be repeatable is an unnecessary constraint that results in more expensive, less powerful testing. Consider: Continue reading
We’ve all come to a crossroads on a project.
Should we ship now or fix more bugs first?
Should I report this bug even though I cannot reliably reproduce it?
Should we change this feature or leave it as is?
Should we tell the executive stakeholders about the current instabilities or hope we can fix them before the problems escalate?
Should we hire this candidate or hope a better one comes along?
We choose one path over another, somehow. We ship, or not. We report the bug, or not. We change, or not. We hire, or not. Various factors may lead us to choose one path over another. Sometimes we choose a path based on what we seek: success for the project, value for the stakeholders, revenue for the company. Other times we choose the lesser of two evils. Instead of running toward a goal, we run away from fear, pain, guilt, or unpleasantness. Continue reading
Wonder why some people are adamant that Agile can’t work; won’t work; shouldn’t be tried; or is the work of the devil? I do. Continue reading
José Alejandro Betancur requested (in comments) that I make a PDF of my Agile Testing slides available. Here they are. For those of you who were hoping to follow along with the Google Video talk, you’ll be disappointed: this is the most up to date version of the slides, not the version I presented at Google. Of course, I think the latest version is an improvement, so I hope you’ll forgive me.
A question from my email archives:
“I’ve been researching Agile. It seems to me that Agile projects tolerate bad engineering, and then testing has to deal with the consequences. Care to comment?”
Ah, yes. The old “Agile is a license to hack” misconception. Continue reading
“What happens if that file is locked when the process tries to write to the file?”
“Um, I don’t know…”
“Do you think maybe we should find out?”
There’s an interesting conversation happening right now on the Agile Testing mail list under the heading “How many test cases?” The discussion centers around an interview question in which a candidate was asked to design test cases for a program that writes data to a file.
What’s particularly interesting to me about the conversation is how widely it is ranging. There are now comments on the thread about the role of testers, the nature of requirements, and the existence (or not) of specifications. All this from a simple question around the sort of test cases that might come from a given requirement. It’s almost as though testing is inextricably intertwined with the whole software development process.
Oh. Wait. It is. Continue reading
Flashback: Quality Week 2001
In 2001, I saw Kent Beck speak to a standing-room-only crowd at Quality Week, a conference for quality and testing professionals. Kent spent the first portion of his talk explaining how QA is a throwback to Tayloristic, Time-and-Motion, Scientific Management practices, and that XP teams just don’t need any of that. He went on to explain the XP practices, and how they are both disciplined and self-supporting.
Then he tried to step off the stage. What Kent didn’t realize is that he had a double time slot. The crowd wasn’t about to let him go after he’d just offended all they knew to be good and holy. He spent the next 45 minutes answering questions posed by extremely angry QA professionals.
The good news is that Kent survived the experience. Despite a few tense moments, the audience did not charge the podium after all. I must say that I was impressed with Kent’s courage and grace under fire.
The insights I gleaned from that talk may not have been exactly what Kent intended. It seemed to me that:
- XP teams still needed Test QA people.
- XP teams might not need Process QA people.
- Kent didn’t understand (or at least didn’t articulate) the difference between Test QA and Process QA; he seemed to paint all “QA” people with the same brush.
- I should learn more about this XP stuff.
Fast Forward to the Present Day Continue reading
People who have known me for a while have remarked that there’s less of me these days. They’re right. See for yourself: Continue reading
“We’re QAing it right now.”
Ow. That just makes me cringe. For the record, QA is a noun. Please don’t verbify it. It’s the verbifying that really gets to me.
There’s another reason that phrase bugs me. It’s an example of taking a perfectly good word, “test,” and substituting a high-falutin’ word instead. Continue reading