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
Not too long ago, I had a conversation with Joe Colantonio. Joe asks questions that prompt answers about the nature of testing, accountability, and telling the testing story. Enjoy!
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
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
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
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
“Happy path testing” isn’t really testing at all. Following the “happy path” is a demonstration. Here’s the role demonstration plays in testing: it’s nice to know that your product can achieve the happy path before you start to test it. To the degree a demonstration is a test, it’s a very shallow test. If you’re building something new and non-trivial that matters to people, or that could harm people, there’s … Read more
Last week on Twitter, I posted this: “The testing is going well.” Does this mean the product is in good shape, or that we’re obtaining good coverage, or finding lots of bugs? “The testing is going badly.” The product is in good shape? Testing is blocked? We’re noting lots of bugs erroneously? — Michael Bolton (@michaelbolton) January 31, 2018 “The testing is going well.” Does this mean the product is … Read more
To a naïve manager who doesn’t understand testing very well, the visible manifestation of testing is a tester, sitting in front of a computer, banging on keys to operate a product, comparing output with a predicted result, and marking “pass” or “fail” on a spreadsheet. Therefore, thinks the manager: one way to make testing dramatically more efficient and effective is to automate the testing. Substitute the human tester for a … Read more
On November 21, 2017, I delivered a webinar as part of the regular Technobility Webinar Series presented by my friend and colleague Peter de Jager. The webinar was called “How To Get What You Want from Testing (for Managers)”, and you can find it here. Alas, we had only a one-hour slot, and there were plenty of questions afterwards. Each of the questions I received is potentially worthy of a … Read more