blogs

I Let BearQ Loose on My Own App Through Two Lenses: Tester and Engineering Leader

2026-05-07T13:47:56Z

Part 4 in “The Autonomous Testing Tipping Point” series If you’ve been following along, you’ll know we’ve been exploring application integrity, the gap opening up between AI-accelerated development and our ability to test what we’re shipping, and the broader implications for how we think about quality. In this one, I want to get hands-on. I’ve […]

Vimes Boots & why the right AI evals could save your project

2026-05-07T10:58:00Z

"The reason the rich were so rich, Vimes reasoned, was because They managed to spend less money" - Sam Vimes, from Men at Arms by Terry Pratchett.

The theory goes that richer people can afford a pair of boots that last longer before repair or replacement than poor people, who can only afford cheaper and less hardy boots requiring replacement in just a ⅓ of the time.

It’s the old "buy cheap buy twice" idea and it still applies today, especially in the world of AI agents and LLMs. Currently your agent is 'managed' or 'directed' at least in part by a harness. In fact, the IDE coding agent is really a harness + an LLM. The LLM “writes the code” and requests tool use, the harness enables those tool calls. E.g.: Write a file or run a command line tool etc.

In one sense the LLM does the productive side of the agents work while the harness has a more deterministic & feedback role. (e.g. reports back that the command the LLM suggested returned result xyz, or the code errored when we ran it)

That dynamic works well, and you can see that in Anthropic's toolset, where the LLM i.e.: Opus 4.7 and the harness i.e.: Claude Code has become hugely effective. Claude Code and other tools with agent capabilities fit together well. But these tools can deliver a slightly perverse incentive, depending on how you pay for your agents. If you pay a flat fee then this might be less of an issue, but if you pay per token, that might influence the vendor’s motivations.

E.g.: What if your LLM isn't very good at what you are using it for? we've all seen the benchmarks, stating how well the LLMs are doing at some maths reasoning etc. But are they good at what you do? so if I think about banking, financial services or payments - does the LLM, create code that works well for your agents operating in your business environment?

Let’s say we're using my new imaginary LLM: “VimesBootsLLM Pro” it’s fast and it's 30% cheaper than the competition and it has “reasoning” and tool use etc. It also passes all the usual benchmarks and is up there with the best of them in the league tables.

But what if you have your agent doing specific tasks (in e.g. banking or insurance) as part of their workflow? E.g.: You might have agent(s) writing code relevant to that domain – Does it perform well? And what does well/good mean here?

If we take a trivial example from bank payments, for example IBAN (International Bank Account Number) validation. Can it create the code repeatedly? How often / what percentage of its code is correct? (and yes, what do we mean by correct…) If our agent “harness” is using this model and finds code errors that terminate execution 50% of the time – the harness is going to be sending that code & result back to the LLM, which is going to rewrite that code maybe doubling the number of tokens used.

What if your tests/evals find the code does not error BUT also doesn't give the correct response 25% of the time? There are edge cases in even simple algorithms like IBAN validation. Then the harness will send this back to the server and the LLM will try again. All this back and forth is costing you money and cluttering your context window (The agent’s short-term memory).

As you can see the headline cost and benchmark stats are like mileage or battery life stats YMMV - Your Mileage May Vary. What’s even more misleading is that “reasoning” models can spend a lot of time just trying internally trying to get to the right answer. That internal reasoning uses tokens and while the price per token cost may be low, if your model is doing twice as much reasoning the cost will be proportionally more, than an LLM that does less “reasoning”.

Thinking this through you can see that it's in a vendor’s interest to maybe not be quite as good at one-shot coding (getting it right first time unaided by similar examples), if they are selling usage by the token. They maybe might create an awesome harness that can handle various values of fail, and handle it gracefully, and get the LLM to fix it next time around, especially if it’s failing reasonably quietly and user is not inconvenienced. It’s a bit like how it’s alleged that some search engines reduced the quality of their search results in a misguided attempt to sell more adverts for a short term-spike in revenue & long-term total collapse of user trust. Or how dating apps are not incentivised to make especially good matches, because if they were almost perfect - you are less likely to keep using them (as you will be dating your one true love – that you met on the first match!)

I’m not suggesting this is Anthropic’s plan, in fact I think they take measures to ensure this isn’t the case for Claude Code users (their recent doubling of allowances is consistent with this viewpoint). But if we look at the industry as a whole and factor in not just IDE based coding agents, but also look at other AI agents, running headless in your back-end systems, are the model maker’s incentives fully aligned with yours? Measuring the cost per successful delivery is a better bet.

