The Real Requirements

One of the reasons that software development and testing are screwed up is because people often name things carelessly. Jerry Weinberg was fond of pointing out that “floating point” was the kind of math where the decimal point stayed in the same place, where in “fixed point”, the decimal point moves around.  People talk about “serverless computing”, when they really mean “computing using someone else’s servers”. “No-code testing tools”… well, … Read more

Respect for Our Clients

For a long time, I’ve suggested that testing should focus on product problems that pose risk to the business. That remains true, but lately I’m thinking there’s another consideration. For instance: yesterday, I accepted an invitation for an online meeting from a potential client. The invitation contained a link to a Microsoft Teams meeting. (If you know where this is going, and find it too painful, just skip to the … Read more

Exact Instructions vs. Social Competence

An amusing video from a few years back has been making the rounds lately. Dad challenges the kids to write exact instructions to make a peanut butter and jelly sandwich, and Dad follows those instructions. The kids find the experience difficult and frustrating, because Dad interprets the “exact” instructions exactly—but differently from the way the kids intended. I’ll be here when you get back. Go ahead and watch it. Welcome … Read more

Testing without requirements

Testing without requirements – PractiTest guest webinar with Michael Bolton

Sometimes as testers we are asked to work on projects where requirements are either vague or even non-existent, in these cases we need to look for ways to define what to test and how should the system under test behave.

Main takeaways:
– Alternative places to look for requirements
– How to work with stakeholders in order to get the information needed to test the system
– Tips on managing projects where requirements are not clear

For additional webinars and resources:…

Four (and More) Questions for Testers to Ask

Testers investigate problems and risk. Other people manage the project, design the product, and write the code. As testers, we participate in that process, but in a special way and from a special perspective: it’s our primary job to anticipate, seek, and discover problems. We testers don’t prevent problems in the product; we don’t design, build, fix, or manage the product. We’re evaluating things that other people are bringing to … 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 (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

Very Short Blog Posts (5): Understanding the Requirements

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