How can the role of QA maintain the alignment between the Business and IT?

Question

In my previous organization there was a disconnection between the Business Operations and IT that always impacted the final derivable.

For some reason, the Business intent was not accurately represented on the final product. Even though we reviewed the Business Case over and over there was always a piece of functionality missing or not performing as expected. We did have QA testers in the Development team but no UAT was carried out on the Operational end. So I have few questions of which I would like your support to prevent this issue in my the future,

1. Should we need QAs at both ends?
2. Who should be really carrying out the UAT?
3. Who should write the Test Cases?

Answer 1

This is a common issue, that I have run into in several organizations.

1. Business may have an expectation that QA can ensure that the system meets their needs. However, QA will be working from the same requirements specifications as development. QA can ensure that the system meets the specifications. This is not the same as ensuring the requirements meet the business needs.

   UAT should be an entirely different process. It is verifying that the requirements as implemented are meet the business needs. If you consider this a QA activity, then you do need two QAs with two different teams. After delivery is not the time to identify variances between the specifications and the business needs.

   Usability tests may fall in the grey area between UAT and QA. QA should handle those tests that require a fresh user (outside resource) each time. UAT can handle cases where business users apply the system to its specified purpose. Users in UAT tests may be involved in more than one test cycle.

2. UAT is a business role to ensure that the system as built really meets the Business requirements. The earlier you can get get the business team to test that the application meets their needs the better. The earlier business reviews the system, the earlier problems can be identified.

   Getting business involved in UAT tends to be difficult. I have found this is a fairly common problem. This will delay detection of variances between the specifications and the business needs. Business involvement throughout the development process should result in earlier detection.

   Business may also want to pass the blame by withdrawing from the project after providing the requirements. Avoiding the blame game, and getting business involved in ensuring the success of the project may help.

3. The QA team should be writing the requirements test cases. If they are involved in the requirements gathering process, they will have a better understanding of the requirements. This will allow early detection of variances between the documented requirements and test specifications.

   There may be a significant number unit test cases developed for the code. This should be the responsibility of the development team. Requirements tested in unit test cases may not be part of the system requirements. The QA team may be able to mentor the developers in designing unit test cases.

I think this quote sums up one of the problems with requirements gathering:

“I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.” Robert McClosky

Answer 2

It reads to me like a fundamental lack of decent requirements were collected at the outset. Was the Business involved at the discovery or initial discussion?

This sounds like the perfect scenario in which to try an agile, iterativeplan. Concentrating on smaller, more frequent delivery (a sprint, if you prefer) with a representative of the Business unit to give feedback should result in a product closer to everybody's goals. Or if not, they should know why sooner.

To answer your questions:

1. 1 QA should be enough, if requirements are accurately defined. 2 sounds like bureaucratic hell.

2. In this instance I would advise UAT is conducted by Business.

3. If requirements are collected, test cases should practically write themselves.