DevelopsenseLogo

Michael Bolton

Very Short Blog Posts (10): Planning and Preparation

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

Evaluating Testing: The Qualitative Way

Evaluating Testing: The Qualitative Way | Michael Bolton | STAREAST

For years, testers and managers alike have wrestled with the problem of evaluating software products and testing efforts, often using approaches derived from manufacturing, construction, and physical sciences. These approaches have been only partially successful because software products aren’t physical products. Rather, software is part of a complex web of relationships among programs, computing equipment, networks, and, most importantly, people.

Read more

Not-So-Great Expectations

In my teaching and consulting work, I often ask people how they recognize a problem, and they often offer “inconsistency with expectations” as one way to do it. I agree, but I also think we should be careful to think things through. A product that fulfills our expectations may not be satisfying, and a product that violates our expectations may be terrific. Several years ago, I bought a new computer … Read more

Your User Is Not You

The title of this post, “Your User Is Not You”, is cheerfully cribbed from a fellow named David Platt, who wrote a pointed and very funny book called Why Software Sucks…and What You Can Do About It. He also gave a terrific talk at SD West 2007, excerpts of which you can see here and here. Attending that talk was one of the highlights of that year for me. Today … Read more

Counting the Wagons

A member of Linked In asks if “a test case can have multiple scenarios”. The question and the comments (now unreachable via the original link) reinforce, for me, just how unhelpful the notion of the “test case” is. Since I was a tiny kid, I’ve watched trains go by—waiting at level crossings, dashing to the window of my Grade Three classroom, or being dragged by my mother’s grandchildren to the … Read more

Very Short Blog Posts (9): “Insufficient Requirements”

Some people say they “don’t have enough requirements to start testing,” or that the requirements are unclear or incomplete or contradictory or out of date. First, those people usually mean requirements documents; don’t confuse that with requirements, which may be explicit or tacit. There are plenty of sources of requirements-related information, and it’s a tester’s job to discover them and make inferences about them. Second, insufficient clarity about requirements is … Read more

Can You Hear The Alarm Bells?

Many people seem certain about what happened to cause the healthcare.gov fiasco. Stories are starting to trickle out, and eventually they’ll be an ocean of them. To anyone familiar with software development, especially in large organizations, these stories include familiar elements of character and plot. From those, it’s easy to extrapolate and fill in the details based on imagination and experience. We all know what happened. Well, we don’t. In … Read more

Very Short Blog Posts (8): Two Big Questions

Too often testing is focused on getting the right answers, rather than asking worthwhile questions and helping to get them answered. There are at least two overarching questions that a tester must ask. While looking directly at the product, at its customers, at the project, at the business, and at the relationships between them, the tester’s first question — and a question the tester must ask continuously, expansively, and tacitly … Read more

Very Short Blog Posts (7): Planning vs. Preparation

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

Very Short Blog Posts (6): Validating Assumptions

Some may say that the purpose of testing is to validate assumptions made by business analysts, designers, or developers. To me, that is at best a potential side effect of testing—but not the goal. If you want testing to reveal important problems in the product, do not focus on validating assumptions (to do so would be more like checking; testing may include some checking). To foster discovery, excellent testing—like excellent … Read more