Who should write your automated acceptance tests?

This post is part of the Pride & Paradev series.

Who should write your automated acceptance tests?

Programmers should write your automated acceptance tests

If you’re a solo tester in an agile team, like me, you really have no choice but have the programmers take responsibility for writing and maintaining automated acceptance tests. You’ll be so busy with acceptance criteria, story and exploratory testing, you just won’t have time.

The benefits of having the programmers in your team writing and maintaining these tests is that they will be maintained and executed as soon as any change occurs, so they’ll be kept more up to date and less likely to go stale. They’ll also be more useful in providing fast feedback to a programmer working on a change to a specific screen as the programmer can run the relevant acceptance tests, make a change and then ensure the acceptance tests still pass. If a tester were responsible for the automated acceptance tests, there is a lag between updating your application and your tests, which, if not properly managed, can lead of many tests repeatedly failing and spurious test results.

Programmers will have a better understanding of the architecture of your application and will be able to build testability features in so that the automated acceptance tests are more efficient and reliable.

Testers should write your automated acceptance tests

Software testers are particularly good at building automated acceptance tests that cover an end-to-end process in the system; often called user journeys. This is because they have a good understanding of the journey whereas a programmer may only understand the logic behind a particular screen. Testers should be involved in writing this style of  acceptance tests so they are representative of real usage.

Some software testers are particularly good at knowing how to automate a web browser. Understanding how browsers work from an automation perspective is a highly developed skill that many testers have and having this skill leads to a more resilient automated acceptance test suite that wait for enough, but not too much, time for elements to appear and update.

Software testers are also very good at interpreting automated acceptance test results and investigating whether a bug exists or whether the tests need updating. If the tester is doing this work, then it makes sense for them to update the automated acceptance tests as needed.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

2 thoughts on “Who should write your automated acceptance tests?”

  1. This is an issue I have been struggling with. Anytime I write a Selenium test (in C# using NUnit), it moves too slowly to really fulfill the job of “providing fast feedback to a programmer working on a change to a specific screen”. It seems to take like 10 seconds just for Selenium to start a browser and open the first page. Are you able to get these tests to launch more quickly?

    (Selenium IDE scripts, on the other hand, do provide fast feedback since they don’t need to launch a browser, but they have limited functionality and can only be run in Firefox.)



  2. Comment for Ben:

    I have used Selenium RC with NUnit and IDE in the fashion you describe. I have found that using automated acceptance test for each build too much of a burden on developer time to be feasible. My strategy was to rely on comprehensive unit tests to be run on each build to validate developer work rapidly and then periodic running of acceptance tests i.e. once in the morning, again at noon and finally a more comprehensive suite over night.

    Comment on article:

    Who should automate your manual tests? Depends on your goals. If you want to build them quick and to specification then a developer, although this is bad for a project as it distracts a developer from their core role i.e. it takes a different mind set to create a feature then to validate a feature with respect to business need.

    Testers can write automated acceptance tests but again having a technical understanding is a distraction from their core role i.e. validate the quality of the system features for fulfilling business need.

    A mature process requires specialisation i.e. an automated tester. An automated tester is technically inclined enough to write automated tests but business orientated enough to automate the right tests.

    What to automate? All automation candidates should be based on process analysis, (in this case test process), i.e. analyse all the functions/tasks performed by a manual tester and identify those best suited to a computer and those best suited to a human.

    Typically humans are good at pattern recognition and intuitively identifying what is out of context for a environment on the other hand humans are notoriously bad at tedious repetitive tasks. Computers are good at repetitive tasks without deviation from a predefined algorithm and they are currently bad at pattern recognition.

    Hence from a broad view, new features/changes should be tested manually and already delivered and tested functionality should be automated by a specialist automated tester. Anything else is a compromise and will yield inferior outcomes.


Comments are closed.