DevelopsenseLogo

Coverage

Boundaries Unbounded

This post started as a LinkedIn post, which got started as a comment replying to this poll: It’s depressing to see ideas about testing and risk reduced to dopey formulas that are great for softball “certification” exam questions, but terribly limited for investigating and revealing product and business risk. Here’s how we describe “boundary” in Rapid Software Testing: A means by which something is classified or filtered This means that … Read more

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 pure, and that we mean “shallow” to be an insult, based on some kind of moral judgement. But we don’t. “Shallow” is not an insult. It is a description. Depth and shallowness are ways of talking about the thoroughness of … 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