An impressive article by Kara Swisher in the Washington Post includes this quote from French philosopher Paul Virilio: “When you invent the ship, you also invent the shipwreck; when you invent the plane, you also invent the plane crash; and when you invent electricity, you invent electrocution. Every technology carries its own negativity, which is invented at the same time as technical progress.” Paul Virilio, Philippe Petit, Sylvère Lotringer (1999). … Read more
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
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
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
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
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
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
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
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.
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