Automation, a work for testers or developers?

Lots of companies don’t have any Testing or QA Team, and in DevOps environment, most of them are thinking about adding a new role to start a new project for test automation. Maybe that you already have some unit tests, integration tests or service tests that are executed on your CI, and these have for sure been written by developers.

But what is the strategy behind that? Are these tests really relevant and useful? Are they passing all the time and not ignored? Do you need a new team to manage these test activities or is the actual team with no dedicated tester enough? And finally what are all these roles including “Developers in Test” in the name?

Automation is a project

First, I like to say one thing: Automation is a software development project. And I think I will write it twice, in bold is better: Automation is a software development project.

Let’s say you are working on a e-shop, at first only available with a browser desktop. If you want to provide your customers with a new Android and iOS application, will you add a ticket in Jira (or whatever) “Build the Android/iOS app” and assign it to one of the developers building the Angular desktop application? Probably not? At least you will create a new project, create a new team, and will look for someone with the skills to build a smartphone application.

Same for test automation, automation is a real new project and should be treated as such. Don’t expect a half-time intern to do it! Don’t expect your developers will do it during a workshop week! Don’t expect your developers to build it during 2 sprints and let them add tests during each sprint.

A project needs a strategy

I cannot give you THE strategy that fits your environment. I can only give you a list of questions that you need to answer then you will be able to start thinking about a coherent strategy:

• Why do you need to automatize?
• What is the goal?
• Release the product faster without the bottleneck of manual testing?
• Let other testers of the team remain concentrated on exploratory testing?
• Do you really need it? Why not testing it “manually”?
• Have you calculated the Return on Investment?
• What levels can be automatically tested (API, Services, UI)?
• How the tests will be ran? Locally, in the CI jobs of the product, or better in a separate CI job?
• Can I be helped by AI?
• What testing data is available and can be used?
• What environment will I be able to use? Is it possible to have a real isolated test environment?

If you want to know more on this, I suggest you to see this course available on TAU: Setting a Foundation for Successful Test Automation by Angie Jones.

An automation project needs experts.

Automation needs a dedicated team. “So if it’s a real project with a strategy, I probably need a team and people in this team, right?”. Yes, you are right, you need resources. But who?

Developers know how to code, but aren’t the best testers. So they will just try to automate all the things, and will probably start with useless things. You could try to learn them the testing Mindset, but I’m not sure they will have enough interest in the topic.

Testers know how to test, but aren’t the best developers. You can train them to help them become a tester able to code testing. If you can wait for several weeks and let them spend full-time learning code, that’s a good idea. Do you really want to do this?

Of course, needless to say that managers, UX designers, Head of Customer success or agile coaches won’t be the perfect candidates too.

Several options are available to you:

1. Hire an automation specialist, one that is a very good developer but also has the testing mindset and will be able to build a perfect strategy in order to only write relevant and useful tests at the correct level (Integration, API, UI). Sadly, they are not numerous and probably already very busy,
2. Use a codeless tool that will be used by your testers. Some of them are very easy to learn, and with a little help from developers for very specific cases, you should be able to automatize major testing features. These tools are very expensive, and will need significant maintenance efforts,
3. Build a team of developers and testers. Because a good strategy will probably be to write different kind of tests: unit tests, integrations tests, API/Service tests, UI tests with or without visual checking (remember the Cohn pyramid of tests). For this, testing and development skills are needed.

I personally think that, in most cases, if you cannot find an automation expert, the best solution will be the third one at least to start the project. Later, you will maybe have someone able to manage it alone, maybe a former developer or a tester.

Do I need a STE, STAE, SDET or a SET?

That’s a lot of acronyms. Are they used for the same role or not?

S stands for Software, D for Developer or Design, T for Testing and E for Engineer. Then you can create your own acronym. Microsoft was the first to introduce “Software Developer Engineer in Test” (SDET) in 2005. Google adopted “Software Engineer in Test” (SET) for the same role. But you can also find STAE or STE.

Another role you may find is “Software Design Engineer in Test” (that’s another SDET) which is a very technical one. Tasks involve auditing the architecture of the software, testing and suggesting improvements on components and interfaces. The SDET (with a D for Design) can also write test scripts to achieve these goals, then he is also a SDET (with a D for Developer).

Software Test Automation Engineers (STAE’s) are often less technical and need less programming skills because they mostly focus on automation using tools like QTP or TestComplete.

So according to your context, who do you need?

Conclusion

It’s up to you to find the right strategy and be helped by the good people. Don’t be ashamed to try things and iterate. Don’t be afraid to say that good automation is not easy. It can be easy, but the one that has lots of value, the one that fails only when there is a real issue, the one easy to debug, the one that is fast, the one that gives good reports is very hard to reach. And don’t forget you will still need non-automated and exploratory testing to fill the gaps.

Good luck, and don’t hesitate to talk about your context and give feedback.

Originally published at lyontesting.fr.