Ownership of test automation

Question

This is one of the challenge am facing with a new project.

We are facing a difficult task in deciding and getting everyone on board as to who will handle ownership of test automation.

I am aware that only if test automation is owned by the team, it has better chances of providing value.

Testers in the team would want to treat test automation as their responsibility and are reluctant to relinquish control and on the other side, developers are shying away from taking additional responsibility.

I would like get some insights on project which has faced similar dilemma. To convince and kick start the test automation soon, I need to ascertain advantages or disadvantages of this task being done by a developer or a tester (with basic knowledge of coding).

The project is planned to run in an Agile way. It is Web based application on Java. Prefreed tool for automation is Selenium.

Answer 1

You don't specify whether the developers are already writing tests at lower levels than the UI, e.g. unit/component/API level tests. It's also not clear how closely the developers and testers work together currently.

I'd agree with Rsf that it depends very much on internal culture, skills etc, which only you and your team can decide. But here are some suggestions for things that might factor into your decision making:

• Testability. As the people building the application, the developers have a lot of power to enhance the testability of the app. If they're building the automation too, then they obviously have some motivation to make life easier for themselves, but if the team works well together, they can help enhance testability just by talking to the people automating the UI and being willing to make changes to help - could be something small, like adding an id, or something a little bigger, like adding the ability to clear a cache so you don't have your tests failing occasionally because you can't reset the state of something. Discuss what the best way is for the team to improve testability.
• Investigating failures. When the tests fail, who will spend time figuring out what the issue is? If the first person to pick that task up is a tester, will they work with a developer? Will they get to a certain point and hand over to a dev? What is that point, and what priority will you as a team give to getting failing checks to green again? (Note: if the team doesn't care about fixing/investigating failing tests - then maybe they shouldn't bother spending the time writing them.)
• How easy/quick are they to run? This is related to the previous point. If it's hard to set up and run the tests, or they take 12 hours to run - no developer will want to run them. Investing in building good infrastructure is worth doing as a team, regardless of who writes the tests that run on it.
• Understanding overall coverage. If you have different people writing unit tests, API test, UI tests - they need to talk at some point, to figure out what's already covered by other tests, what could be pushed down to a lower level, what is missing from all of them and really should be covered somewhere. This could be as straightforward as a 5-10 minute chat at some point in the process, or it could be a formal review. Whatever will work for the team.
• Creating a maintainable, reliable framework. You will probably want to sit down and refactor from time to time, as you learn more about what you need (and see what's causing issues). Would it still be valuable for developers to pair on this, even if they are not usually writing tests for the framework?

I think my main suggestion though would be that you shouldn't consider test automation as a single task that has to either be done by one group or another. It's actually a number of different tasks and skills, and you could either choose to divide those tasks between the groups, or you could also share work by having members of both groups pair on tasks where needed. There are more options than either/or.

Answer 2

You'll have to discuss this with your team and company, among other things it depends on the internal culture, skills, schedules and even internal politics.

FWIW I've seen both successful and miserable results from the following:

• A test team owning entire automation, from the infrastructure to test cases and execution
• Separate infrastructure team, separate team adding test case and executing them
• Same as above but with another sub team working closely to developers
• One team to rule them all, aka "combined engineering". This may require a team dedicated to maintaining and building the test infrastructure itself

Answer 3

There are too many variables currently not reported in your question, for example:

• how many members will join the team? And will they be in common with other projects?
• do you expect to have dedicated testers and developers? Or can they change role?
• will product owner be dedicated to the project or shared with other teams/projects?
• do testers have coding skills?

If testers and developers are different members of the team and testers have programming skills, I suggest you to split the automation tasks into two: Developers: they should write unit tests and component tests for assuring the stability of core parts of the software; Testers: they should write functional tests with the aim of validating and verifying the user requirements. Functional tests may include end to end testing.

Useless to say that manual testing is another story and should be managed separately.

Answer 4

Frankly, this is a modern bane of many testers.

What you need to do is remind people in your teams (and higher up) that Everyone is working towards the same goal and its important that everyone in the team is respected for their areas of knowledge and specialism. You are a memeber of the development team who happens to specialize in writing Webdriver tests.

In your question you mention ownership of test automation. I presume this is something along the lines of running and checking the results of a nightly webdriver suite. Explain to your team that if you are on holiday for a couple of weeks then the daily checks will need to continue regardless.

Provide training to them so they can cover should the need arise. Running tests that no one looks at the results for Benefit no one, make sure that is understood by the team as a whole.

To make sure automated tests are written I would suggest you add the automated tests to the Definition of Done for a story. Help define these during your planning meeting as part of the requirements in the story.

In agile, a tester is BA, PO, Dev and Tester. So are all the Devs.

Change will take time, don't expect it to occur overnight. But once the teams sees the benefits it brings, they won't want to go back!

Some good areas to read further are here and here

Answer 5

I would like to suggest that testers should handle automation scripting. Because developer has development tasks also there and in future it may be possible that because of parallel development tasks , they may not be able to maintain automation tasks.

Also for any testing , prospective and mindset is totally different of developers and testers. According to ISTQB glossary , Developer can not do effective testing because of lack of objectivity. I agree because goal and mindset of developer and tester is different and they behave/work in that way.

So if you allow your tester team to do automation scripting then it is possible that they can cover many more test cases and scenarios. So here test coverage will be high by testers than developers.

Answer 6

Another thing to consider is, if you are agile ultimately the choice is up to you. There are conventions, but agile is intended to work in the best favor of the team. If you decide at some point that devs are best served focusing on dev work while testers are writing tests, then maybe that is the best approach for you.

The best part about agile is it should be whatever the team decides works. You should always start by following rigid guidelines and as the team gets used to the best standards and practices they can change to best suit their needs.