“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.

Read on »

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: Read on »

We’ve all come to a crossroads on a project.

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. Read on »