Who writes the test cases for your client when it's time for Client Acceptance Testing?

Question

This question has recently come up at my organization. When it's time for the client to review and accept either a large ecommerce implementation or a smaller feature enhancement, will your QA team write the test cases for your client to use or will you leave this for your client to do?

The concern is that the client either will not have the time or focus to be able to write the test cases and do a full system test. But maybe this is ok, if we agree that the purpose of Client Acceptance Testing is for the client to poke around in whatever way s/he is accustomed to and see if anything breaks.

What have you done?

Answer 1

Client (or User) Acceptance Testing (CAT or UAT) is a critical phase of system implementation projects and should be well planned, structured and documented.

About test cases (or test scripts):

• Test cases are detailed step-by-step instructions that allow to validate how the functionality works from an end-user perspective.
• They should cover all user requirements in scope for the project as well as business processes supported by the system.
• The best way to write a test case is to base it on a business process (eg. place an order) and validate related requirements as part of that process execution (eg. modify product specification as part of the order).

Who should write test cases:

• Test cases should be written by project team members who have a good command of the system's functionalities as well as client's business processes. So depending on your project team structure, this could be a Business Analyst or a Functional Lead (or even a Developer on small projects though that's less common). On large system implementations there are dedicated test teams who are tasked with writing up the scripts as well as preparing and managing the test cycles.
• Usually it is not the client or end-user who writes the test scripts, unless the client has actually assigned resources to the project to do that. In any case, to maintain the integrity of the test process the person who writes the test case should not be the person executing the testing.

Additional recommendations:

• Don't let your client loose: I advise you strongly not to agree to a "do-as-you-like" testing. Although this stems from a good intention (giving freedom to the client), this will likely get you a into a problematic situation: not only the system will not be thoroughly tested but you will likely see your client raise issues and questions that are not valid (e.g. "this doesn't work" because client doesn't know how to use it, or "this doesn't do X" because it wasn't a requirement in the first place).
• Always do regression testing: when you deploy a new system or go through a significant upgrade, you have to test the entire application. However for small enhancements, there isn't a need to put the same amount of effort into testing. You should test for new/modified functionalities (either through new test cases or existing updated test cases) and also test critical "regular" functionalities to ensure enhancements haven't affected the normal utilisation of the system. Hence it is a good idea to identify amongst your test scripts a set of critical test cases that you can use going forward for your regression testing.
• Optimise the effort going into your tests cases: Test cases can take some time to write depending on the complexity and the scope of the functionalities developed. However since they are designed to validate how to use the system, they can also be used as a basis for developing training materials (particularly if they are written based on business processes). So this is a way to leverage the effort going into test scripts for another area of your system implementation.