Hello,
we’re interested in creating a cohesive test automation approach that spans across our company’s different development projects. Rather than having strict guidelines, we envision something akin to a test automation toolbox. While we have a clear understanding of the desired content and direction, we’re unsure about how to implement it within our organization. Could you please provide insight into whether you have a test automation team, a guild, or a product owner specifically dedicated to test automation? Thx
2 Likes
It depends. Of course. 
There is (much) more to an automation strategy than tools, especially at the enterprise level that you are referring to. But to focus on the question you ask:
- A central automation team is useful when the org is just starting with automation, to build up knowledge, experience, a toolbox and one or more frameworks. And later it can support development teams by providing expertise, training, and maintaining standards where necessary. But it does create a dependency between teams, which is not ideal for a Agile/DevOps context. The question is what goal the team would serve, you want that to be very clear, and also what its mandate is.
- A guild as I understand the term - a community - does not usually have much time to create/build things. And then it cannot replace an automation team. It is a good way to get quick answers, set standards that are supported by the teams, and boost knowledge. Can be very valuable but often needs management encouragement for people to participate in it, otherwise they may often “have no time” for it (according to their PO …).
- If you have a central team then it needs to know what to work on. A PO is a common way to make that happen. You can also have a central authority that makes strategic decisions, a sort of ‘automation owner.’ Depending on the org culture and delivery model, this task is often better assigned to the guild/community.
Hope this helps.
Hi @forestgeeks - really good question, it got me thinking about my organisation and just how differently its done across different teams
But the one thing that remains constant is that we are empowered and have autonomy to do what works for us re our approach to automation - we have a central team that has done a lot of the hard work in setting up automation frameworks that anyone can adopt and build on but that doesn’t mean we can’t decide to go a different route and explore different tool suites etc
Ultimately the QE’s drive the approach and requirements with the support of the Product Owner/Engineering Lead, often times we need to secure funding so thats why PO/EL support is crucial.
Hi @forestgeeks. In my org, we have about 20 squads working on very different products. We have multiple guilds, or communities of practice as we call them. I look after two of these, one for test engineering and one for SDETs and they both meet monthly.
The SDET one is the most mature and is the most successful in the org for attendees and content. It meets monthly and collectively agrees the standards we adopt. We aim to have some consistency across products, encourage innovation and exploration while having to conform to a non-proliferation of technology agreement (so while we’re currently exploring K6 for some cool perf testing, if we adopted it, we’d need to halt any further Artillery testing for e.g.).
One of the key reasons it is successful is that we rotate the host. It’s their job to ask their colleagues what they would like to show or ask and cue them up on the day. There isn’t one key person who, if on leave, means the community stuff stops and we bubble up things from areas where the quieter folk are. We consider it a badge of honour to present or demo something and community engagement is one way of impressing at a promotion interview. We consider ourselves to be super friendly, so if a junior is showing something small or something the seniors already know, it’s just as valuable to us.
Another reason is that we get high attendance from outside of QE. The BAs in particular were fundamental in setting our early standards. The software engineers enjoy the how-to-make-it-testable discussion.
It tends to generate a lot of ideas for experimentation or tool building. My most senior SDET ‘owns’ the backlog but the implementations comes from the community. Again, we consider this a huge badge of honour and engagement is widely celebrated.
Celebrating failure is important to us. If we try something and it doesn’t work, the learning from that is highly valuable.
Lastly, although anyone can raise a standards change at any time, we have one session a year dedicated to reviewing these specifically. This lets us challenge our principles and revalidate, adjust or replace them.
Hi Yvonne 
A bit late to the party but I thought I’d add some things here that might be of interest.
I’ve been in my current role with my client for just over 3 1/2 years. In this role, I’m
one half of a platform testing team on the platform.
The platform consists of many different teams responsible for providing different things to teams, for example, there is a team to help with building frontends using specific components, build and deploy to help build and deploy services, telemetry, platform security etc. The platform is also very opinionated meaning that certain things need to be done in specific ways to ensure that all the many teams and services work together as seamlessly as possible. The platform enables teams to focus on building, running, monitoring and fixing services.
The platform helps engineering teams across the UK across 5 digital delivery centres. There are over 134 testers alone spread across teams in each of these digital delivery centres with teams typically consisting of 1 or 2 testers, a few developers, a tech lead etc.
The test lead role is split up into three main areas:
Consultancy & Best Practices
- Providing consultancy and support on all types of testing, collaborating with the test communities across the many different digital teams.
- Providing guidance for example on how to test services running on the platform
- Guidance is derived from the best practices adopted by Digital teams working in each of the delivery centres
Community
-
Collaborating with the testing communities across the digital teams to promote testing strategies and help solve their testing problems.
-
Advising other platform teams of the impact that changes to the platform will have on a development team’s ability to test.
Tooling
Provision of test tooling - where we are the product owners as well as maintainers of what we provide.
- We provide many test tools and libraries for tenants to help with standardisation on the platform. For example, libraries and templates for teams to quickly be able to create a journey that can automatically run aXe or ZAP checks, or another example would be helping to quickly create performance test suites using Galing.
The tooling we provide is reviewed often as is our guidance. It helps teams to focus on building/testing and not so much on worrying about what tools/languages etc to use.
All the best,
Viv