Welcome to the 282nd issue!

Today, I want to highlight the two great articles on quality leadership that came out recently:

• Quality Leadership in Quality by Brijesh Deb
• Bottom-up or Top-down? by James Thomas

There are some great insights I can relate to after being in a leadership role for a few years now.

So whether you're an aspiring leader or want to influence change within your team, this might be worth checking out.

Happy testing! 🙂

Dawid Dylowicz

There's no golden rule when it comes to the amount of test documentation you should have but Madhumini Kodithuwakku provides good guidance.

On the other hand, George Ukkuru asks: Still writing Test Plans no one Reads?

Mike Harris explains how well-written requirements as part of the shift-left testing activities can lead to more effective testing further down the line.

Moreover, Jesper Ottosen provides more context about The next shift-left: Compliance.

With a lot of focus put on automation and AI, Maaike Brinkhof reminds us that we can't forget about the importance of exploratory testing done by humans.

Additionally, Will Robinson came up with an interesting way to explain lessons learned in testing — Relativity, Reality, and the QA Engineer Who Knew Too Much.

Traditionally, testers were seen purely as the safety net involved towards the end of the SDLC. However, it shouldn't be like this anymore, and Ganga Pandey correctly points out why.

Similarly, Higor Mesquita explains How Communication Between QA and Devs Helps Avoid Rework.

There's a saying that a picture can express a thousand words. Jitesh Gosai demonstrates that with a new model for mapping team knowledge gaps and improving quality.

If you're looking for an assessment of quality and test automation practices, Aditya Kappagantula proposes a scoring model based on the test pyramid and process maturity.

Naveen Khunteta shares the story of learning test automation and provides great advice on how to do it effectively.

Furthermore, Shakti Swaroop demonstrates that with an example of going From Hobby to AI-Augmented Testing: My R&D Journey with Selenium/Appium, and Java.

More code generated by AI means more potential dangers in software. Francis Bourre wrote a very detailed explanation of why it's important to rely on test automation for safeguarding.

I liked this article by Geetesh Laddha because it comes from a developer's point of view, describing how necessary a risk-based approach to creating software is.

Similarly, Shneha Paudyal advocates for holistic approach to quality because Automation Alone Won't Save Your Product.

The test pyramid is considered a default test strategy, but it may not always be the best approach. Lucas Fernandes shows a few examples where focusing on higher-level tests might be more beneficial.

Moreover, Peter Billen from Google wrote a comprehensive article about Automating everything; and why metadata matters

Interested in analysing your flaky Cypress tests? David Ingraham wrote a step-by-step guide to building and integrating it.

Playwright has some great reporters built in, but sometimes you may want to get more clarity in your test steps. Here's a handy tip by Chris Enitan on how to achieve that.

If you're interested in running Playwright on several browsers, you may consider Thananjayan Rajasekaran's suggestion to set up a browser server in the cloud.

From my own experience, product managers can be great testers. In this 22-minute overview, Daniel Knott offers great advice on how to do it well.

Wondering about the challenges in testing AI? Nikita Sidorevich invited Michael Bolton to share his thoughts, which turned into a deeply insightful hour-long talk.

Also, Karthik K.K. recorded a helpful overview of The 100% EASIEST Way to Test LLMs & AI Agents using DeepEval.

AI assistants... 😂

Thanks for reading!

If you enjoy this newsletter and find it helpful in becoming a better tester, please feel free to share it with others.

Dawid Dylowicz