Like Vimes and his cheap boots problem, sometimes we need to look at the total cost of ownership over time & how we intend to use the LLM. And it makes sense to look at this without custom skills and harnesses to reduce noise. I don’t mean to say that such agent & skills checks should not be done – they should be done, it’s just they are testing something else, something bigger, and are more akin to end-to-end tests.

DeepSeek V4 Flash does almost as well as Qwen 3.5 at a much lower cost.

Take this set of trivial "eval" results for some payment related functions. Essentially the LLM is provided with a typical bank payment validation functional description and then asked to create code to-implement it. Then the code is unit tested with several examples and the results recorded. Rinse and repeat many times across many function descriptions and LLMs. We then factor in the cost and accuracy, and we can then get a pretty-decent idea of how well the LLMs handle the bank payments domain.

This sort of analysis is going to be of greater concern in the coming months as more teams adopt agentic approaches to solving the problems and keep wondering why they have such high inference costs despite choosing what they thought was a good model and low price! Smart companies will look for this sort of analysis to ensure they don't buy cheap and buy twice.

This sort of analysis of software, of AI tools and teams is what I do, if you want to know more - get in touch.

Your CI Pipeline Is a Black Box. That’s Why Your Tests Feel Random.

2026-05-07T03:46:01Z

“If your test fails only in CI, it’s not a flaky test. It’s a blind spot.”

Continue reading on Medium »

Why Most Visual Regression Tests Fail in CI (and How Playwright Fixes Them)

2026-05-07T03:42:28Z

Learn why visual regression tests fail in CI and how Playwright's screenshot assertions fix flaky screenshots with real code examples.

The post Why Most Visual Regression Tests Fail in CI (and How Playwright Fixes Them) appeared first on Software Testing & Automation.

Playwright Locators Masterclass: All 18 Strategies With Real Code Examples

2026-05-06T22:00:00Z

All 18 Playwright locator strategies with real code examples: getByRole, getByLabel, filter, frameLocator, Shadow DOM, and more. With a decision tree for choosing the right one.

The post Playwright Locators Masterclass: All 18 Strategies With Real Code Examples appeared first on Software Testing & Automation.

Engineering Quality Podcast

2026-05-06T21:27:12Z

The Engineering Quality podcast is seriously one of the best software testing podcasts around and I was lucky enough to be invited on as a guest. Have a listen to Ale, Royalee, Veronika and I talk about quality leadership, career management, quality engineering, and just generally have a good laugh…enjoy!

The post Engineering Quality Podcast first appeared on Quality Remarks.

How to test a PUT, PATCH, and DELETE API request using Playwright TypeScript?

2026-05-06T12:55:26Z

Learn how to test PUT, PATCH, and DELETE API requests using Playwright TypeScript for API testing, including code examples.

Continue reading on Level Up Coding »

How to test a PUT, PATCH, and DELETE API request using Playwright TypeScript?

2026-05-06T12:55:26Z

Learn how to test PUT, PATCH, and DELETE API requests using Playwright TypeScript for API testing, including code examples.

Continue reading on Level Up Coding »

BrowserStack point 2026 Blog

2026-05-06T11:36:04Z

Had fun answering these questions for the BrowserStack blog ahead of my talk at break>point in May presenting my talk “To Infinity and Beyond: The Death of Test Engineering”. Hope to see you there!

Q: You’ve spent 25 years leading quality engineering inside some of the world’s biggest financial institutions. What does that work actually look like, and what’s kept it interesting for this long?

A: The work looks exactly the same as anywhere else that builds and deploys software, but I think one of the primary differences is the operational structure and oversight that comes with enterprise technology. When you get into certain types of financial services organisations, the context is just different than other industries because the exposure to regulatory and market moving consequences are higher.

As well, there is a corporate structure you have to deal with when despite not being able to conduct business without technology, it’s not your primary product. So a lot of times you have to navigate business structures and operations that are counterintuitive to running a tech team, but are vital to building and supporting the business.

It can be very stressful at times, but I think that’s one of the things that keeps it interesting and feeling you’ve very connected to global events, politics, etc keep it fresh and current and I’d probably be bored working in any other industry!

Q: Can you give us a sneak peek into your Breakpoint session? What’s the one thing you want every attendee to walk away with?

A: Aside from unloading on the test automation industrial complex for 20+ years of pent up frustration, my talk is a challenge to one of the biggest assumptions in our industry: that test automation means more/better testing and higher quality. I’ll also lay out how the old model of test engineering built on script production, regression sprawl, and maintenance-heavy automation has lost relevance in an AI-driven world.

