DevelopsenseLogo

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.

Subscribe to the Newsletter

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

  1. 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.

    Reply

  4. acceptance criteria are useful to deliver a quality working product.

    Michael replies: We could say that, but I’d put that slightly differently: using acceptance criteria can be a useful heuristic to deliver a quality working product.

    That might sound nit-picky, but it’s important. In Rapid Software Testing, we try to speak and write that way to remind ourselves that whatever practice or tool or approach or technique we apply, it can work and it might fail. (Here’s more about heuristics.)

    For instance: weak acceptance criteria might not have the desired effect. Insufficient acceptance criteria might not result in a quality product. Framing things in terms of rejection criteria, or thinking in terms of a definition of not done might be even more useful, and so forth.

    Reply

Leave a Comment