09May
INVEST Guidelines – Testable Criteria

In this sixth and final article, it is analyzed the meaning of T from INVEST mnemonic: Testable. When discussing this aspect, usually it comes down to analyze the acceptance criteria defined. This user story cannot be considered "Done" unless the acceptance criteria is satisfied. And the only way we know if it's satisfied is by verifying it through tests, but acceptance criteria is not test cases. Acceptance criteria answers the question, how will I know when I'm done with this user story? Test cases lists the steps needed to test the functionality. 

When writing acceptance criteria, individuals from three different disciplines are required, to collectively understand what should be tested and how. The product owner, the team members who will be doing the development, and the ones who will be doing the testing. All three must be in agreement on what needs to be done in order to satisfy the user story. Tests can be manual or automated (unit tests, integration tests), doesn’t matter at this point.

Acceptance criteria should be detailed enough to define when the user story is satisfied, yet not so detailed as to inhibit collaboration. And all agreements should also be captured in the user story. So, there are no misunderstandings if someone new is added to the team and ends up doing the work. The acceptance criteria are used to create the test plan, and it's a best practice to write the test plan before developing the code. It makes it very clear to the team what they need to do to move this user story to "Done". If the team knows exactly how the feature will be tested, they will know exactly how to implement it, which increases the team's productivity. A way to ensure the user's story is testable, is have the customer that submitted this user story tell the team how to test it. If the customer cannot describe how to test a feature, it means there's more discussion needed. If the test criteria are difficult to write, then there's a problem with the user story. 

When writing the test criteria be aware of descriptions that are not testable. Words must be exact. Words like "all" mean you never know when you're done testing.

Now when the user story is new and very large like an epic, fuzzy words can promote a conversation and negotiations. In this case, they would help the team and stakeholders, come to a single idea of what it means to be user friendly or clean. But they don't belong in that acceptance criteria, which you're going to be using to write your test plans. Now all these agreements that the team comes to, must be written in the user stories acceptance criteria in clear, concise, testable language. Also, what's essential to capture notes, assumptions, and agreements in the user story. Too much information in a description can lead to missing information and acceptance criteria. Here we see, customers should be restricted to more than five comments in a single day. Well that's something that should be in the test plan, but down here, logged in user should be able to submit comments on plant files relaying to their own experience. This doesn't bring that in and so it could be left out of the test plan. Ensure that the assumptions captured in the description are also reflected in the acceptance criteria. 

The "T" in the INVEST guidelines stands for Testable. Writing clear, testable acceptance criteria is crucial as it's the only way the team, product owner, and customer, can agree on when the user story is done.