Very Short Blog Posts (37): “Testing slows down the project.”

I’ve had a long career in this silly business. All the way along, one of the sillier things that people have said is this: “Testing slows down the project.” This is roughly equivalent to saying that looking out the windshield and attending to the dashboard slows down the journey. Sometimes people say that discovering problems slows down the project, but that’s not true either. Discovering problems can dispel the illusion … 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 (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

Very Short Blog Posts (31): Ambiguous or Incomplete Requirements

This question came up the other day in a public forum, as it does every now and again: “Should you test against ambiguous/incomplete requirements?” My answer is Yes, you should. In fact, you must, because all requirements documents are to some degree ambiguous or incomplete. And in fact, all requirements are to some degree ambiguous and incomplete. And that is an important reason why we test: to help discover how … Read more

Very Short Blog Posts (30): Checking and Measuring Quality

This is an expansion of some recent tweets. Do automated tests (in the RST namespace, checks) measure the quality of your product, as people sometimes suggest? First, the check is automated; the test is not. You are performing a test, and you use a check—or many checks—inside the test. The machinery may press the buttons and return a bit, but that’s not the test. For it to be a test, … Read more

Very Short Blog Posts (29): Defective Detection Effectiveness

Managers are responsible for hiring testers, for training them, and for removing any obstacles that make testing harder or slower. Managers are also responsible for hiring developers and designers, and providing appropriate training when it’s needed. If there are problems in development, managers are responsible for helping the developers to address them. Managers are also responsible for the scope of the product, the budget, the staffing, and the schedule. As … Read more

Very Short Blog Posts (28): Users vs. Use Cases

As a tester, you’ve probably seen use cases, and they’ve probably informed some of the choices you make about how to test your product or service. (Maybe you’ve based test cases on use cases. I don’t find test cases a very helpful way of framing testing work, but that’s a topic for another post—or for further reading; see page 31. But I digress.) Have you ever noticed that people represented … Read more

Very Short Blog Posts (27): Saving Time

Instead of studying and learning from every bug, you can save a lot of time by counting and aggregating bug reports. That’s a good thing in its way, because if you don’t study and learn from every bug, you’ll need all the time you can get to deal with problems that seem to keep happening over and over again.

Very Short Blog Posts (26): You Don’t Need Acceptance Criteria to Test

You do not need acceptance criteria to test. Reporters do not need acceptance criteria to investigate and report stories; scientists do not need acceptance criteria to study and learn about things; and you do not need acceptance criteria to explore something, to experiment with it, to learn about it, or to provide a description of it. You could use explicit acceptance criteria as a focusing heuristic, to help direct your … Read more

Very Short Blog Posts (25): Testers Don’t Break the Software

Plenty of testers claim that they break the software. They don’t really do that, of course. Software doesn’t break; it simply does what it has been designed and coded to do, for better or for worse. Testers investigate systems, looking at what the system does; discovering and reporting on where and how the software is broken; identifying when the system will fail under load or stress. It might be a … Read more