Hopefully you’ll away with some ideas on how we got here and a clear message: don’t build your future around writing more tests, build it around understanding risk, failure, and system behaviour. The people who stay relevant won’t be the ones producing the most test scripts. They’ll be the ones who can ask better questions, model what matters, detect problems earlier, and explain why systems fail.

Q: What’s a belief you had about AI in testing a year ago that you’ve since changed your mind on?

A: What has changed for me is the full realization of just how powerful the cognitive surrender to AI has been from people I used to respect in this business. I think I underestimated the power of anthropomorphism with GenAI and that it’s pretty much treated like magic. It has created a mania and FOMO that is nothing like I’ve seen before, so my belief that systems thinking, risk management, and oversight could counteract that has been completely changed.

What hasn’t changed it that most of my pessimistic views about AI in testing have pretty much been validated, specifically how bad actors (consultants and vendors) in our industry are cynically just hyping AI as some evolutionary next step for quality. If you’ve been around this business long enough, you see the familiar patterns from people who clearly don’t understand testing, don’t care about testers, or have to live with the consequences of their quality decisions.

To be clear, a testers JOB is to be sceptical about things in order to get an objective view about progress, quality, and most importantly risk. So it’s getting pretty boring listening to the usual suspects drone on about how questioning the value of AI in testing and looking at risk is just being negative or acting like some kind of Luddite.

Q: What are some of the best tech-focused newsletters/blogs/podcasts that you would want to recommend?

A: I’m a pretty heavy consumer of everything testing industry related and am very active on LinkedIn and industry events, but my go to sources for keeping up on the industry is Software Testing Weekly, the Software Testing Round Up by Alan Richardson, the Engineering Quality podcast, and some Google/Reddit alerts I’ve set up.

To keep up with AI and the endless stream of news stories, I keep my inputs limited to trusted sources to focus my attention, and those are: Dagmar Monett, Emily M. Bender, Timnit Gebru, Charity Majors, Karen Hao, Fiona Charles, Michael Bolton and Maaike Brinkhof.

I’ve also outlined most of who and what I listen to on a regular basis that has influenced my thinking about my work on my Resources page on my blog: https://qualityremarks.com/resources/ and more specifically for AI here: https://qualityremarks.com/test-automation-days-follow-up/

Q: Outside of the tech world, what’s a hobby or passion you keep coming back to?

A: Well, I spend a lot of time a work so I take every chance I get to hang out with my family and travel. I hiked the South Downs in Surrey last year by myself and it was amazing and I’m hoping to do another one this year in Cornwall.

The post BrowserStack point 2026 Blog first appeared on Quality Remarks.

BrowserStack-Klain-Promo.mp4 (14MB)

Your Brain Is Full. The Problem Is How You’re Filing It.

2026-05-06T08:35:31Z

Building a second brain used to mean better folders. AI changes what it can actually become.

Continue reading on Medium »

Playwright Sharding and Docker: How I Cut My Test Suite from 47 Minutes to 8 Minutes

2026-05-06T03:41:10Z

I cut my Playwright test suite from 47 minutes to 8 minutes using sharding and Docker. Here is the exact GitHub Actions configuration, benchmarks, and mistakes I made so you don't have to.

The post Playwright Sharding and Docker: How I Cut My Test Suite from 47 Minutes to 8 Minutes appeared first on Software Testing & Automation.

5 New Roles Every QA Engineer Must Embrace in the AI Era

2026-05-05T22:00:00Z

AI is not replacing QA — it is creating 5 entirely new roles. From Quality Strategist to AI Output Validator, here is how to reposition your QA career for 2026.

The post 5 New Roles Every QA Engineer Must Embrace in the AI Era appeared first on Software Testing & Automation.

Using CIA Triad in our test strategy

2026-05-05T19:08:12Z

Periodically instead of writing blog posts I intend to share short videos. To start with I picked a slide that I had to cut from a talk but still wanted to talk about!

https://studio.youtube.com/video/a3DzHNp5c4E/edit

An example abstract for conference talks

2026-05-05T15:58:26Z

An example abstract for conference talks

In this post I’m sharing an old abstract of mine for a conference talk that was selected. My aim here is to help others to see the kind of thing that works when submitting to a conference, as there aren’t many guides out there.

Title

Hot Take – You’re not really ready for QE: Software testing is evolving but most testers haven’t evolved with it.

The title is punchy and highlights the core idea of the talk. The hot take part is derisive to grab attention of people (committee programme and potential audience) and the part after the colon helps explain the specifics of what the talk is about.

Remember when submitting that the title will be used to advertise your talk and on a multi-track conference will be the thing to sway people to come listen to you rather than other talks.

Main statement

