Organizing UI automation testing

In recent years it is becoming less and less companies where you can meet dedicated test teams working with different development teams under the same product. This is most likely due to financial reasons because there are not so many companies who can afford to keep a team dedicated exclusively to testing and everything related to it.

Nowadays a majority of software development companies work using Agile & Scrum, where all team members (software engineers, architects, programmers, analysts, QA experts, testers and etc.) are sitting together and doing their best to meet the goals of the sprint. In such projects testers, in principle, may know nothing about work of their colleagues from other teams because their areas of responsibilities intersect not very often or do not intersect at all. It can work fine until we are not starting talking about organizing automation testing and everything related to it: planning, design, implementation of frameworks and tests, support.

I think that the main issue here is a lack of understanding that UI automation testing is a separate project which has to be developed based on “defined” requirements, using “defined” technology stack by developers with “defined” skill set and experience. Saying“defined” I mean a bias towards testing:
  • Requirements has to display that product is being developed for testing
  • Should be used tools and libraries developed mainly for testing
  • Developers have to have experience in testing and development of test tools
It is not a secret that developers do not like writing tests and performing tests. They do such tasks without any desire and sometimes with not proper quality. So why do we need to ask them to do a UI automation testing?

With distribution of UI test automation between teams we are starting development of the second project in parallel (formally with different set of requirements and goals). In such case we are getting issues with distribution and prioritization of tasks in the backlog and also areas of responsibility.In the end it requires a lot more efforts from management, work synchronization and professionalism of individual developers. What we also get is a number of developers doing test automation instead of new features development or bug fixing.

From my own experience it is much harder to solve global tasks in such conditions: “You are creating a critical for automation testing task and waiting when it will be solved. In a few days it is not yet started. You are asking people why and when it will be ready. They answer that they didn't have time for it because they were busy by doing more important stuff and maybe in the end of the sprint they will find time to start working on it”. In the end you have to talk to product owners of all teams, prove them that your task is the same important as their ongoing tasks and find somebody with free resources to implement your request.

In my opinion, the most logical way is to create a separate team for test automation with a quite experienced test automation engineer as product owner. Some of you will say that it is too expensive but I think that in the end it will not be more expensive than distributing work between different teams.

You can ask: "What if the main part of development is done, new features implementation minimized and project is on maintenance?" In this case keeping a separate team will be of course the same expensive as keeping the same amount of development teams for support.

*   *   *

As you can see there is no universal answer on the question about organizing UI automation testing. Pros and cons will always present in all cases. Therefore it is better to act on the situation and availability of resources on the project. Personally, I hold the opinion that the work at first, must be carried out by specially trained people, and secondly, people should enjoy doing it. Only then working process will move and not stay still. 

Comments

Post a Comment

Popular posts from this blog

QA Chapter

There are different point of view on organising a QA chapter. As a QA manager, I see it in the following way. If you ask me ` How  should  QA Chapter look like?` , I would suggest the following structure: Chapter Lead: Person taking final responsibility for decisions Mandatory: 3 QA engineers, 1 BE engineer, 1 FE engineer Optional: Product Owner, Architect, DevOps engineers NOTE: It is very important for me to have representatives of different roles in the chapter, since everyone sees how to improve quality and where to apply improvements differently.  If you ask me ` What  are  QA Chapter  areas of responsibility ?`, I will answer that the agenda of QA Chapter meetings should be based on the following areas: Product quality: Quality of Development Quality of Testing Quality Control Quality of Delivery Visibility of QA work If you ask me ` How are you going to make your QA Chapter performing well?` , I will answer that we will need to define a set of rules and constantly monitor tha
Read more

Leader is not an individual contributor

On many interviews for the leader's role you can hear questions like:  - Who pushed for this change? Who proposed this improvement? Who implemented this approach?  For me personally, leaders should answer in the following direction: - My team! It was a team effort! It was proposed by an individual, but implemented by the team!  Unfortunately, in many cases interviewers want to hear:  - It was me! I did this! It was my initiative!  They want to see an individual contributor pushing for changes and doing mostly a hands on work as a leader. Most likely, in their environment they need such a person.  My point of view, is that leader is a buddy, who can organise, motivate, inspire people. Sometimes he should lead by example, sometimes he should explain your fault one on one, sometimes he should motive a whole team. From day one in his role, real leader should start thinking about finding another leader in his team, to be able to delegate and share work with team mates. Only then you wil
Read more

How to access Extended object properties in TestComplete

Image
UI testing is a very tricky thing. Everything depends on how accurately test tool recognizes UI elements and theirs properties. In this particular topic I would like to tell you how some invisible and not obvious settings of TestComplete can improve recognition of UI object properties. TestComplete with default settings does not always have access to Extended properties of these UI elements: You can change it by going to Tools > Current Project Properties > Object Mapping and check the required component there (if it is supported by TestComplete). After this you will be able to see additional category “Extended” in the Object Spy and access these properties in your test scripts: The only one thing you should take into account is that the designer of the Object Mapping tree was probably drunk or used a very heavy drugs. In some cases it is not enough to check the object category (I spend several days by trying to configure support of our DevExpress XtraG
Read more