Rikard Edgren is a testing philosopher in Sweden. He independently develops his own ideas on testing (an example here), collaborates with his colleagues on The Test Eye, and critiques and builds on the work of other people in the community. He offered a comment to my recent post on test framing, and the comment deserves a post on its own. He said, I don’t think explicit framing is needed very … Read more
I regularly converse with people who say they want to introduce exploratory testing in their organization. They say that up until now, they’ve only used a scripted approach. I reply that exploratory testing is already going on all the time at your organization. It’s just that no one notices, perhaps because they call it “review”, or “designing scripts”, or “getting ready to test”, or “investigating a bug”, or “working around … Read more
Last week in the Netherlands, I presented a workshop on test framing, a skill that James Bach and I like to talk about. Test framing is the set of logical connections that structure, inform, and motivate a test. Testing is a process of composing, editing, narrating, and justifying a story with three parallel threads. There is a product element—the part of the story that describes product, how it works, how … Read more
Note: This post contains plagiarism: I’ve stolen some content from an earlier blog post, and from my comments on another. I beg the forgiveness of faithful and diligent readers. Recently I’ve had to deal with some complaints from people on Twitter who seem to have misinterpreted certain analogies. Worse than that, sometimes it seems as though they don’t understand why and how we use analogies at all. Here are some … Read more
On Twitter, Johan Jonasson reported today that he was about to attend a presentation called “Structured Testing vs Exploratory Testing”. This led to a few observations and comments that I’d like to collect here. Over the years, it’s been common for people in our community to mention exploratory testing, only to have someone reply, “Oh, so that’s like unstructured testing, right?” That’s a little like someone refer to a cadenza … Read more
In the last post, my LinkedIn correspondent provided a couple of reasons why she liked writing test cases, and why she thought it necessary to write them down in the early stages of the project. Then she gave a third reason: When I’m on a project and I am the only one who knows how to test something, then I can’t move on to something new. I’d still be testing … Read more
Over the years, LinkedIn seems to have replaced comp.software.testing as the prime repository for wooly thinking and poorly conceived questions about testing. Recently I was involved in a conversation with someone who, at least, seemed to be more articulate than most of the people on LinkedIn. Alas, I’ve since lost the thread, and after some searching I’ve been unable to find it. No matter: the points of the discussion are, … Read more
As a followup to “More of What Testers Find“, here are some more ideas inspired by James Bach’s blog post, What Testers Find. Today we’ll talk about risk. James noted that… Testers also find risks. We notice situations that seem likely to produce bugs. We notice behaviors of the product that look likely to go wrong in important ways, even if we haven’t yet seen that happen. Example: A web … Read more
Damn that James Bach, for publishing his ideas before I had a chance to publish his ideas! Now I’ll have to do even more work! A couple of weeks back, James introduced a few ideas to me about things that testers find in addition to bugs. He enumerated issues, artifacts, and curios. The other day I was delighted to find an elaboration of these ideas (to which he added risks … Read more
Today, someone on Twitter pointed to an interesting blog post by Alan Page of Microsoft. He says: “How do testers determine if a bug is a bug anyone would care about vs. a bug that directly impacts quality (or the customers perception of quality)? (or something in between?) Of course, testers should report anything that may annoy a user, but learning to differentiate between an ‘it could be better’ bug … Read more