DevelopsenseLogo

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

Rapid Software Testing in Toronto, June 4-6

I don’t usually give upcoming events an entire blog post. I usually post upcoming events in the panel on the right. However, this one’s special. I’m presenting a three-day Rapid Software Testing class, organized by TASSQ in Toronto, June 4-6, 2018. Rapid Software Testing is focused on doing the fastest, least expensive testing that still completely fulfills testing’s mission: evaluating the product by learning about it through exploration and experimentation. … Read more

How Long Will the Testing Take?

Today yet another tester asked “When a client asks ‘How long will the testing take for our development project?’, how should I reply?” The simplest answer I can offer is this: if you’re testing as part of a development project, testing will take exactly as long as development will take. That’s because effective, efficient testing is not separate from development; it is woven into development. When we develop a software … 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

Very Short Blog Posts (34): Checking Inside Exploration

Some might believe that checking and exploratory work are antithetical. Not so. In our definition, checking is “the algorithmic process of operating and observing a product, applying decision rules to those observations, and reporting the outcome of those decision rules”. We might want to use some routine checks, but not all checks have to be rote. We can harness algorithms and tools to induce variation that can help us find … Read more

Very Short Blog Posts (33): Insufficient Information and Insufficient Time

Here’s a question I get from testers quite a lot: “What do I do when the developers give me something to test with insufficient information and time to test it?” Here’s my quick answer: test it. Here’s my practical answer: test it with whatever time and information you have available. (Testing is evaluating a product by learning about it through exploration and experimentation.) When your time is up, provide a … Read more

Four (and More) Questions for Testers to Ask

Testers investigate problems and risk. Other people manage the project, design the product, and write the code. As testers, we participate in that process, but in a special way and from a special perspective: it’s our primary job to anticipate, seek, and discover problems in products. It’s probably a good idea to clear up some possible ambiguity here. When I’m talking about a product, I’m talking about anything that some … Read more

Signing Off

Testers ask: “I’m often given a product to test, but not enough time to test it. How am I supposed to sign off on the release when I haven’t tested enough?” My reply goes like this: If you’re a tester, it seems profoundly odd to me that you are responsible for signing off on a release. The decision to release a product is a business decision, not a technical one. … Read more

Finding the Happy Path

In response to yesterday’s post on The Happy Path colleague and friend Albert Gareev raises an important issue: Until we sufficiently learned about the users, the product, and the environment, we have no idea what usage pattern is a “happy path” and what would be the “edge cases”. I agree with Albert. (See more of what he has to say here.) This points to a kind of paradox in testing … Read more