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!
Regards,
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 
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.
The organization where I am working is a full-fledged QA company and if it is one thing that has helped us yield the best output is adding the testing factor throughout the software development lifecycle.
It means from the moment a project is initiated; we make sure that everything right from the requirements to the development process must be thoroughly tested at the developer level to avoid any errors affecting the end outcomes.
Besides, it has even helped our testers to create a smoother end experience without putting any extra effort into complex test suites.
Looks interesting @kanikavatsyayan and itās like you are building quality IN 
Can you share more ! What are your quality objectives and how is the commitment of.the whole team toward those objectives?
How everyone contribute to quality?
Hi,
I have very good personal experiences in shift-left testing with āearly Model Based Testingā (eMBT) at different clients. eMBT is a software testing approach that ensures to optimize and speed up the Test Case Design phase. And perhaps more important, eMBT stimulates communication between all stakeholders (business and technical stakeholders) with the aim of getting a shared understanding of the requirements in an early stage of the SDLC. After all, still 35% of all bugs in production can be traced back to the requirements.