What’s one way you’ve seen responsibilities for quality change?

Discussions
, , ,
1

Testing (or Waterfall testing) used to happen at the end of development, in the days of the Waterfall model of software development. But over time, many teams have changed how they think about quality and who is responsible for it, and when testers get involved in the process. We have heard this expressed in many ways, such as shift-left and shift-right.

In some teams, testers still focus mainly on finding bugs. In others, they are leading automation, joining story reviews, shaping pipelines, or coaching developers, and others on testability and product quality. Titles have changed. Team habits have changed. Responsibilities have moved. That’s why 80% of testers identify themselves as Quality Engineers.

We want to hear your experience of that shift. Whether you’ve seen it firsthand or heard stories from others, your insights can help show how quality work is changing for others in the MoTaverse.

So, what’s one way you’ve seen responsibilities for quality change in your own work, or in stories you’ve heard from others?

In your reply, you could talk about

  • Tasks that moved

    • Did something that used to be seen as “just for testers” become shared across the team?

    • Have testers taken on new tasks that didn’t used to be part of the role?

  • Mindset shifts

    • Have you seen people think about quality earlier, such as during planning or design?

    • Did a change in title, such as QA to QE, lead to a change in how others treated the role?

  • Team habits

    • Did collaboration change, such as more pairing or shared ownership of testing?

    • Did new tools or processes, like automation or pipelines, change how people worked?

  • Impact

    • What effect did these changes have on how your team works or how confident you feel in the product?

    • Was it a smooth transition or a difficult one?

I look forward to reading your stories!

3 Likes
2

I know this is a bit weird but I want to answer my own question to see how others compare with my experience.

Having been around a while, approx 23 years now, I began in a silod team, with software ‘thrown over the fence’ and formal feedback only. I once was ‘told off’ for speaking to a dev and, quote, “wasting their valuable time!”

But I’ve also been in environments where the whole team collaborated on development, bringing their own skills to a concerted effort. So much better for so many reasons. So here are a few ways I’ve seen changes.

  • Definitions of ready and done framing what needs to have been done for software to move through the SDLC.
  • Testers learning more about usability and UX through interacting with design and ideation.
  • Requirements reviews, backlog refinement and 3 Amigos sessions are becoming more standard.
  • More opportunities for questions, both from devs and testers.
  • Less surprises and more consistent software deliveries.
3 Likes
3

Callum Akehurst-Ryan from LinkedIn

For me anyway, the primary shift has been away from doing and more coaching others into picking up quality thinking. With that has come more of a generalist viewpoint for knowing about quality, so a really wide lengthening of skills across all quality aspects.

3 Likes
4

My day in the life of a quality coach compared to a tester looks a lot different for me now. When I started out as a tester 9 years ago my job was mainly analysing requirements that had already been written, writing and running test cases, writing bug reports and generally trying to ‘break the system’.

Now I use those skills to ‘build quality in’ to the system. It’s definitely given me more space to engage with product, design and other stakeholders outside my team. We write requirements together, we decide what to test together based on the quality attributes they most care about and more often than not they join us while we’re testing (because testing at the end is still important, you just find fewer issues at the end).

When I was a tester I could look back at my week and say I analysed x number of tickets, I wrote x number of test cases and raised x number of bugs. Now I look back at my week and say ‘How many times did I ask a question that caused someone to respond: Ah, I hadn’t thought about that’.

As a tester I worked almost exclusively by myself and if I did work with someone else, it would likely be another tester. Developers were intimidating to me! Now I join calls with developers as they’re coding and encourage TDD, suggest ideas for tests or help clarify requirements. I pull in design or product if something isn’t clear and encourage collaboration across all disciplines.

One of my mantras for any team getting used to a quality engineer or coach is: ‘If I’m testing something by myself, something has gone wrong somewhere’. I’m more than happy to test but the whole team should be observing and learning from that. There is far more pairing and ensembling across disciplines than when I was a tester.

It is so joyful when I see a developer doing some exploratory testing or when product/design collaborate directly with developers (skipping out the testing and raising bugs bit in the middle). It’s allowed me to focus my coaching efforts on the testing skills that are actually needed by the team rather than blindly testing everything.

7 Likes
5

I’ve seen testing/QA take on a lot of different responsibilities, and rarely shed any.
QA positions often bundle together: defining the quality strategy; accessibility expertise; code and maintain automation across the stack (E2E, API, performance, unit); talking shop with product; collaborating with design on UX; communicating with business about the customer; coaching them all on testability; and leading other QAs and chipping in with the manual testing.

On the flip side I’ve spoken to some people in amazing roles who are actively helping to share those responsibilities out. Like Callum said the shift in coaching others is also happening.

I’ve been in both situations, and I much prefer when we’re aiming to make quality a shared goal through empowering others. So hopefully this change continues.

5 Likes
6

One important element I see is the testing mission.

Are you testing to verify or testing to learn?

The former tends to have a bias for scripts and the latter for experimentation and investigation, however the difference is significant. I have a strong preference for the latter but it can be a hard sell and in my experience is a massive mindset shift, probably the most important one I see in testing as a whole.

