Acceptance test dilemma

Anonymous

I’m having trouble articulating an acceptance testing assumption to my client (or maybe my client is stubbornly refusing to accept my assumption) so would like to request your feedback on my situation. The project I’m delivering is a database system, which the client is supplying the data for. The data is coming from multiple legacy systems from within the client’s organization and the data has numerous issues (i.e., missing information, inaccurate information). I don’t want the UAT approval to be delayed by the client’s data issues so I added an assumption to the UAT plan which states that data quality issues caused by source data problems are not considered negative UAT results.

Needless to say, the client has balked at this assumption and they claim it is impossible for them to run the acceptance test on the system (and accept it) unless the data is correct. Their thought is they can’t accept a system if their business queries are returning inaccurate results. Any thoughts?

Posted: Apr 4, 2003 5:18 PM

Sort By:

Frank Patrick Boonton, Nj, United States

Sorry, anon, but I'm on their side. If the project is to give the client a useful system, there needs to be included in it assurances that the data it queries is useful. I suspect that the client's view of a usable system is one that gives answers to the questions asked, not just something that asks the right questions. (Or maybe, the wrong questions, given the state of the data.) Rather than throw an unusable system over the wall, you need to work with with the client to add a few tasks to your plan/schedule to address the data cleanup.

Posted: Apr 5, 2003 7:30 AM

Mark Tinsley Melbourne, Vic, Australia

Anon, I would agree with Frank. If I were a client asking for a product and an agreement was in place to deliver on the product... I would expect a working product.

Some thoughts that may help your casuse:
1 Has the quality of the data been raised at any point during the project, or is it only being raised now

2 Is this an opportunity for further work. Handled professionally, you present an opportunity to assist the client in finding where their data is poor and as Frank suggests, offer to include tasks deal with it.

Good Luck

Posted: Apr 8, 2003 1:55 AM

Anonymous

There are no surprises on this project related to data for three reasons:

1) Data quality and timeliness of delivery was raised as a risk early on in the project as the data is coming from twelve different systems across the country.

2) One of the assumptions in the SoW was that the client was responsible for all data quality issues.

3) Data issues have been a recurring theme throughout the life-cycle of this project so data has been a permanent line item on my weekly client status meeting agenda.

One other thing I didn't mention in my original post is that the system is designed to be updated weekly with new/refreshed data from the client's legacy systems. This is the primary reason why I thought we could separate data quality issues from the UAT. The client has the power, through the weekly update process, to easily add corrected data to the system.

P.S. Thank-you to both Frank and Mark for your feedback!
Saving Changes...

Posted: Apr 8, 2003 6:51 AM

Kevin Konynenbelt Calgary, Alberta, Canada

Another option you introduce is to "classify" any issues encountered during UAT -- so you can segregate the data issues.

If you can get the client to agree that the data quality issues are their responsibility, and that "sign off" can be of two sides -- one for the system and another for data issues -- this might allow you to stake out the middle ground.

It will allow you to clearly report on where the issues are coming from, and show the impact on the testing cycles and progress.

I agree that the client won't want to sign off on the system unless all the pieces are working together, but it sounds like you need a way to hold them to their responsibilties (and also to get them to recognize that their progress will impact your ability to deliver).

Posted: Apr 8, 2003 5:07 PM

Francis Cepero Walldorf, Germany

Hi,

We have similar problem at a CRM implementation.

However the Data Quality here runs as a separate global initiative with DQMs in every location and is firmly in the hands of the customer.

Despite that, we had a big discussion around data, timeframes and deliverables. Nevertheless we agreed to separate the system delivery from the data quality issue from the functinal and ownership perspective. In the blueprint and project definition we integrated the data migration and data Quality topics and planned for that.

Then we defined that both streams meet at the Going Live date. I would tr to recover the project by driving agreement towards a new deadline incorporating customer's requests for data quality but also his responsibility.

Posted: May 15, 2003 6:10 PM

Amon Nixson Falls Church, Va, United States

Data quality (particularly from legacy systems) is always a problem. I have found there are two ways to deal with the problem, but each method requires the cooperation of the client.
1) The testing scenarios established for the application must include a control scenario. This control scenario includes a set of input data that has been reviewed and blessed by the client as correct. The expected output of this particular test must be known by the client. You will have to actively participate and insure that the clients have run these control scenarios. If the results can be repeated with multiple sets of reviewed and blessed input data, it will only be a matter of review to determine that bad data produces unexpected results.

2) The only other means is restricting data feeds to information that meets standards. Of course, this means that the input process must produce error logs for the originating system to indicate items that have been rejected and must be cleansed(a business process that very few organizations want to undertake).

Good luck

Posted: Jun 4, 2003 4:22 PM

Please login or join to reply

Acceptance test dilemma

Sponsors

Vendor Events

Guessing is not a strategy: How to build decision velocity with AI and real-time data

Newsletters