Hot take: most testers aren’t ready for the current software market. Software development (and by extension testing) is changing constantly with the use of AI, massive reductions in test team sizes and a desire for more coaching changing the game. But whilst the industry is changing, testers are not… in fact they’re clinging on to and defending the old ways and arguments that don’t make sense in a modern context.

Note: I am open to working with the programme committee to shape this into a keynote as I believe this topic speaks to the theme well. I could envision doing this would include looking to the future of the industry based on the context of the past.

The main statement is my sales pitch for my talk, expanding upon the title to give an overall flavour of the talk. This usually gets used as the blurb on the conference website, so like with the title it’s good to make this eye catching and exciting.

I included a note here that showed my intent and interest in making this into a keynote speech. When doing this, it’s useful to set out why you think this would meet the conference theme (see section below for that).

Abstract

Starting any discourse online within the testing community can show just how out of touch a lot of testing professionals are with modern software team needs. I’d made a post about how most teams already test in production and the push back from so many people was unreal; this is not only an unpragmatic response but flags to engineers that testers are out of touch with modern software development.

In this talk I’ll use my experience as a seasoned tester and a QE that works closely with modern product development teams to go through my observations of the testing industry and show why many testers don’t yet give teams what they need. Calling out conventional wisdom and what testers say online I’ll give some tough love and honest feedback on where many testers are at and why this isn’t helpful.

Following this, based on discussions with CTOs, Engineering Managers and Software Engineers, I’ll explain what modern teams are looking for and why traditional testing wisdom and discourse hurts getting a seat at the table for testing professionals.

Attendees will be challenged to change their thinking around how they talk about testing and how they need to evolve to suit the current market needs. Focusing more on becoming a generalist, being a pragmatist and speaking out to push ideas at teams proactively.

The abstract speaks to the main points and themes of the talk, explaining the tone and what people will get out of listening to it. I’ve used this section to point out:

The problem space that exists and why this talk is needed.
What I’m bringing to the talk (how my experience shapes the talk).
The practical insights I’ve accumulated and where they come from.
What the core lesson from my talk is about.

I’ve tried to make my position on the topic really clear, to give the programme selection committee all the information I can about why to select me. I’m not trying to have a shock twist for them!

Tying this to the conference theme

A lot of the problems I’ve observed come from the limited context that most people have. Even testers don’t know what good testing looks like because they don’t know the art of the possible. Understanding good testing comes from breaking away from the safety of a known context and driving into the unknown. This means rejecting the bubbles that confirm the same stories, challenging posts that get all the likes and starting to widen our contexts by talking to other engineers.

I will speak to widening my own context, having worked across a range of technologies and domains, that have allowed me to see these problems in our industry. I’ll also talk about how my context has been shaped by working more closely with software engineers.

This section is important, it helps the programme selection committee understand my thinking of why this talk fits with their theme. I haven’t just submitted any talk, but instead thought about and submitted something that I think would add to their specific conference.

By helping them to understand “why this talk fits” rather than assuming that they’ll come to that conclusion, I’m increasing my chances of being selected.

Key takeaways

How we as a discipline talk about quality and testing shows that many testers aren’t ready for QE.
That most testers lack the context to see what’s needed in the market and how we can fix this.
What modern engineering teams are looking for from a testing professional.
How to distinguish yourself as a pragmatic testing generalist to become marketable as a tester.

The key takeaways are the learnings that attendees will get from listening to my talk. This could be seen as a tl;dr from the other sections but written in an actionable way so that people can take away and apply learnings.

This specific talk was a keynote thought piece so there are less practical actions; here’s another example that shows more practical learnings:

Understanding the “solved problem” of testing being limited to one facet of testing and how that’s impacted the industry.
How I’ve used quality radar within engineering teams to visualise the gaps in their “solved problem” of testing.
How to use quality radars to talk to teams about holistic testing and set goals for more quality coaching.

The speaker

Callum (he/him) is a testing specialist and quality coach with over 18 years of experience across a range of different industries and development methodologies. With a focus on holistic quality engineering and exploratory testing, Callum teaches others in core and agile testing concepts. He’s also a kick-ass dungeon master!

Callum’s speaking experience: https://cakehurstryan.com/talks/

Social media:

LinkedIn: https://www.linkedin.com/in/cakehurstryan
Website: https://cakehurstryan.com/

I use the speaker section to express “why me” to the conference programme selection committee. I share my experiences as both an expert and as a speaker to help inform the decision to include me; that I’ve spoken in front of big crowds before (so won’t get nervous) and that I’m experiences so have some credibility on the topic. This section may be shared to attendees too, so you’ll want to sell yourself to get them excited to come and listen to you.

