Quality assistance - what does QE do during stand-ups?

We are trying to introduce this concept of Quality assistance (Atlassian, Canva, etc. use this model) where devs do their own testing for new features while QE’s guide them and work on bigger features for automation, non-functional tests, observability, beefing up regression suite.
The Devs are quite receptive to this concept but the QE (my team) have a bit of apprehension (as they feel like they have less work and feels like they get to be on the sidelines instead of being in action).
We’ re trying to create something like: What is a quality coach? (Definition & nature of role) but it looks very holistic and no specific tasks / activities that would require QE’s providing updates on stories / tasks on a daily basis.

1 Like

There is no single answer to this, there are many flavors and aspects of what will work for you.

Here’s some of my experience that may give some insight into what did and did not work for someone else.

Quality Coaches. Coaching itself is a deep knowledge area that should not be underestimated, you may find only one or two of your testers are suitable and capable for coaching, I would recommend against trying to turn all testers into coaches.

I like teams where developers own all the scripted testing, they do test all their changes and they usually own the automation . In 25 years this is the most optimal model in all but very few cases, and those cases usually created a massive regression risk they cannot get out of. In this role as a tester my focus is much more on discovery and potential product risks/values. In defining stories I contribute by asking a lot of business risk questions this is still testing in my view and testing with a discovery focus can be down continually even if you do not have a product available to test yet. On product testing its usually session based discovery focused investigating specific potential risks and things others may naturally miss even if they have tested.

In this model I’ll also test ideas for AB hypotheses and test analytics, data and customer feedback for things that can improve and guide the product forward. I can also contribute and support the developer testing and automation and even run test knowledge sessions as required so opportunity to apply those coaching skills if you have them.

So in the above model I was likely able to do all of the Quality Assistance aspects but also remain a tester even though my test mission changed from the old school script focused testing. This works particularly well if there are a lot of potential risks or rapid feature rollout.

In other projects I’ve seen a different route taken and a lot of automation activities went to testers and developers tested their own stories. I am not so sure I’d call this quality assistance but it is a model out there. I’ve seen this working where regression risk is the primary risk and there are not a lot of other risks deemed worth exploring.

Another model I’ve used is sort of a combined tester and sys ops, basically covering many things that accelerate the team as a whole, CI, environments, system monitoring, release etc. Its fairly broad but does suit some people.

Either way you need to align on what your role’s mission is, you may find you are trying to solve the wrong problem or their are a lot of personal bias’s at play. A massive common bias is some developers do not like testing so will naturally push that to someone else even if its the most inefficient thing to do.


Pretty much all that @andrewkelly2555 covered, but mainly those 2 last points. I’d be wasting time trying to rephrase those last 2 points Andrew made as my own words.

Your big risk when developers do their own testing is that leaves nobody responsible for integration testing and “upgrade” testing or performance and UX. It’s a risk. So you will probably find you have plenty to do, but not everyone fits this role well.

1 Like

To answer specifically “what does QE do during stand-ups” when devs do their own testing, I would suggest having QEs turn the activities you mention (automation, observability, etc.) into sub-tasks of the tasks they relate to or into separate tasks which are also put on the team’s board. That way they can be talked about the same way the QEs are used to.

Also, if they’re indeed guiding the developers and not sidelining themselves then they could talk about the code reviews they need to do on the tests or about the pair programming sessions with the developers or about the testability issues they’re resolving.

Personally I like it if QEs also get involved in early pair testing with the developers and in collaboratively defining unit and/or integration test scenarios before a line of code is written, but you may feel this violates the principle of developers doing their own testing.


I checked with the QE’s and I gave them some options and this looks like a keen focus for them to learn and have a go at. Thanks for your responses. It good to learn from each other this new way of working.

We are onto the Quality Engineering path as well and I definitely understand your struggles.
We did however include up-skilling into automation, since we had mainly manual QA engineers but Automation is merely a tool, a small part for the role of Quality Engineer that I imagine.

One of the best resources I found on Quality Coaching is from Anne Marie Charett, she is a pioneer in the industry.
Here is her blog/live book (it’s subscription based but so affordable) for example this post What is a quality coach? (Definition & nature of role)

Also, don’t know where you are based but I am in Europe and the concept of Quality Engineering, let alone Quality Coaching is very new, so I found it very useful to check job ads for Quality Engineer on LinkedIn in Australia to see what usually is expected from this role, since for Australian job market the concept is not that new. :slight_smile: