I would like to remind people involved in testing that—after an engaged brain—one of our most useful testing tools is… the pause. A pause is precisely the effect delivered by the application of four little words: Huh? Really? And? So? Each word prompts a pause, a little breathing space in which questions oriented towards critical thinking have time to come to mind. Wait…huh? Did I hear that properly? Does it … Read more
A plan is not a document. A plan is a set of ideas that may be represented by a document or by other kinds of artifacts. In Rapid Testing, we emphasize preparing your mind, your skills, and your tools, and sharpening them all as you go. We don’t reject planning, but we de-emphasize it in favour of preparation. We also recommend that you keep the artifacts that represent your plans … Read more
Imagine a software project. Imagine the things that you want to accomplish, the problems you might encounter, the workarounds you could apply, the accidents (both happy and sad) that might happen, the missteps you may take, the steps you can take to prevent them; all of the actions you can perform to manage the project. Now, make a detailed plan that takes all of your expectations into account. The more … Read more
People often suggest that “understanding the requirements” is an essential step before you can begin testing. This may be true for checking or formal testing—examining a product in a specific way, or to check specific facts. But understanding the requirements is not a necessary precursor to testing, which is learning about a product through experimentation (a larger activity which might include checking) and creating the conditions to make that activity … Read more
Another day has dawned on Planet Earth, so another tester has used LinkedIn to ask about the difference between severity and priority. The reason the tester is asking is, probably, that there’s a development project, and there’s probably a bug tracking system, and it probably contains fields for both severity and priority (and probably as numbers). The tester has probably been told to fill in each field as part of … Read more
Accompanying slides can be found here: http://lets-test.com/wp-content/uploa…
This conversation is fictitious, but it’s also representative of several chats that I’ve had with testers over the last few weeks. Tony, a tester friend, approached me recently, and told me that he was having trouble understanding heuristics and oracles. I have a heuristic approach for solving the problem of people not understanding a word: Give ’em a definition. So, I told him: A heuristic is a fallible method for … Read more
Jerry Weinberg tells a story (yes, it’s me; I’m telling yet another Jerry Weinberg story) of meeting an old friend who looked distraught. “What’s the matter?” Jerry asked. The fellow replied, “Well, I’m kind of shellshocked. My wife just left me.” “Was that a surprise?” “Yes, it really was,” the fellow said. “I mean, we had had some problems, but I thought they were all settled.” Jerry paused for a … Read more
Calculating a ratio of passing tests to failing tests is a relatively easy task. If it is used as a means of estimating the state of a development project, though, the ratio is invalid, irrelevant, and misleading. At best, if everyone ignores it entirely, it’s simply playing with numbers. Otherwise, producing a pass/fail ratio is irresponsible, unethical, and unprofessional. A passing test is no guarantee that the product is working … Read more