All through our lives we get told by people you get out of anything that you undertake what you put in. How can it apply to me as a Tester or as an Engineer?
Well lets start with a rather less than subtle drawing, the above shows that if you put poop (in case my 4 year old son reads this one day) into something you will most probably get poop out. It doesn't matter what that task is, it directly effects the outcome.
How does this apply to me as a Tester? Lets look at a PBI with no COAs? If we took that into a sprint, chances are we will end up with a rubbish outcome, it most probably won't be what the Product Owner wanted and it probably would be littered with bugs, and the time taken to even develop and test that thing would have been far greater than it perhaps should have!
Lets flip it, what if we had a Product Backlog Item (PBI) with well defined, testable and understood Conditions Of Acceptance (COAs) the chances are that what would come out at the end of a sprint would be a well tested PBI that meets the Product Owners requirements.
This is why it is so so important to get well understood, clear concise requirements. Requirements that can be tested and are not open to interpretation. This is also where Behavour Driven Development style language (more on this in a later post, but for now read this here by our very own Oletha Lai) can be useful in ensuring that requirements are well understood by the team!
It can pretty much be applied to so many different things, that it's important to remember, next time someone wants to bring in a PBI for a sprint with no COAs, just remind them, that we will more than likely turn out rubbish as a result! Rubbish in = Rubbish out..... That is of course not to assume that by having well defined COAs that you'll definitely deliver an amazing PBI, but it's a step in the right direction!