Acceptance Tests, who is responsible?

I have been thinking about what do I plan to do differently as a tester in 2012.  I have come to the conclusion that I am going to promote acceptance tests.  Over the past  few years I have seen numerous stories flowing through the software development life cycle without an inkling of testing thought.  I contend that for a story to be successful we must have some strategy as to how to test it. 

The objective is to have acceptance tests defined before a story is put into the backlog.  In the Kanban world perhaps backlog is not the correct place, but in the defined or ready state a story should have acceptance tests.

So who is responsible for this testing thought?

The quick and obvious answer is the tester.  I believe the tester does carry much of the burden.  I think testers should be the leaders in defining acceptance tests.  A tester should not be a Buford Pusser, but we should halt stories that do not have acceptance tests and help lead the team to define the tests.  There is nothing like trying to find a product person or a developer just before a release to understand what the heck a story meant.

Does the developer have a role in defining acceptance tests? 

My opinion is absolutely.  How can a developer write the best code possible if they do not know what the feature should do.  Some serious thought should go into how a developer should prove to the stakeholders that she did a fantastic job writing the code.

Does a product manager have a role in defining acceptance tests?

No, because their only job is to put the stories into the queue.  Just kidding!  Absolutely the product manager has a stake in the game.  The product manager needs to know exactly what it means for a feature to be "done".  In fact the product owner has the most insight on how to define if a feature has been developed to expectations.  Notice I inserted expectations instead of the evil word, requirements.  I will save that for another post, but if a story is well drafted and coupled with great acceptance tests, my opinion is that detailed requirements may not be necessary!

In the software world you often hear the term the business team.  These are the dreamers who come up with the ideas.  Should they care about acceptance tests?  Absolutely!  How do they know their dream has been realized.  I would contend that as a concept is being visualized the business should also be dreaming about testing.

Does management care about acceptance tests?  This is a tough one, but I conclude the answer is a resounding, Yes!  Knowing that the team has defined a minimal set of success criteria should indicate some level of efficiency.  Isn't management all about quick road maps to success?

At this point in the little ramble I have two additional thoughts.  One is that I would conclude that EVERYONE is responsible for acceptance tests.  Two is that I never defined what an acceptance test is.

So let me conclude with my simple definition of acceptance tests.  Acceptance tests are the proof that teams are getting shit done, GSD and that expectations are being met.

So testers GSD by providing evidence of success in the form of acceptance tests!