The involved early, close collaboration and getting more technical are generally a given these days.

Switching bias from known risks to unknowns is closely linked to that testing to learn idea.

That technical side will go further, if you are not doing local builds even for exploratory testing its likely you will be missing out.

Many of the testers I work with picked up dev ops activities, as a tester we can help accelerate the whole team, that carried into dev ops. I big factor in this was often testers were not full time assigned and had gaps that they could use fleshing out basic automation or switch to another high value activity that the team needed.

AI will likely change things particularly for the testing to verify model, Agents can plan, automate, fix automation now but again you benefit more from code access than you would otherwise. Perhaps it could end up like leading an orchestra of agents.

Testing to learn will also change but AI is not so focused on this yet as far as I can see, however with non deterministic systems perhaps highly technical testing to learn models will reappear more.

I’ve never liked the QA title as we never really did that with a tester hat on, I have done it but only because I’ve been a developer and a PM before and had that broad influence to change things so I will help the team create quality plans as opposed to test plans.

In all the title changes and broaden contribution, my highest value likely remains in the discovery of things that could diminish or opportunities to enhance the product for the benefit of both company, customer and end user. So yep I still stand by that finding bugs is what I do and what I enjoy doing. I put it a bit like fishing, lots of other things I can help with steer the boat, monitor the radar, check the weather patterns to guide where we go which are all useful things, but I want to fish and catch fish.

4 Likes
7

Collaboration has definitely improved and changed.

We had Slack before COVID and the shift to remote working (before that Skype) but as it’s become more essential, it has made everyone more available. I was no longer the tester in the server group but the best person to ask if anyone had questions on testing & quality (and they did!). There’s something easier about pinging someone to say “do you have a min to chat about introducing network loss?” than having to do to a desk, hope they are there and then interrupt what they are doing.

Further to this, tools like Mural make collaboration easier. This in turn makes engagement with quality easier. 10 years ago I wouldn’t have expected to have developers caring about test strategy but by using these tools to collaborate on it, people have been engaged and taken ownership.

5 Likes
8

I suppose the initial shift from the waterfall/v-model practices was in agile models. However, in my experience until very recently there was still an argument to say that teams were still asking test to”test it at the end” but in sprints. So the only thing that changed was shorter cycles, but the same practice was still being applied. It improved quality but there was a limit as to how far you could push it due to the fact of issues were being introduced way earlier than just dev.

Where I’m seeing only very recently thanks to the MoTaverse is the advocacy of quality engineering and quality coaching, is that engaging those stakeholders from the beginning to the end. So now I’ve been coaching my teams to coach earlier on focus on prevention working with customer success and product teams. But you have to stick at it as not all of the stakeholders are ready to engage, especially if they see you as the test team. You have to earn that trust to engage.

For example, we’ve been prototyping a product and the initial view was “its a prototype you don’t need to test it”. So rather than argue, we suggested we have a look once you have something you want to put in front of customers for feedback. We used a couple of exploratory techniques and gave not only a list of issues, but a list of questions and ideas which really got products attention.

We then moved to the next prototype phase and this time they actively sort our opinion, still falling into the mindset of features 1st, quality 2nd. We did the same technique more frequently and again it started to have an influence.

Where we are now is we are going through the “productionising” phase but now we are influencing before devs commit code and as an engineering team we are questioning the product team as a collective to make sure we understand the business benefits of the features before we develop them.

So moving in the right direction, but coaching just doesn’t stop. It takes work to keep that influence there, because if you don’t, no-one is going to wait for your feedback if you don’t offer it but one day it’ll become the norm. :crossed_fingers:

4 Likes
9

As an alternative thinking I’m throwing in the question “Have they changed at all?”
I’ve been thinking about this a lot recently and I feel that observations by quality engineers might have not changed at all. What could be shifting things is the word of “quality” thrown into the mix. I remember for example when i first started in software testing I was included in line with the dev teams and started early. That hasn’t really changed. Also continuous improvement has not changed - we are trying to get better. Maybe the technology is helping us there?

Also, how far back are you thinking? How are you defining change - for the majority, some companies, a few? I don’t know that many companies for example that use the term “quality coaches” but know there are companies that use that.

4 Likes
10

also to throw something in there….in my experience quality engineers are still software testers masked with the word quality….they are still doing typical testing tasks like functional, regression, exploratory, continuous improvement, so overall whatever we call ourselves doesn’t distinguish a difference in my opinion with the core tasks being the same.

11

I as a tester have taken on managing coordination between teams so they are better synced.

The dev teams have been made to verify 100% coverage of use cases so no time is wasted bug fixing cycles.

Having empowered discussions around “what else can be tested that might be affected” the team conversations feel more collaborative where test cases are exchanged between testers and devs.

What’s still missing in my life is shift left testing and having my input used earlier on in the requirements gathering process. It happens but not to the extent I want it to be.

Silo’d work processes have always lead to blame games with the end result being established that “tester should have looked at this”. This just goes to show how misunderstood our line of work is.