Recently, there are fewer companies with dedicated testing teams serving several development teams. Most likely this is related to financial issues – not every company can afford to have a team that deals exclusively with testing and everything related to it.

Basically, now everyone prefers to work on Agile and Scrum, where all team members are gathered together and are working to complete everything planned in the sprint on time. In such teams, testers, in principle, may not know what their colleagues are doing in other teams, because their areas of responsibility have little or no overlap. All this may be not bad, until it comes to organizing automated UI testing and everything related to it: planning, designing, developing frameworks, implementing tests and supporting.

Perhaps the main problem is that not everyone understands that automating UI testing is a separate project that is developed according to certain requirements, and to implement them you need to use a certain technology stack and use developers with relevant experience. Of course, there is a big emphasis on testing:

• requirements must show that the product is developed specifically for testing
• libraries and tools developed specifically for testing should be used
• developers must have experience in testing and developing test tools

Obviously, not all developers like to develop and run tests. Such tasks are performed reluctantly and sometimes with poor quality. So why should they also be loaded with automation via UI?

Distributing automated testing between teams, we begin the development of two different products (formally with a different set of requirements and goals). In this case, there are questions about the distribution and prioritization of tasks in the backlog and areas of responsibility, which requires more effort on the part of management, synchronization of work and professionalism of specialists in resolving conflicts. We also get developers who perform test automation tasks, instead of which they could develop a product.

It should be noted that it is much more difficult to solve global tasks under the conditions distributed among different teams of resources. The task of testing what the team is developing may remain unfulfilled for a long time. The reason for this is the lack of time. In the end, you communicate with the Product Owners of all the teams, prove the importance of your task and look for someone who has the resources to implement your request.

Therefore, it would be most logical to select a separate team with an experienced automator as a Product Owner to work on automating UI testing. It may seem expensive, but is it more expensive than distributing this work among different teams? It seems that in the end the costs will be equal.

But what if the main development phase is completed, the implementation of new functions is minimized, and the project is temporarily transferred to maintenance? In this case, the content of a separate team will be costly, as well as the content of several development teams.

Summing up, let’s say that there is no universal answer on how to optimally organize the automation of UI testing. Everywhere and always there will be pros and cons. Therefore, it is best to act on the situation on the project. One of the opinions is that the work, firstly, should be done by specially trained people, and secondly, it should be enjoyable, only then everything will move, and not stand still. That is what will be the key to the success of any project.