Conferences will be looking for a range of people with different experiences (career and speaking) so don’t be put off if you’re a first time speaker.

Submit your talk

Now that I’ve shared how to write a talk submission abstract, why not give it a go. PeersCon 2027 has opened it’s call for talks (you can find the details here) which is open until 31st July 2026.

Thanks for taking the time to read! If you found this helpful and would like learn more, be sure to check out my other posts on the blog. You can also connect with me on LinkedIn for additional content, updates and discussions; I’d love to hear your thoughts and continue the conversation.

More Blogs

Public Speaking: Between Confidence and Self-Doubt

2026-05-05T15:45:59Z

Public speaking sits in a strange space between confidence and vulnerability. Whether you’re standing on a stage, leading a meeting, or speaking through a screen, you’re doing more than delivering words—you’re exposing your thinking in real time. That’s where self-doubt begins. For many of us, the loudest voice in the room isn’t the audience—it’s our own. Being your own worst critic can feel like a form of preparation. You replay sentences before you’ve even said them. You anticipate...

The Human in the Loop Isn’t Going Anywhere: They’re Just Moving Up

2026-05-05T12:36:19Z

For the 7th post in the Intelligent Quality Leadership series, I have dived into where having a human still involved in the loop is crucial. These are my thoughts, would love to hear others on this…

AI Writes the Test. But Who Decides What to Test?

A CTO asked me a question recently that’s stayed with me.

“Would you be comfortable with non-automation experts writing test automation through AI?”

He was testing whether I’d get defensive about QE territory, or whether I’d actually thought it through.

My answer was yes. The yes comes with a clear position though.

AI can write the test code. Deciding what gets tested, and why, is still a human call.

The business context, knowing which feature change carries the most customer risk, knowing that the checkout flow matters more than the account settings page, that feeds into every good testing decision. AI doesn’t have that. You have to give it to them. And “giving context to AI” isn’t the same as owning the strategy. Someone still has to understand the product well enough to know what to point the AI at.

The Coverage Trap

There’s a failure mode I’ve seen play out in real organisations.

Coverage goes up 25%. Incidents double. The metric looks healthy. The product doesn’t feel it.

Nobody stopped to ask what the new tests were covering, or whether they connected to anything a customer would actually notice. Coverage without that understanding is a vanity metric — a number that creates the feeling of safety without the substance.

Wait. Let me be more precise: it’s not a feeling of safety. It’s the appearance of safety, in a dashboard, to people who haven’t looked closely enough.

Guardrails help. But zero human oversight, even with stringent guardrails, is a risk I’m not comfortable taking right now. The governance frameworks aren’t mature enough. The judgment of what matters, what risk is acceptable, what coverage actually means for this product, can’t be fully codified into a prompt yet.

The Conflict of Interest

There’s another problem that doesn’t get enough airtime.

If you’re using an LLM to help build a feature, and the same LLM to test it, you have a conflict of interest. The blind spots in the output are exactly where the blind spots in the testing will be. It’ll miss what it missed the first time.

It’s the same principle as a developer testing and being the only one to review their own code. You’d never accept that as a quality practice. The same logic applies here.

For AI-powered features it gets more serious. When the output is non-deterministic, someone has to set the thresholds. What range of responses is acceptable? What constitutes a regression when the answer changes? That someone needs to be independent of the system that produced the output.

Human judgment. At the validation step. Independent of the AI that generated the thing being tested.

The Shift

Here’s where I land on the other side of this, and it’s actually good news for the profession.

A QE engineer who couldn’t write automation before can now point an AI at a user journey and get working test code. That’s progress.

The skill was always knowing what to test and whether what came out is worth keeping. AI removed the barrier between having that skill and being able to act on it. Less experienced engineers can now do work that used to need years of automation behind it.

The education piece shifts with that. Teaching people how to write a loop matters less than teaching them how to think about what the loop should test. How to set up the right approach. How to judge whether the output is actually useful. That’s a better conversation to be having with your team.

So Where Does the Human Stay?

In the judgment calls. In the decisions about what matters to the customer. In the independence layer between generation and validation. In the strategy that decides what good coverage actually means for this product.

The loop still needs a human. What changes is where they sit in it.

From execution to judgment. From writing tests to owning why they exist.

Where’s the human staying in your team’s process right now, and what made you draw the line there?

The beauty of having muscles

2026-05-05T09:49:49Z

This is the story of how and why I decided to pursue a muscular physique as a woman in my thirties. Most of it was sort of unplanned, but the start of it all has a very common reason: back pain.

