You’re an organization that has moved to the agile methodology and after a period of time you have figured out that you need to implement automated testing in order to become truly agile, if so, don’t fall into the standalone automation team trap.
Many organizations do the proper research to determine what they need in terms of automated testing, what tools best fit them, the skills needed, but then they make the big mistake of creating a standalone automation team in an agile environment. They quickly forget one of the tenants of the agile methodology is that we focus on teams and no longer silo individuals by their functionality, if QA is no longer strictly responsible for quality then why would there a separate automation team responsible for all automation testing?
There are three distinct problems with having a standalone automation team in an agile environment, first the team will never be able to keep up with the test case maintenance because they will always be automating after the fact. What this means is the standalone automation team will be creating the automation tests after the agile teams have finished and then will create the tests and push these tests to the regression suites. The problem is that an agile team may make changes to the areas where these automated test cases were written and nobody will know till the regression test are run, thus always putting the standalone automation team one step behind the agile teams.
Having a standalone automation team also creates another issue with the basic agile tenant of testing the software during the iteration and having releasable software at the end of the iteration. Functional automation should be done by the agile team as part of the iteration. If an organization is using the correct tools, following the correct automation method (Page Objects) and using processes like BDD there is no reason not to be doing the automation during the iteration. By having the agile teams create the automation during the iteration you now fix the problem above of being one step behind with test case maintenance because of BDD’s concept of executable acceptance criteria which should alert the agile team to any test cases that may need to be updated/changed in addition to any new test cases that need to be created.
The last issue with automating test cases after the fact with a standalone automation team is how can you have a truly automated CI/CD process if the automated test cases are built after the agile team finishes their work? This generally means that in addition to any unit testing that was done, the teams probably did manual testing which would make it impossible for the entire CI/CD process to be automated.