How to write automation when test engineers are constantly pulled to do manual testing?

Question

The scenario:

1. Scrum team consists of more developers than testers
2. Stories revolve around 80% of testing tasks

3. Why so much testing?

   • There are asks of E2E testing for several user flows; regression testing for some on E2E level
   • most of which changes at upstream / UI so that automation is not an option always; component level new features being added and need feature testing; automation of these tests; Documentation
   • because the areas of testing and steps often encompass new domains and complicated environment setups
4. Though ideally the product manager would let add technical user stories for QA too, most of the times, such automation backlog stories don't get prioritized over other testing tasks

Due to the above, most of the times, the QA need to concentrate on a lot of manual testing. And hence, automation goes to a backseat. Sometimes the features need to be pushed out so much soon, that the automation gets a backseat.

Question 1: In these circumstances, how can a team manage coping up with automation?

Question 2: One of the things we did was ask our Developers to help complete automation (on a feature they haven't coded for). However, two things happen due to this:

1. QA does not get a chance to improve automation skill set
2. As QA does not do automation anymore, (the criteria of performance reviews) the QA gets negatively impacted during the evaluation

How to deal with this contradictory situation?

Answer 1

You think it's impossible! Not really. Here is how to accomplish this. Short and sweet.

1. QAs are involved in pointing the stories. You decide in sprint planning/refinement if any automation needs to be done on the story. Everyone including QAs know the effort it's going to take. So, you point them keeping that in mind. And, you mention that as an acceptance criteria that automation needs to be done.
2. Technically for all new features you should be writing E2E testing and if so you don't need a different regression suit because one suit can be run on a regular basis(through CI).
3. "because the areas of testing and steps often encompass new domains and complicated environment setups": You shouldn't be writing any automation tests that cannot be fully automated. So, this scenario keep only manual and create documentations. And, I forgot to mention, when you write automation that's your test plans, no need to write manual tests plans and you concentrate fully on automation for that feature. There are plenty of ways to generate reports through tool.
4. QA cannot have a backseat: Because there is technically no designated role in Agile as QA. All of them are team members and if stories are becoming heavier in QA lane then Devs have to step up and clear the QA lane. And, if you push the stories out without giving QA enough time or QA cannot finish them and you want them to be out, there is, of course something wrong with story pointing. They are not pointed right.
5. Choose an automation tool and language which go with the application architecture. Such as select Java dependent tool(Selenium with Java) if you are a Java shop so that if QA falls behind Dev can easily pick up and finish, re-patch or write some automation tests cases. This scenarios will also cover the improvement of QA's automation skills since they can easily take help from devs for writing code and such. It dramatically speed up the process.

Edit: Make sure the proportion of QA and Devs are right otherwise QA will always be behind because sometimes writing automation is heavier than writing application.

Answer 2

If your management is so focused on short time returns that it will not invest in increasing your skills to improve your productivity - you should do it anyway in your own free time. All tools and documentation are free, you just invest your time.

Of course your progress would be slower, but after some time you should be able to show some results, proving to your managers that giving more support to test automation is good investment for company. Or if not, you gained skills which you can apply in a different company with better future (for both company and you).

As the saying goes: if you cannot change your company - change your company (meaning: vote with your feet, work for another one).

Answer 3

You need to redefine what the definition of "done" is for a ticket. A ticket is not complete until manual testing, documentation, and automation are done. Project Managers might get upset at first but it's not hard to win an argument when you tell them the increase quality means.

Answer 4

The Scrum guide does not recognize a separate QA role.

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

It is pretty nice to have someone with a lot of testing skills in the team, but this person should try to work with the team as any other developer, as the quality is a team effort not a personal responsibility.

I would suggest the following:

• QA/Testers start programming with pair programming sessions, this to become a full team-member in the long run.
• Developers start writing automated tests before coding, read these pages about Technical Excellence to get an idea about why and how.
• Developers also do manual exploratory testing (maybe start in pairs again to get them onto speed)
• Make quality a shared team responsibility.
• Automated testing is part of the definition of done and not something you put on the backlog

Your first goal is to make sure they do not rely on you as a tester, spread the skills. Then start to integrate yourself as a developer in the team.

The ultimate goal is to become a T-shaped or even better a PI-shaped developer, where your expertise might be automated and manual testing.