It's 2018 (I'm 32 years old), and the Desk Dweller lifestyle is starting to make its presence known in the form of neck pain and back pain. I was sitting too much, looking at phones too much because of my job as mobile app tester, and not moving enough. The only saving grace is that my weight was normal, I wasn't eating too much.

how I looked in 2018, at the start of my journey

I wasn't happy with how I looked though, in typical female self-loathing style. Thinking I wasn't thin enough (I was), hating my belly fat, there was always something wrong with the way I looked. The back pain was where I drew the line though: "I'm too young for this shit!". This felt actionable.

I didn't know where to start, so I went to a small local gym for personal training twice per week. I only had one request to my trainer: I wanted to work towards being able to do a pull-up. Why I chose this goal is something I don't remember, I think it just sounded cool. And also, you train your back quite effectively with this exercise.

The first good feedback loop started here: within a month my back pain was gone. Dear reader, you aren't really strong after just one month of strength training, but apparently the movement alone was a good medicine to start with. I also enjoyed the training I was doing, which was an important discovery. Not that the training was effective (a sadly common theme among personal trainers), but I didn't know that at the time.

Key point: enjoyment will help with consistently showing up

Serendipity

I told two of my colleagues (Jacob & Stephano) that I had started strength training because they were also on the "gain train". Their reaction and enthusiasm was instrumental in my journey in the gym. I showed them that I was able to do a pull-up after 6 months of training, and they loved it!

Jacob, Stephano, Stephano's wife, and me!

Key point: receiving support from people around you can be instrumental

My colleague Stephano was like "why don't you try powerlifting?". This was a serendipity moment! He explained that you specialise in the squat, bench press and deadlift. I had done all three lifts already with my personal trainer, so the exercises themselves weren't completely new any more. Not that I was squatting to standards, I think I was doing "quarter squats" at that point. I now think it's odd that my personal trainer never really corrected my technique on this.

Anyway, it didn't really matter at that time. I started doing more powerlifting on my own, adding weight where I could. With the help of Jacob and Stephano, I also started to learn more about how nutrition mattered. You have to eat enough protein, for one. They also got me taking creatine, the number 1 supplement for people that do strength training. It gives you a slightly larger supply of ATP, enabling you to squeeze out extra reps, therefore leading to more muscle mass over time (compared to when you didn't take it).

At the time, Oliver and I were looking to buy a house. We ended up buying a house in a neighbourhood of Utrecht that is close to a powerlifting gym: Iron House. I remember being so intimidated by the people who trained there. I thought I was quite strong, but then I saw what the women there were lifting, and I was like "oh, I'm not strong at all". This was a huge motivator. It showed me what was possible!

Key point: having role models to look up to and aspire towards

my first 100kg deadlift, 2019

At the end of 2019 I decided to work with a powerlifting coach via my new gym: Leontine. She actually knew what she was doing, and thus started my real journey towards results. Not that the first gym was totally useless, but the trainers I had were only reluctantly helping me with my goals (the pull-up). They'd rather do a HIIT training with me. HIIT training is a bit insidious, if you ask me. It will give you the feeling that you did a hard workout, but it's more cardio focused than strength focused. Most people don't know the difference, and will feel good about themselves because the workout felt hard. But at that point: I wanted strength, not HIIT!

Iron House gave me strength, all right. Leontine taught me how to squat to powerlifting standards, improved my bench press and deadlift technique, and forced me to keep adding weight every week. This is key. Progressive overload is needed in order to keep progressing.

Key point: you need to train hard enough: volume, intensity, frequency, consistency

The Rona happened, but I had bought a home-gym just in time. I kept working with Leontine while the gym itself was closed. I never missed a training, I trained 4x per week at that point. Good to mention that I trained 3x per week at that first gym, and I have never struggled with consistency. When I decide something, and I like it, I do it.

Powerlifting era

I stuck with powerlifting for 5 years in total (January 2020 - April 2025).

I brought my squat up from empty bar to 132.5 kg (292 lbs).
My bench press from empty bar to 81 kg (178.5 lbs).
And my deadlift from empty bar to 185 kg (408 lbs).
I participated in Dutch National championships in 2023 and secured the last place! Somebody has to do it, lmao.

My body weight went from 62 kg (2018) to a peak of 75.5kg (2024) after a particularly long bulk. The calories I ate went from around 2000 kcal (I think, I never really tracked my food) to over 3000 kcal during a bulk.

More importantly, though: my self perception shifted. I no longer hated the way I looked, I started appreciating my body for what it could do. Food was no longer the enemy, but fuel. I overhauled my diet completely. I went from being a grazer (somebody who eats tiny bits all day long) to a meal-only girl. Stopping snacking gave me a lot of mental peace around food. And it's not like this is a religion or something, I still have a snack here and there if life presents itself in unpredictable ways (parties, holidays, going out all day, etc).

