Gary Hawkes | Comments

Great conversation. Engineering often get look at as the sole responsibility for shipping faster. But when we step back we realised that engineering can only go as fast as every process from Product to the customer will allow. I think Quality Engineering and Continuous Quality practices, will be uncovering the friction in each discipline and influencing the discussions on how we reduce unnecessary friction or manage the friction we can do nothing about, better.

100% support. I haven't even completed my first year but I've been able to extend my membership by contributing articles, course content etc. That's an easy sell to bosses, as long as we put the work in. Professional membership has changed me for the better- personally and professionally! 🙏

Brilliant article. Over the years, my QA team had reduced from 13 to 4. We have had to react and do things differently as the luxury of lots of dedicated resources has gone. This is an inspiring article that will help me tackle that, so I've saved it. Thanks for sharing 🙏

You know what, I wasn't sure when I started to read this as to what new things it will open up...BUT as soon as you brought in the ISO and IEEE standards amongst all the other sources, this is a really thought provoking read. Are the industry standards keeping pace with Quality Engineering practices? Which are way off the pace. Genius Ady! 👏

I used to have a whale mug where the handle was in the shape of its tale. Whilst I admired its accuracy in design, fish tales are not exactly designed to be held.

I've established the principle to "politely" not wait to be invited by product and project people and start influencing them as soon as I can. For example, with product people I track when they create stories. I can either wait for the refinement sessions or I can as the leader review their stories searching for the "why", ambiguities, untestable AC's etc. I'm happy to brainstorm any ideas with you if it helps 😁

Hearing what you said about influencing developers, I think you're on the right path. Its no different to influencing outside engineering.

The advocation to those outside QA is tough. Its not a thing that gets solved, but it is possible to improve it but speaking their language. If I can help with advocating outside QA I will 🙏

😂😂😂😂

Love the way you framed this as cognitive load is problem not always acknowledged as you indicate. But when you list the symptoms for overload, I can see a lot of testers (including me) going "hey, thats me!". Great work 👏

I love the reference to what a customer thinks is an issue is not always what testers think is an issue. I think thats why its so beneficial to get people into QA/QE from support, dev, product backgrounds as that really powers up the perspectives of what quality is.