As I said before, I have not yet made up my mind about the CMMI…
At the Agile Open Europe conference I participated in a discussion on the subject of acceptance testing. One of the open questions was how to match "traditional" customers with the agile idea of delivering a potentially shippable product every few weeks.
Different Types of Customers
While some customers are delighted to receive a new release every month, there are others that don't even want to see or know about any of the intermediate releases. Some customers simply insist on working the traditional way. They hire a team of testers for a couple of weeks before the intended release date, and they require the development team to deliver one release candidate, just in time for the test period, and the team should then stop working on the system until the test team has finished testing.
After fifteen minutes of heated debate about expectations, responsibilities and mindwiping customers, it dawned on me that the participants in this discussion were using three different meanings of the term acceptance testing:
Forget the Words, but Check the Meaning
Depending on the type of organisation, type of product, and type of customer, a project will face one, two, or all three of these forms of acceptance testing. In our discussion at Agile Open it took a while for us to realize that some people were not agreeing with each other only because their ideas of acceptance testing followed different levels of definition. Once we identified that problem, communication (and agreement) seemed to be a lot easier.
Now, don't get me wrong, I have no intention to redefine acceptance testing! The testing community itself already has many fine definitions of all kinds of testing activities. But some people correctly pointed out to me that exact terms and wording are irrelevant as long as people agree on meanings. I have noticed similar confusion among development teams and customers leading to miscommunication about expectations and responsibilities.
Let's Understand Each Other
So… I advise you to check each of these "levels of acceptance testing" to see if all stakeholders agree on the way they are implemented in the process. It doesn't matter how you call it. Just make sure you're talking about the same thing.