First of all: A royal road and a really correct solution to automate acceptance tests does not yet exist. I am as aware of that as many of you are aware. But is that really so? Is there no way to go?

What is your solution?

What would be the right approach for planning and implementing the automation of the acceptance test?

  • 6
    Acceptance testing of what? A rocket, Hadoop job, national voting system or mobile game? As is know the question is too broad. – dzieciou Mar 24 '19 at 7:11
  • 2
    The question is already ok, because it should be clear that this software test is meant in the broadest sense. Whether you're behind coffee machines or lawnmowers, it does not matter;) – Mornon Mar 24 '19 at 15:05
  • 3
    I'm not sure what you're asking for here - what's the problem exactly? – trashpanda Mar 25 '19 at 10:21
  • 1
    I don't know why there is a trend in down voting possible questions that makes sense – PDHide Jun 20 '19 at 14:20

You automate acceptance testing by writing Automated Acceptance Tests and using a devops pipeline for continuous integration

These are frequently (not not always) UI tests.

Set up your environment to that when developers change code they run all the automated tests locally.

Set up your Continuous Integration environment ('tests that run on a cloud server') so that when changes are made and pushed, tests are run. This should happen both at branch and master levels.


If one is appraising a solution that requires things like long run-times, massive datasets or 100's of users ie things that would be difficult to replicate, then perhaps testers may assist. You don't want to end up with a complicated black-box though, as that only creates more code to worry about!

The correct answer to this question is 'It Depends'. If your problem can be solved by automation then use it - it has to be evaluated though as there is no magic bullet in testing.

  • Theoretically then pure manual testing would be possible in the team? Because who says that I have to automate at all? – Mornon Mar 24 '19 at 15:06
  • @Mornon Automation is a serious investment that pays off if done right and used frequently. For instance, if you want to execute your tests only once, then automating might not make sense. I'm leaving might in italics, because there are cases when it makes sense running automated tests only ones, but you have given no context, so I will live the answer open as well. – dzieciou Mar 24 '19 at 19:32

The choice of best acceptance testing practices can vary according to the project, organization and the system under test. I am not sure that the answer that follows would be used as a generic solution but surely does help in software testing domain.

1: Using regression test result as the acceptance criteria:

In most organizations, on integrating new features the functional tests are integrated into the regression test suite and are ran as a single test. This ensures the end to end test coverage of already existing features and the newly incorporated features. As we all know, these tests will obviously cover the user acceptance tests scenarios also.

So one of the best practice is to keep around 95%< pass rate as the acceptance criteria for the release candidate.

2: Using Keyword driven testing

Use frameworks like RobotFramework to create keyword-driven tests. Make product owners, and business analysts to write high-level keyword-driven test cases and hand it over to QA automation team, who then develops the low-level source code for this high-level test-cases.

enter image description here

2: Using Behaviour driven testing

Same approach like in KDD, but here BDD frameworks like cucumber is used. The PO and BA creates the high-level behavior driven test cases using feature files in gherkins (Given, When,Then) format, and QA team have to write the step-definitions.

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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