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.

  • 2
    Hi could you elaborate on what you mean by looks like "system test case"
    – PDHide
    Commented Jan 29, 2020 at 8:40
  • Its more technical Commented Jan 29, 2020 at 8:41
  • I don't know if my test scripts will be valid I don't have a sample. Can you give me flow on how to create the test scripts? Commented Jan 29, 2020 at 8:44
  • 1
    This is where you can use gherkins bdd style frameworks like cucumber
    – PDHide
    Commented Jan 29, 2020 at 8:45
  • 2
    cucumber.io/docs/bdd/better-gherkin read here
    – PDHide
    Commented Jan 29, 2020 at 9:59

4 Answers 4


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

You can get more information for gherkin here at:


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:




*** 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
  • I think it's ATDD not BDD when it boils down to acceptance tests.
    – Moro
    Commented Jan 29, 2020 at 12:05
  • @Moro when you dig deep most approaches overlaps some where . ATDD is just an approach I believe , but kind a framework to use depends on the team . For instance, you could go for a BDD or kDD framework for writing your ATDD
    – PDHide
    Commented Jan 29, 2020 at 12:26
  • How about filling out a form?? Commented Jan 30, 2020 at 1:54
  • @Moro I think the robot framework would be more technical on end-users views. Commented Jan 30, 2020 at 3:59
  • @JayBoyQuinto the keyword would be "when I fill all the details and try to register" . Keywords are just functions , so for this keyword you will right code (step definition) that will fill the form and click submit . So when u call the keyword, when I fill all the details and try to register" it will execute the function to fill everything n click send
    – PDHide
    Commented Jan 30, 2020 at 4:35

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')

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

Result ('then')

  1. 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.

  • 1
    Why didn't you add "Exected Result" and "Pre-Conditions"? Commented Jan 30, 2020 at 1:52
  • Thank You @jay ! Commented Jan 30, 2020 at 10:51

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.



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!

  • I know your point but the question is how are you going to document the test cases in UAT?? Commented Jan 30, 2020 at 1:53
  • @JayBoyQuinto So, is it "creating" (the verb in the original post) or "documenting" ? Because those are different. Creation ("what do I need, how do I know what I need") comes from the end user community, based on their requirements. Documenting ("once I know what I need, what tool do I use?") is more of a tool based question, and leads to Cucumber, or Word documents with tables, or Excel, or a host of software engineering tools suites (Rational, TFS, etc). Reusability, auditing of UAT test cases and results, use in automated regression etc. and so forth will drive the choice of tool. Commented Feb 4, 2020 at 18:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.