How to Create Test Scripts for UAT that focus on Business Process?

Question

I am creating a Test Scripts for our UAT but I always ended up doing a test case that looks like a System test scripts. Is it ok to have another test case in a test case since I am validating that the feature is working?

If I'm going to use Gherkins BDD style does it mean I will not do this?

• Steps 1: Click [Button] Expected Result:Users sees the window
• Step 2: Click [Dropdown] Expected Result: Option will be displayed

I've been searching online for a sample but I don't see any helpful article or blog.

Answer 1

The best approach for UAT would be gherkin or keyword-driven testing

You can get more information for gherkin here at:

https://cucumber.io/docs/bdd/better-gherkin/

BDD driven

An example for UAT test could be :

  Feature: Subscribers see different sets of stock images based on their subscription level

  Scenario: Free subscribers see only the free articles
  Given Free Frieda has a free subscription
  When Free Frieda logs in with her valid credentials
  Then she sees a Free article on the home page

  Scenario: Subscriber with a paid subscription can access both free and paid articles
  Given Paid Patty has a basic-level paid subscription
  When Paid Patty logs in with her valid credentials
  Then she sees a Free article and a Paid article on the home page

Here we hide the internal procedural flow, for example

When Paid Patty logs in with her valid credentials

step actually includes inputting credentials, clicking login button etc. But we hide the actual procedural flow from the final test.

So here we are considering more of what than how.

Keyword Driven

There are keyword driven frameworks like robotframework:

reference:

http://robotframework.org/robotframework/2.7.2/RobotFrameworkUserGuide.html

Example:

*** Test cases ***
Simple Smoke Test - Correct Answer
   [Tags] cloud
   Set Up And Open Android Application
   Input Name ${NAME}
   Select Option Use Testdroid Cloud
   Submit Selection
   Validate Correct Answer

Answer 2

Use Cucumber

Focus on using full english. Focus on behavior over details, the 'what' over the 'how'.

So instead of

1. Click Button
2. See Dropdown populated
3. Enter numbers in input field

You want something that is more meaningful to the product owner, such as

1. Navigate to sign-up page
2. Select the correct type of product
3. Provide the number of items desired
4. Submit form
5. Ensure result is as expected

In the details you will do all the click, enter, click, etc. actions.

As with all testing you are doing three activites:

Setup ('given')

1. Navigate to sign-up page

Action ('when')

2. Select the correct type of product
3. Provide the number of items desired
4. Submit form

Result ('then')

5. Ensure result is as expected

Get your product owner to own and maintain these with appropriate language for the domain you are in. You may need to help them with this advice too or they may just write 'click button' 'type 3', etc.

Answer 3

Others give examples for Cucumber, which could be a good fit, but be sure to read this:

Cucumber reached a million downloads in the first three years and 5 million downloads 3 years later. I'm happy to have created such a popular tool, but saddened to see how it's misused and misunderstood.

If you think Cucumber is a testing tool, please read on, because you are wrong.

https://cucumber.io/blog/collaboration/the-worlds-most-misunderstood-collaboration-tool/

Answer 4

Why are you, instead of the user community, creating the UAT scripts?

Verification is the comparison of the as-built system vs. the documents requirements. This is a defect discovery activity and is technical in nature (see White Box or Grey Box testing).

Validation (which is done in User Acceptance Testing) is the assessment of the as-built system for suitability of use in a production environment. This is a "missed or misunderstood requirement" discovery activity. See Black Box testing.

The system testers should be doing Verification.

The end users should be doing Validation.

The initial set of requirements (however they were documented, maybe as User Stories) should describe how the users will use the system as part of their day jobs. These implicitly contain their workflow and work processes. UAT scripts should be based on those requirements, and not any follow-on / elaborated / technical requirements or specifications.

Good luck!