I’ve released 17 issues of the newsletter at this point, and I have only posted three times here, so let’s catch up on stuff I love!
Always With the Learning
Each issue will have some blog posts or articles to read. We’re starting out with a series by Maria Kedemo about testability. Four parts, but they’re nicely consumable.
Part 1: Testability Is About People, Not Just Code
Part 2: Poor Testability Is Everywhere — But We Don’t Always See It
Part 3: The Triangle of Perception: Why We See The Need for Testability Differently
Part 4: Changing the Conversation About Testability
Each issue will also have a video to watch or podcast to listen to. As a companion to David’s risk-based testing presentation at our sting this past Monday, here’s a video by Paul Gerrard about risk-based testing (I also like his video about what risk is ).
Laveena Ramchandani and Chris Armstrong wrote about components of testing strategies in this Medium post .
Dan Ashby blogged about creating a new model for testing strategies. It’s quite thorough and an enjoyable read and links back to some older material by others.
Elizabeth Zagroba has a post on Ministry of Testing about using mind maps to clarify testing strategies.
Daniel Knott concisely answers what a good testing strategy comprises in this short YouTube video .
For more interesting takes on the philosophy of strategies, check out the Testing Peers podcast and the Evil Tester’s podcast on the topic.
Angie Jones wrote about automation maturity while she was at Applitools. You may have feelings about this, I’d love to hear them.
Maaret Pyhäjärvi has a fantastic blog post about how she thinks about test coverage .
The Testing Show did an episode about test coverage. It’s a bit different from how we’re talking about coverage here, but it’s an interesting conversation.
Lisa Crispin wrote about what shifting left and shifting right mean in terms of continuous delivery.
And a related inspirational post by Anne-Marie Charrett about testing being like breathing, which should happen all the time!
Callum Akehurst-Ryan and Marie Drake talk about shifting left (specifically in story shaping) in a video.
This is an updated classic: the test heuristics cheat sheet on Ministry of Testing. Initially created in 2006 by Elisabeth Hendrickson, James Lyndsay, and Dale Emery, it got a facelift and an update in 2022 by contributors through Ministry of Testing. Check it out and see how you can use it in creating testing ideas for your own work!
The Heuristic Test Strategy Model by James Bach is a useful model to review when planning your testing. This was updated less than a year ago and comes from decades of his experience.
Chris Armstrong and Heather Reid talk about things every new tester should learn in the Testing Peers podcast . The links in the show notes are a veritable treasure trove as well.
This Medium article by Victor Morais lays out how to tell an effective story in engineering. It’s not specifically about bug advocacy, but he gets to the heart of why it’s important to tell a compelling story when it comes to code.
Nishi Grover Garg wrote about bug advocacy for the Ranorex blog . It’s a solid post about how we can make quality of our products more important.
Richard Bradshaw wrote ten tips for communicating bugs on LinkedIn . He writes from a dev perspective on what’s helpful and what isn’t for getting things fixed.
And a podcast I listened to recently was Stu Day talking about storytelling using metaphors for quality and how it can change perceptions.
Melissa Fisher writes about making work visible in this short Medium post.
If you want something lengthier to consume, Mike Bland has an entire series of posts (24 of them!) plus a recorded talk about making quality visible. Here’s the whole shebang . To be fair, I’ve not consumed all of it (yet!), but it seems like a really valuable contribution to the community.
Richard Seidl interviewed Cassandra H. Leung about making testing work visible. I love how she talks about imposter syndrome and how she’s celebrated work.
This post with an interview with Krystal Lamoureux talks about what it means to bring your whole self to work.
Juraj Malencia talks about vulnerability of engineers and how it creates great teams in this Medium post . Any post that starts out with a Brené Brown quote is fantastic.
The Testing Peers discuss authenticity within context .
Dan Ashby uses the DevOps model and shows how testing can be as continuous as our development and deployments.
Angie Jones talks about automated tests in continuous integration and how to do them well.
Lisa Crispin talks with Ale Moreira, Veronika Pliusnina, and Royalee Martin about holistic testing and how to lead by example and build connections on the Engineering Quality podcast .
SauceLabs has their three big trends for 2026 in this blog post . Spoilers: using AI as a strategic collaborator, unifying the pipeline through shifting left and shifting right, and measuring quality are all going to be important going forward.
Testlio released their trends for 2026 in this blog post . With AI writing code and AI being embedded into our products, QEs are needing to shift their thinking, but we’re not going away.
Joe Colantonio talks about AI and automation trends for 2026 in this short video .
Vernon Richards and Richard Bradshaw discuss the Automation in Testing principles and whether those are still relevant. They follow it up with Automation in Quality using AI . Both excellent episodes and worth a listen.
Vernon Richards also muses on his role with the advent of AI. It’s a good and powerful read, and there’s more to come in this series.
As a precursor to going into alerting and monitoring with us on April 1st, check out this blog post by Sidney Karoffa for an introduction to observability!
Aya Aki looks at observability and the way it helps with quality in this post .
Parveen Khan spoke about observability, including how to use it in exploratory testing, on the On-Call Me Maybe podcast a few years ago. It’s an engaging conversation, and you need to learn from Parveen, she’s amazing.
Although we at SeekWell have been pretty insulated from the layoffs affecting our industry, we aren’t immune to the effects of seeing our friends and colleagues go through it. Personally, I’m a bit jumpier, regardless of how much value I think I’m adding to the company. And I don’t think I’m the only one. It’s scary out there, which makes me feel like I need to do more and more to prove myself here… so I don’t end up out there. And that can all lead to burnout pretty quickly, not because of anything that is happening internally, but because our industry as a whole is going through a massive upheaval. So here are a couple resources about burnout that I hope help.
Stu Day has short-ish podcast episodes on recognizing burnout and preventing burnout .
Nikhyl Singhal writes about the Burnout Paradox in Tech .
Chantal Kapani of LeadDev writes about burnout from a leadership perspective .
Katja Obring talks about how the quality jobs have changed because of AI in this blog post .
Joe Colantonio talks about testing in the age of AI in this (short) news podcast .
Benjamin Bischoff joined David Burns for a BrowserStack Talks podcast about AI and testing.
Something to Try
I have a book recommendation for you!
I read Donella Meadows’ Thinking in Systems: A Primer as part of the systems thinking presentation I did, and it was a powerful book. She approaches systems from a broader perspective than technology, using things like the temperature regulation of a room and population stability as examples.I learned about components of a system, including stocks, flows, feedback, and boundaries. Meadows explains concepts in an understandable way. She defines a system as “an interconnected set of elements that is coherently organized in a way that achieves something (function or purpose)”. The whole is greater than the sum of its parts, and we often talk about systems through their behavior rather than their goals (functions/purposes).However, knowing the function of a system is critical to understanding how it can be altered. Meadows uses the example of a university, in that the university as a whole has the function of educating students, though each element of the system (faculty, the deans, the students, etc.) may have other goals that may or may not be consistent with the function of the university (like getting tenure, fundraising, growing as a person or just having fun). If you don’t understand the goal of a system, messing with it will get you into trouble.Meadows talks about leverage points as well, small to large changes that can have an outsized impact on the system. Changing the parameters of a system might sound really good, but it might not have the same impact as changing the elements or the rules of the system. The book had me reconsidering about how I think about systems, and I appreciate the thought that went into the content. Systems thinking is something we all need to consider in our work, and though it may sound like we do this intuitively (which, to some extent, we do), learning about it formally can improve our ability to understand the systems we work with daily.
And another! I finished reading Build by Tony Fadell, and there were things I enjoyed about it and things that didn’t resonate as much. What really hit me was the importance of knowing why we’re building things and doing things, the importance of telling a compelling story around our products. It also drove home the need to build things with people you trust and are excited about building with. I think we get some things right here, and we have opportunities in other ways. A lot of the book was about founding a startup, and it ended with when to step down as CEO and when to sell. That stuff wasn’t as powerful to me, though I suppose it’s relevant for everyone to know when it’s time to pursue another project, team, or company.
And another! I’ve started reading Stephen Wolfram’s A New Kind of Science , which deals with quantum theory and quantum computing. So far, it’s fascinating in how it can be applied to many different disciplines . It’s a beast of a read, though, clocking in at 800 pages of content and another 400 pages of end notes. It looks like the whole e-book may be online at the link above, and if you can deal with the ego, it’s a great introduction to quantum.
Memesis
This happened the other day while I was trying to create a new Zoom background, hahahaha. If you have testing-related memes, cartoons, or interesting bugs in the wild, send them my way for inclusion in a future newsletter!
A classic (more here !):
Get That Brain Moving
James Lyndsay’s Puzzle 31 is a great one to try to figure out rules. See if you can condense the rules to a classic tweet-length statement.
Some of you may have about the Triangle Problem from Glenford Myer’s book The Art of Software Testing, first published in the ‘70s. There are many iterations of it available online, but the one I’ve come to use in training is this one . The responses are a bit snarky, and putting in half a million digits of pi will bring your machine to its knees, but it’s a fun exercise to see how efficient you can be while still covering many bases.
Another black box puzzle from James Lyndsay, see if you can figure out the rules!
This is an oldie but a goodie . See if you can find all 18 things to check! If you want another exercise in this series, I like number 6.
Another oldie but a goodie: Userinyerface ! See how quickly you can get through it. Share it with your designers to really horrify them too.
Here’s a list of brainteasers commonly asked in engineering interviews with answers. See if you can figure out the answer before scrolling to it (unfortunately right below the question).
Odds and Ends in Engineering
An open source project has a page of cursed knowledge about things they wish they hadn’t had to learn. It’s a useful format, as we have learnings outside of sev retros as well, and they could be useful to track.
Time is tricky, from daylight saving time to time zones to leap years (and leap seconds!). This post about time by Noah Sussman pops up every couple years, and it’s really useful as we consider all the ways getting time wrong can have an impact.
This page about failure in complex systems is something worth returning to every once in a while.
This article about expert generalists , why we need them (especially now), and how to train them, is quite an enlightening and inspirational read.
This came up in our OWASP stuff, but in case you haven’t seen it, check out the Big List of Naughty Strings . ‘Tis the best resource for finding things to blow up input fields.
This quality of life TED talk by Manoush Zomorodi about needing regular movement really resonated with me. No, a standing desk alone doesn’t cut it!
Anthropic released a changelog bug that took down the CLI. Here’s an analysis, called the 1000 Commits Problem . The last three paragraphs will stick with me a lot. Oh goodness, they’re worth quoting here:
The Claude Code crash wasn’t AI being dumb. It was a system that couldn’t catch drift between components. The kind of bug that happens when things move faster than the connective tissue between them can handle.This is going to keep happening. Not because teams are careless, but because the velocity is genuinely new and we haven’t built the infrastructure to support it yet. The same way early web apps had categories of bugs that desktop software never dealt with, AI-assisted development is going to surface failure modes we haven’t seen before.Nine minutes to fix. But I suspect we’ll be talking about “changelog drift” and “schema mismatch” and “component boundary failures” a lot more in the next few years. The taxonomy of bugs is changing.
And on the quality note, Jason Arbon created his 2026 list of predictions for testers in the age of AI.