Key point: food went from a constant stressor to a neutral entity (mentally speaking) and fuel to do well in the gym

The funny thing is though, my physique wasn't really impressive. Because I started out as a "skinny fat" person (someone with low muscle mass, and a bit on the higher side of body fat) I could just start eating a bit more and slowly gain weight in the form of muscle mass. My body fat therefore stayed about the same. If I have to wager a guess: somewhere in the 27-30% range. This is still in the healthy range for a woman, but it doesn't give you a shredded look. Life is really easy on this body fat percentage though! You can eat a lot, you don't need to be super strict with your diet, you can enjoy plenty of fun foods.

To show you what I mean, here's a picture of me in bikini back in september 2021. This was right after I overhauled my diet from grazer to meal-only girl. I had also done my first ever cutting phase, which is a way of saying that you are losing weight with a focus on fat loss only. You want to keep your muscle mass or even add muscle mass while you're losing weight.

I did this cutting phase for 6 weeks to see if I could achieve a meaningful result before I went on holiday to Greece. When I look at this photo, I'm quite critical. You can't really tell I lift weights from this photo. This was 1.5+ years into my powerlifting journey, mind you. I added a couple of kilos of muscle mass already, but the higher body fat percentage cloaks this.

This is one of the areas were a lot of people are clueless. Because so many people are overweight these days, the idea of what a fit body looks like has undergone inflation. This photo shows me sitting at around 27% body fat. Again, not unhealthy for a woman, but not really low either!

This was not the physique I wanted. But I am thankful that I gave myself a few more years (!) of bulking and muscle building before I truly started peeling away the body fat with a serious cutting phase.

Because the thing is: as a powerlifter, you don't really care about your physique. The main thing is to lift as much weight as you can. That doesn't mean that it isn't relevant to work on your body composition (% of muscle mass up, % of body fat lower) in order to fill in your weight class, but I wasn't ever truly competitive in my weight class, so I never did this.

My physique December 2025

As you can see, I did end up adding lots more muscle. I weighed around 74kg in this photo. My arms and shoulders got a lot bigger, and my back also is very muscular (thanks, deadlifts!)

I'm grateful for powerlifting to force me to lift crazy weights. It developed my resilience, helped me overcome fears, I met a lot of nice people through the sport. In these years I also did more than just squat, bench and deadlift. That's not the only thing powerlifters train. We also do: accessories (what the rest of you call normal gym exercises). I learned to push hard on all other exercises as well, truly learned what training to failure is.

Key point: you have to learn to train to failure on non-compound exercises

Photo shoot prep

From April 2025, when I quit powerlifting, to the end of the year I was without a coach. I scaled back my training to 3x per week, and just maintained my current physique. It was nice to take a step back from intensive training for a few months.

Then, I made the decision to finally peel away some of the body fat I had accumulated over the years with the bulking phases. At the top of my last bulk (April 2024) I weighed 75.5 kg, and I hated food because I had to eat too much of it. I went back to eating as much as I wanted, and my weight drifted downwards to a steady 73-74 kg.

To reiterate: I didn't hate how I looked. I was okay with it. Not super pleased, but okay. That was still a different feeling compared to how I felt at 62 kg, with no muscle mass to speak of. Back then I actively hated my body. So being okay with it was actually a huge improvement.

I was healthy, I was strong. And now, I was curious how cool my muscles would look at a lower body fat percentage.

I hired a coach specialised in hypertrophy training, nutrition, and working towards a photo shoot. In the year I turn 40 (2026), I wanted to give myself this gift of looking lean and shredded. A sort of cherry on top of the 8-year muscle building cake.

How does this work?

It's simple, really. You eat less kcal than you need (about 500-600 below maintenance), make sure you eat enough protein, eat quality foods, and go to the gym 4x per week, where you train hard enough to signal to your muscles "keep hanging on please, or better yet, grow please!". Doing it well, however, is not easy for some people (for various reasons).

Key point: cardio is overrated for fat loss

I also did cardio, but I do cardio for my general (heart) health and activity level. For fat loss, cardio is just not really that interesting. Strength training is so much more important!

Why do people fail?

crash diets
not enough consistency
they don't train hard enough
they think cardio is the way
mental health issues around food, mild to moderate disordered eating habits like binging, restricting, guilt cycle
eating like a toddler (not enough quality foods)
making excuses for themselves
putting short-term pleasures over long-term results
the base habits aren't in place so they're spinning their wheels.
they forbid certain foods, thereby increasing cravings for those foods
they feel like this is a punishment instead of choice they made themselves

