Blog: 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 attention toward specific things that matter to your clients; that’s fine. You might choose to use explicit acceptance criteria as claims, oracles that help you to recognize a problem that happens as you test; that’s fine too. But there are many other ways to identify problems; quality criteria may be tacit, not explicit; and you may discover many problems that explicit acceptance criteria don’t cover.

You don’t need acceptance criteria to decide whether something is acceptable or unacceptable. As a tester you don’t have decision-making authority over acceptability anyway. You might use acceptance criteria to inform your testing, and to identify threats to the value of the product. But you don’t need acceptance criteria to test.

Want to know more? Learn about Rapid Software Testing classes here.

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

  1. Nicolas Umiastowski says:

    Hi Michael,

    I would say that acceptance criteria are not useful for exploratory testing.

    Michael replies: I would say that acceptance criteria could be quite useful for testing, be it direct interaction with the product, interaction mediated by tools, or testing using the tactic of automated checking. (In fact, acceptance criteria as the basis for decision rules that can be applied algorithmically are essential for checking.)

    But if in the process there are automated acceptance tests before the exploratory testing sessions, I think it is good to have acceptance criteria :
    – We can automate the tests 🙂

    In the Rapid Software Testing namespace, we would say that we cannot automate the tests. A test is an instance of testing which by our definition cannot be automated. A test case is not testing; a test is a performance, not an artifact. We would say that we can automate checks, though.

    – When the PO can define some test scenarios (input/output) before the User Story is developed, I think it will limit potential rework after the story is tested.

    I suppose that we could evaluate a particular acceptance criterion, and if the product exhibits a problem fulfilling it, we could say so and provide immediate feedback. I don’t see how this leads you to conclude that it would “limit potential rework after the story is tested”, though.

    But I would appreciate to read your experience about that, because I also noticed that we could deliver a User Story even when acceptance criteria were not defined 🙂

    We don’t deliver user stories. We deliver software that is an attempt to fulfill some kind of business need, some aspects of which are expressed in a user story. Since products and projects can run into real trouble when we’re imprecise about what we mean, let’s try to speak and write precisely.

  2. […] to Buy, Download, or Do When Working Remotely – Alexandra Samuel(HBR) You Don’t Need Acceptance Criteria to Test – Michael Bolton(DevelopSense) Don’t Start With Automation – Jim […]

Leave a Reply

Your email address will not be published. Required fields are marked *