Automation - Team set up

🗄️ Archive
1

Hi All,

Wondering what team setups (around automation) have worked best for people. I suppose it boils down to

a) separate “Automation” and “manual” testers
b) Having all testers responsible for both automation and manual (no automation SME or lead per se)
c) Having a designated automation lead and many others who are capable of writing the scripts

For context, In our (small) team at the moment we’re using a Selenium based framework built in C#

My own opinion lies more with option (a) as my preference is to give people a chance to “own” something and the objectives to enhance and improve, and give some consistency.

1 Like
2

Hi

In my opinion… if you have separate automation and manual testers, you may be allowing a single point of failure.

If you only have one automation engineer, what do you do when they take unplanned leave for a month (e.g sick)?

Maybe you have two, but one is on annual leave and the other on sick.

Ideally, you want to aim for T-shaped testers, and everyone to be able to do each other’s job. People will have their preferences, and some will be better at certain tasks than others, but then you are giving them a fair chance. They could also learn from each other and be able to work collaboratively.

I hope this helps?

3 Likes
3

Hi, Thanks for the reply. I agree with the SPOF comments and this is particularly an issue as we have an smaller team.
Would you (and others) say that you agree with a notion that we should have at least 1 specialist/SME though and other testers who are competent capable - so leaning towards option ©

4

Personally, if I had the choice/resources option C is how I would do it. Interested to hear other people’s comments though, if they disagree :slightly_smiling_face: just speaking from experience though that is how I have always worked

1 Like
5

Here are some of the things that I have experienced in the past (and present):

We had a team of 2-3 testers. One tester would not touch the code (tangent: he is now a coder), but had the most domain knowledge of anyone in the team. I would create simple test scripts in Python, but nothing which would pass as automation. This worked for us, even if one or both of us were away. It seemed that we communicated our testing efforts well enough that, if needed (and gladly wasn’t needed much), other team members could step in.

We had a team of 2 testers in a huge company. We were supposed to “follow the script”, but neither of us did. We both worked on automation, had code reviews, maintained the repositories (even for the production code), explored the systems, and logged the results. This also worked well because we constantly communicated our testing stories with the rest of the team.

We had a “team” of 1 tester (me). I split my time between exploring, creating regression test scripts, creating automated tests, and communicating the results of my testing. It worked well because the communication helps keep both myself and the team on the same page. (Are we seeing a theme here?)

The need for constant communication in teams leads me to believe that the word “separate” is extremely loaded. The whole team doesn’t have to work on the code itself, but they should really work together on defining the test strategy and test ideas. In this way, you aren’t stepping on toes, and more hands may make easier work. (But beware, as too many cooks may also spoil the broth)

Having all testers responsible for all tests can also be a fallacy, since someone may have a huge depth of domain knowledge, but little skill in coding, or vice-versa. This could lead to a non-optimal use of the team’s time.

Ideally, everyone is T-shaped and can do all of the roles. Then you could have a “leader” and split roles evenly. But in the real world, that is never the case. Therefore, you may want to build your team based on the abilities, desires and goals of the team members rather than a pre-built model.

2 Likes
6

Michael Bolton asked a parallel question about teams on twitter, do chime in better than I have managed to https://twitter.com/michaelbolton/status/1174117262544048128

I am a fan of cross-team testers, a team where only the tester tests is broken, and a team where a tester only stays inside of their team’s own remit is also broken - this creates a role for testers to be a extra communication link/loop in the SDLC in whatever form it takes for you. Creating high role separations for me, always leads to duplication and wasted time. I like a system where automation engineers help the manual test engineers by giving them tools that let them do their jobs faster. For example automators can help to script setting up an active-directory environment together with user profiles and policies, or a SQL script that helps with populating a web database with realistic e-commerce datas.

7

In my org we have 2 different career paths for testers — SDET (Software Development Engineer in Test) and Test Engineer. Both SDET and Test Engineers are expected to take on testing tasks as needed, but the main focus of SDET is to build out and train others on the Test Automation Frameworks including documentation, 1:1s, and adding specs (tests) as well, but not on a specific project team. While the Test engineer is responsible for working with project teams to identify and test for risks, and learn and contribute to test automation for the features that they are testing.

We also have a prioritized backlog of Test Automation tasks that anyone can pick up as time permits. So far this has worked really well for our team. I do think it is really important to make sure there is some lead, that has a good foundation of test automation and the strategies behind it. I’ve seen too many test automation projects die (a few that I have been on) because they didn’t have a good lead, chose the wrong things to automate, or wrote code that was difficult to maintain.

4 Likes
8

An alternative is to have purely manual testers who can write business-language automatable tests (eg gherkin) and code experts (cough, developers, cough) who implement them as automation - this is how my current place works. Plays to the strengths of both: the people you employ to design tests design the testing, the people you employ to code hook that up to the code (usually code they have written, so already understand intimately), and everyone shares responsibility for quality, automation and the like.

2 Likes
9

Your comment about the lead and needing one echoes my thoughts entirely. Currently, whilst I am the TM/TL I don’t have technical, hands on, experience of automation so can’t train or give technical guidance .
I’m - as a side project - looking at Katalon at the moment to see if that is worth pursuing as a replacement for current framework, in the hope that it is a more accessible to all.

1 Like