Impactful process improvement within the quality team

Hello Folks- Hope doing well. I am just curious to know if you have made any new process (QA processes) improvements and that had a big impact on improving the quality of the software. i.e: weekly bug scrubbing we implemented and it helped in clearing the backlog.

Look forward to hear back!

Puneet A


That’s an interesting question! I’m also looking for more inputs.

  • One of the things we implemented to shift the testing earlier while collaborating with developers
    The developer starts working in a separate branch the testing need to be done in parallel and raising bugs in that branch (visible only to that dev-tester) then give the ok to dev team to merge it to master when they are more assured. But be sure to stay updated with master !

  • testers can start designing their test cases practicing BDD earlier before developers start that better understanding can lead to better testing and thinking about more cases before even receiving the final version that’s going to be released


My nr 1 is still Mutation testing, when devs like to write unit tests (or have to) but don’t really know what to test for… I introduce mutation testing so they can get up to 100% mutation coverage & 80% code coverage.


Yes, I agree to this point that creating test cases at the earlier stage leads to better testing and finding more edge cases for testing.
Also tester gets a more clear picture of how that feature will work with the entire product.
We have implemented this technique into our one product and we have seen some remarkable results for that.


Implementing session-based test management helped us focus on risks and increased the time spent interacting with the application and anything beyond software and hardware that is also part of the product. This maximises chances of finding problems that matter.
It also helped with continuous improvement of the testing process.


How easy is mutation testing really, when you don’t have a code coverage tool to validate against as a way to know you are close to the goalposts? Is it worth prioritizing a code-coverage tooling Epic (even if my PO will probably not agree to doing the work).

I’ve never pushed mutation testing, but I’m sure a few of our devs do use it to experiment, but once again not having code coverage tool, it means less feeling of value I guess. Myself I’m at the end-2-end level, and it feels evil to only be doing the UI level testing in the testing pyramid.

Mutation testing can be used aside from code coverage. You don’t need a fancy code coverage tool to use mutation testing. Mutation testing is just there to test your unit tests and it points out which are bad and which are missing. The mutation coverage doesn’t say anything about your code coverage either, it’s coverage means that you have written good unit tests not that you are covering all parts of the code itself.

It’s super easy to implement. imho Mutation testing > Code coverage because you can write unit tests which test absolutely nothing. I don’t really ask for their code coverage anymore now that I think of it, I just ask if they have 90%+ mutation coverage because then I at least know they have written decent unit tests :stuck_out_tongue:

1 Like

Okay, I’m going to gripe a bit about early testing. I hope my Marketing team don’t read this forum.

We have been asked to do some re-skinning, and were given “wireframes” for all the screens that need changing, but the wireframes are in Adobe Cloud, and the person making them has to of course password protect these. As they update the wireframes with final versions to include the correct re-skinning colours, they have to remember to publish the new file in the Adobe cloud as a new file.
Basically marketing don’t get “agile”, because they have not been sharing the graphic designs with any of the testers. In part this has been caused by marketing not being the same person along the chain, and actually being multiple providers, which ads risk.

How do Marketing expect to check that their designs got delivered? It’s the QA’s job to check, but QA need to be in the loop every time the designs change. Perhaps some parts of your organisation are not ready for this left-shift. I think left-shift also entails a kind of communication and a kind of transparency of process that not everyone is good at implementing, much less explaining. It’s hard.

That is brilliant. The cost of maintaining a code-cover tool it a pain, but it’s more valuable the bigger you are. I just never thought about mutation as a way of creating “production-grade” tests that give you the same confidence a code-cover tool often does. I really hope I can come back to this topic if it comes up in my team later.

1 Like