DevelopsenseLogo

We Have to Automate

A recent posting (apparently no longer available) on LinkedIn entitled “Why Is Automated Software Testing A Better Choice?”, prompted some discussion. (As usual, the question “better than what?” was begged.) Then came this comment from my friend Jon Hagar: “There are … environments where the team must automate, e.g. a fast embedded control system where computation cycle is 10ms.” You might be inclined to agree with Jon, and I might … Read more

Very Short Blog Posts (11): Passing Test Cases

Testing is not about making sure that test cases pass. It’s about using any means to find problems that harm or annoy people. Testing involves far more than checking to see that the program returns a functionally correct result from a calculation. Testing means putting something to the test, investigating and learning about it through experimentation, interaction, and challenge. Yes, tools may help in important ways, but the point is … Read more

The Pause

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

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