This post is part of the Pride & Paradev series.
Should testers write the acceptance criteria?
Testers should write the acceptance criteria
The main benefit of having a tester write acceptance criteria is that they are more likely to be measurable and testable as whilst writing them the tester will be asking themselves: how will I be able to test this.
It also encourages a good working relationship between the product owner and tester which can come in very handy when conducting testing if there are issues with implementation, as they will have background knowledge of what was originally required.
Testers will also be able to think of unusual edge cases in the acceptance criteria which can be considered from the start.
There may not be a business analyst on your team and in this case it makes sense for a tester to take on the responsibility for writing the acceptance criteria, so that the programmers can focus on implementing them.
Testers shouldn’t write the acceptance criteria
Testers like to think of how things shouldn’t work more than how they should work. Sometimes testers will be more pedantic about the acceptance criteria and can get carried away with them – adding niche edge cases which might not be applicable to the real world, or just not a priority to the business, who is trying to get the thing out the door and delivering business value.3
More often than not a bandwidth limitation will stop a tester from writing acceptance for user stories. Working as a solo tester on an agile team, having to both write the acceptance criteria and test the acceptance criteria, often in multiple browsers and/or devices, can be a time consuming thing, so in this case it would be advisable to get someone else to focus on writing the acceptance criteria so that they can be properly tested.