I don't say this to be a dick, or to brag, but a cutting phases should be easy and clear.

My base habits were already good:

consistent training
established food habits: meals only, lots of quality foods
I barely drink alcohol
I train hard enough, and feel confident about my technique being good enough

For the cut, I hadn't had to drastically change my lifestyle. I ate the same meals, but with a little less carbs and fat in them, and more veggies added. I quit alcohol entirely, I quit fun foods for 99%. I did NOT forbid certain foods, however.

For me, it was quite easy to flip a mental switch and stick to the plan. That's not to say that it was easy the entire time.

I struggled with hunger and low energy at times. I felt like a zombie at times. I only had energy for the things that were required of me, but it was hard to do spontaneous extra things. And then, in the last month, my body gave up on all feelings of hunger and it got easy again, even as I had to lower my calories to 1800 kcal per day. Mind you, my maintenance kcal was about 2700 kcal, so yeah, 1800 is low.

And then, after a little more than 3 months, it was done! I went from about 73 kg to 66.4 kg as the lowest weight. My waist shrank from 73 cm to 67 cm, meaning all my trousers are now too big. But more importantly: I lost zero strength, and actually got stronger. Training kept going really well, the entire time!

Key point: if you lose strength during a cutting phase, you're doing something wrong.

Mission accomplished!!

The eating and training protocol towards photoshoot day was also really fun. 5 days out I could increase my kcal back to maintenance, which is now lower than before the cut because I weigh less, at around 2300-2400 kcal. Carbs were back to normal numbers, which was a relief!!

The goal of the protocol was to de-stress the body out of the diet-state. Make sure the muscles look nice and full, while the waist looks nice and lean. So after a few days of high carb, on the day of the shoot (and possibly the day before) you scale back the volume of food you eat a little to look as good as possible.

I didn't do dehydration protocols (which are normal in bodybuilding) because I didn't want to. The only thing I did was have a shot of whisky the evening before the shoot and take extra magnesium before bed (that will ehhhh make sure you do a lot of number 2 on the toilet the next day, I got to 5!) to dehydrate a tiny bit without any risk to my health.

May the results speak for themselves.

Now what?

My body truly peaked that day of the shoot, I don't look like that any more, lol!

I am now 1 kg heavier than my lowest weight, and the look is a lot softer already. That's because I eat more kcal and carbs on a daily basis again. The stomach area is therefore fuller (literally food in the GI-tract), the glycogen stores in all my muscles are filled up again, removing that defined look, making it softer.

This is normal. Almost no one walks around shredded all year around. I didn't want to keep eating so few calories, I'm glad to eat more food again. That's why I am so happy I have the photo's! They are proof of my hard work and dedication.

Also: isn't it funny how 8 years of building muscle is revealed with just one serious cutting phase?

Key point: building muscle takes a lot longer than lowering your body fat %

To build that muscle: train hard, fuel yourself, be patient. That's truly it. There's no magic, no short cuts (if you want to stay natural like me, that is).

I am so incredibly glad I gave myself the gift of muscles in my thirties. It transformed me, physically and mentally. How I perceive myself is so much different compared to when I was just thin. I have so much more selfconfidence.

And, my muscle mass is the insurance I have against menopause. I have to see what my forties will bring, hormone shenanigans wise, but I am prepared. I will continue building, hopefully until old age.

Questions about my journey? Shoot.

Please be aware that I also offer strength training and nutrition coaching. It is my mission to get more women into the gym, as muscle is so important for us. Screw being thin, choose strong. If you're interested to become a client, please shoot me a message.

The Hidden Cost of “Just Add a Test”

2026-05-05T04:01:01Z

Every team has this moment.

Continue reading on Medium »

Playwright Docker GitHub Actions CI/CD Pipeline: The Complete 10-Minute Setup

2026-05-05T03:40:45Z

Build a production-ready Playwright Docker GitHub Actions CI/CD pipeline in under 10 minutes. Pin versions, cache dependencies, shard tests, and cut CI time by 40% with the exact workflow I run in production.

The post Playwright Docker GitHub Actions CI/CD Pipeline: The Complete 10-Minute Setup appeared first on Software Testing & Automation.

Is Your Test Coverage Keeping Pace with Your AI-Accelerated Dev Team?

2026-05-04T22:00:00Z

When dev velocity accelerates with AI, test coverage drops. Here is how QA leads should recalibrate strategy with confidence coverage, repair agents, and risk-based testing.

The post Is Your Test Coverage Keeping Pace with Your AI-Accelerated Dev Team? appeared first on Software Testing & Automation.