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?

  • That's why automation is the developer's job. It requires development work. Dec 7, 2016 at 13:56

4 Answers 4


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.

  • +1 for "if stories are becoming heavier in QA lane then Devs have to step up and clear the QA lane" - this is key. Not just by writing code, but by sitting down and doing that tedious and long winded environment setup (and hey, if they are actually having to do this themselves, you might suddenly find a few tools get written/some redesign happens to make this easier.)
    – testerab
    Nov 7, 2016 at 10:44

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).

  • 1. Improving self - i agree to what u said; but what about the fact that the expectations from QA in such a team to be able to do all of the above and only then be able to match the performance criteria? Shouldnt then, there be either more sensible distribution of work and better planning instead so as to have QA be able to do all the above at a doable pace?
    – shanianp
    Feb 7, 2015 at 1:26
  • 1
    It might be possible, maybe more likely in different company. And you need those new skills to get that better job. Feb 7, 2015 at 1:30
  • I did not understand
    – shanianp
    Feb 7, 2015 at 1:39
  • Upvote for the free time piece. I learned automation in my free time at my old company and ended up drastically changing their culture in QA. I also built the automation suite in my spare time and reduced the total amount of hours I had to actually 'work' so I could study QA further
    – Paul Muir
    Feb 9, 2015 at 14:19

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.


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.

enter image description here

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.