DevelopsenseLogo

Coverage

Talking About Coverage

A while back I wrote a post on coverage. In fact, I’ve written a few posts about coverage, but I’m talking about this one. A question came up recently on LinkedIn that helped me to realize I had left out something important. In that post, referring to coverage as “the proportion of the product that has been tested”, I said A software product is not a static, tangible thing; it’s a … Read more

Testing Deep and Shallow (3): Determination

After almost a year of the blog lying fallow, it’s time to continue the series on Testing Deep and Shallow that begins here. (Shallow testing (not an insult!) is testing that has a chance of finding every easy bug. Deep testing maximizes the chance of finding every elusive bug that matters.) Premise 6 of Rapid Software Testing is about cost and value. “We commit to performing credible, cost-effective testing, and … Read more

Testing Deep and Shallow (2): “Shallow” is a feature, not an insult!

When we talk about deep and shallow testing in the Rapid Software Testing namespace, some people might assume that we mean “deep testing” is good and decent and honourable, and that we mean “shallow” to be an insult. But we don’t. “Shallow” is not an insult. Depth and shallowness are ways of talking about the thoroughness of testing, but they’re not assessments of its value. The value or quality or … Read more

Testing Deep and Shallow (1): Coverage

Many years ago, I went on a quest. “Coverage” seemed to be an important word in testing, but it began to occur to me that I had been thinking about it in a vague, hand-wavey kind of way. I sensed that I was not alone in that. I wanted to know what people meant by coverage. I wanted to know what I meant by coverage. In the Rapid Software Testing … Read more

To Go Deep, Start Shallow

Here are two questions that testers ask me pretty frequently: How can I show management the value of testing? How can I get more time to test? Let’s start with the second question first. Do you feel overwhelmed by the product space you’ve been assigned to cover relative to the time you’ve been given? Are you concerned that you won’t have enough time to find problems that matter? As testers, … Read more

Breaking the Test Case Addiction (Part 8)

Throughout this series, we’ve been looking at an an alternative to artifact-based approaches to performing and accounting for testing: an activity-based approach. Frieda, my coaching client, and I had been discussing how to manage testing without dependence on formalized, scripted, procedural test cases. Part of any approach to making work accountable is communication between a manager or test lead and the person who had done the work. In session-based test … Read more

Exploratory Testing on an API? (Part 4)

As promised, (at last!) here are some follow-up notes on previous installments in the series that starts here. Let’s revisit the original question: Do you perform any exploratory testing on APIs? How do you do it? To review: there’s a problem with the question. Asking about “exploratory testing” is a little like asking about “vegetarian cauliflower”, “carbon-based human beings”, or “metallic copper”. Testing is fundamentally exploratory. Testing is an attempt … Read more

Very Short Blog Posts (35): Make Things Visible

I hear a lot from testers who discover problems late in development, and who get grief for bringing them up. On one level, the complaints are baseless, like holding an investigate journalist responsible for a corrupt government. On the other hand, there’s a way for testers to anticipate bad news and reduce the surprises. Try producing a product coverage outline and a risk list. A product coverage outline is an … Read more