Writing test cases business testers understand

Why business testers need other test cases

A system test is done by people who built the system or know it well. A user acceptance test is done by people who use it: they know the work, not the configuration. They do not know which field is new, which flow runs in the background, or what the developer meant.

So a UAT test case has to work for someone who:

• knows the business process by heart, but not the new screens;
• has a few hours between other work, not a week;
• should never have to guess whether a step passed or failed;
• will stop and wait when a step is unclear, and lose time.

Every hour spent on clear test cases saves many hours on the test days: fewer questions, fewer issues that turn out to be misunderstandings, and results you can trust at the go/no-go.

From user stories and processes

Test cases come from two places, and you need both.

User stories and their acceptance criteria

A user story says what someone wants to do and why: As a sales rep I want to convert a qualified lead, so that I get an account, a contact and an opportunity. Its acceptance criteria say when it is done. Each acceptance criterion is a candidate for a step or a test case.

Check coverage: every user story in scope needs at least one test case. A story without one is a gap, and gaps are found in production.

Business processes, end to end

User stories are cut small for the developers. The business works in processes that cross many stories: lead to cash, quote to order, case management from email to resolution. A story can pass on its own while the process breaks at the hand-over between two teams.

So add end-to-end test cases that follow a process from start to finish, across roles: the sales rep makes the quote, the manager approves it, the order goes to finance. These are often the test cases that matter most to the business.

In UAT StudioRead the user stories from Jira or Azure DevOps on the User stories card, and tick Only stories without test cases to see the gaps. With the AI test design module, AI proposes test cases from your stories or from a process description, also on your company's own model. Nothing becomes a test case until you approve it. Without the module, Prepare with your own AI gives a prompt to paste into your company's AI; steps marked [CHECK] are assumptions to check.

One goal per test case

A test case tests one business scenario, with one goal. Its title says what the tester achieves, in the words of the business:

• Convert a lead with an existing account
• Approve a quote with a discount above 20%
• Route an email from a known customer to the right queue

Not Test the lead object, and not Leads, opportunities and quotes. When a test case has several goals, one failure blocks all of them, and the result says little: what failed, and what still works?

How big is one test case?

As a rule, a test case has between three and fifteen steps, and takes a tester five to twenty minutes. Much longer, and it probably has more than one goal: split it. Much shorter, and it may belong with a neighbour.

End-to-end test cases are the exception. They follow a whole process and can be longer. Keep them, but make sure each part of the process also has its own shorter test case, so a failure is easy to place.

Steps with an expected result

Every step has two parts: an action (what the tester does) and an expected result (what should happen). The expected result is what makes a step testable. Without it, the tester decides what is good enough, and two testers decide differently.

Write the action

• One action per step. Open the lead and click Convert is fine; five clicks in one step is not.
• Start with a verb: open, click, fill in, choose, save.
• Use the labels as they are on the screen, in bold or quotes.
• Say what, not how the system works inside. Save the quote, not trigger the approval flow.

Write the expected result

• Say what the tester sees: a message, a value in a field, a new record, a status.
• Be specific. The opportunity is in stage Qualification, not it works.
• Name what should not happen when that matters: No second account is made.
• For things the system does by itself, say where to look: The case shows in the queue Benelux Support within a minute.

Test data and roles

Test data

Testers lose more time looking for data than on any other part of a UAT. Put the data in the test case wherever it matters: which customer, which product, which price list or price book, which amount. Prepare that data in the test environment before the first test day.

• Use names that are clearly test data, such as Jansen Logistics (test).
• Give each tester their own records when they change data, so two people do not edit the same opportunity.
• Add values at the edges: a discount just below and just above the limit, an empty required field.
• Do not use real personal data of customers where you can avoid it.

Roles

In a CRM, what a user can see and do depends on their role: a profile and permission sets in Salesforce, security roles and a business unit in Dynamics 365. A UAT proves that each role can do its work, and only its work. So every test case says which role tests it, and the tester signs in with a test user that has exactly that role.

Never test with an administrator. An administrator sees and may do everything, so the problems a UAT should find stay hidden.

In UAT StudioEach step has an action, an expected result and optionally test data. Each tester gets a Test role and a Test account, shown at the top of their tests as Log in as …, and the role is shown next to their name on every issue they log.

Priority and risk

There is never enough time to test everything equally well. Mark each test case so the important ones are tested first, and finished even when time runs out.

Add the risk next to it: what it costs when this goes wrong after go-live. A wrong price on an invoice is high risk; a wrong label on a report is low. Within the same priority, testers start with high risk.

Be strict with Must. When half of the test cases are Must, the label means nothing: keep it for what the business cannot do without. Agree the priorities with the process owners: they also decide at the go/no-go, where Must test cases that have not passed count most.

In UAT StudioSet Priority (Must, Should, Could) and Risk (High, Medium, Low) in the editor or in a column when you import. Values of other tools are read too: Critical and High become Must, Medium and Normal Should, Low Could. Testers see their Must test cases first, with high risk first within each priority.

An example

Test case 12: Approve a quote with a discount above 20%

Priority Must, risk High. User story CRM-118. Role: sales rep (steps 1 to 3) and sales manager (steps 4 and 5).

Note what makes it work: one goal in the title, one action per step, an expected result a tester can check, the data and the role named, and an unhappy path in step 3. Add a second test case for a discount below the limit, which should need no approval.

Common mistakes

• No expected result, or works as expected. The tester has to guess what was expected.
• Technical language. Field names from the database, object names, or check that the trigger fires. Use the words on the screen.
• Too many goals in one test case. One failure blocks the rest, and the result tells you little.
• Only the happy path. Add a required field left empty, a value above a limit, a user who should not see a record.
• Missing test data. Open an opportunity: which one? In which stage, with which products?
• No role. The tester uses whatever account they have, often one with too many rights.
• Copied from the system test. Written for developers, with steps business testers cannot follow.
• Everything is Must. Then nothing is, and the important tests are not done first.
• Written once, never read. Scripts nobody checked before the test days are full of old labels and wrong menus.

Let a key user review them

Before the test days, ask a key user from the business to read the test cases and try two or three of them in the test environment. They find what the writer cannot see: a step that assumes knowledge, a label that changed, a process that runs differently in another country.

Check at the same time that every user story in scope has a test case, that every role in scope tests something, and that the test data exists. Then keep the test cases after the go-live: they are your regression test for the next CRM release.

In UAT StudioImport test cases from Excel, Azure DevOps, Jira with Xray or Zephyr Scale, or TestRail, or write them in the editor. The template library, an add-on to every paid plan, has ready-made scripts for Salesforce and Dynamics 365 to change to your own setup.

Free to use

For everything else to arrange before, during and after the UAT, see the UAT checklist for a CRM go-live, also as a free Excel file.