DevelopsenseLogo

Risk in the Wild

In several of our Rapid Software Testing classes, for the last four years at least, these three slides have part of our materials on risk: And then what do you know?! This happened. Here’s the link. And this happened too… Here’s the link to that. Don’t say we didn’t warn you.

Ask Me Anything with Michael Bolton

QA ATL 2020 Day 2.5http://www.qaatl.com From the YouTube description… Too often, conference sessions don’t allow enough time for questions and answers. For QA ATL, Michael Bolton will deliver a conference session that is nothing but questions and answers. Michael invites you to ask him anything about topics near and dear to him, including (but not limited to) developing test strategy, recognizing problems in products, thinking critically, analyzing risk, applying tools, … 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 (36): Positive, Negative, and Sympathetic Testing

In Rapid Software Testing, a “positive test” is one that honours every required and explicitly declared condition or factor for a desired outcome. A “negative test” is one that violates (or dishonours, disrespects, ignores, omits, undermines…) at least one required and explicitly declared condition. That said, we don’t talk very much about positive and negative testing. We do talk about “sympathetic testing“, a closely related idea named by Cem Kaner. … 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

Drop the Crutches

This post is adapted from a recent blast of tweets. You may find answers to some of your questions in the links; as usual, questions and comments are welcome. Update, 2017-01-07: In response to a couple of people asking, here’s how I’m thinking of “test case” for the purposes of this post: Test cases are formally structured, specific, proceduralized, explicit, documented, and largely confirmatory test ideas. And, often, excessively so. … Read more

The Honest Manual Writer Heuristic

Want a quick idea for a burst of activity that will reveal both bugs and opportunities for further exploration? Play “Honest Manual Writer”. Here’s how it works: imagine you’re the world’s most organized, most thorough, and—above all—most honest documentation writer. Your client has assigned you to write a user manual, including both reference and tutorial material, that describes the product or a particular feature of it. The catch is that, … 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

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