MindLog

I started a newsletter.
I started a newsletter to become better.
I started a newsletter to become better and to help you.

Did it work?
Did I change anything?
Did you read this and think differently about quality, or testing, or your own job?

I have no idea.

But I think I’m getting better.
I have a marketing calendar now. I never had one before.
I built a test environment for my website. Why would you need a test site for a blog?

Whatever.

I produce more content.
Faster.
Fewer rewrites.
That’s measurable.

Do you care?
No.
Why would you, it’s not visible.

These are my internal processes.

But this is internal quality.

Internal quality is a predictable discipline, tracked and continuously improved through its measurable characteristics and indicators, a pursuit of excellence with which an organisation and its people produce a product or service for the person who matters.

Read it again.

From my definition of quality, this is the part that’s actually measurable. To make it useful, we just have to select the right KPIs. Like number of test cases. LOL. No. Not that kind of KPI. The real ones. The ones that give us value. For example, incidents after release grouped by root cause and severity.

Is it hard?
No.
Well… yes.
It can be a trap.
If I have trash metrics, I’m successful at something no one cares about.

So pick the metrics that the person who actually uses your work would care about.
Measure them honestly.
Look at trends, not individual results. (Everybody can have a bad day.)
Change something.
Get better.
Repeat.

I have a marketing calendar. I don’t know if my newsletters are better or not.
I built a test environment. I don’t know if it adds value for my audience.

I know one thing.
I decided that in the second half of the year I want to share more of what I know, in a prettier way.
Because I got feedback. I’m taking it seriously. I’m improving my internal processes. Also, thanks for that.

Hit reply.

Tell me if “this is the way.”* Tell me if you want something else.

Thanks for reading.

*That was a Mandalorian joke. Pun intended.

Alex is a freelancer. He has his own limited company. Works twelve hours a day. Loves what he does.

His relationship with his customers is amazing. He sells his service himself. He talks to them all the time. He tries to deliver the best service ever. At the end of every project, he upsells. Overdelivers.

His customers feel his enthusiasm. He’s worth every cent he invoices.

Great.

The story continues.

Alex wants more profit. He hasn’t had a holiday in two years. He wants to secure his income for the time he’s sick. Stability comes with a cost.

So he hires.

Sally takes over sales. She’s amazing. New customers keep coming in. She upsells. Always on schedule with the check-in call.

Alex now has more delivery work than before, so he hires Brian. Brian is good at what he does. Maybe even better than Alex.

Brian is an employee, not the owner. Brian works 9 to 5. If the customer calls at 17:01, Brian is already closing his laptop. Of course, he calls back first thing in the morning. He follows the handbook Alex wrote.

But the customer waits.

Alex has more costs now: two extra salaries. So he raises his prices.

The customer feels cheated.

Nobody did anything wrong. Sally did her job. Brian did his job. Alex did the math. And delivery quality already decreased.

Last time we talked about external quality: whether the delivered value aligned with needs, requirements, and expectations. In Alex’s case, the value didn’t change.

Same service, same outcomes. What changed was the feeling around it. That’s delivery quality.

Delivery quality is the experience the person who matters feels before, during, and after the process of delivering a product or a service, shaped by multiple dimensions.

In Alex’s case, those dimensions changed the moment he scaled. Response time. Ownership. Emotional investment. Pricing. Nothing broke. Shifted. And the customer felt it all.

The Stoics called it the dichotomy of control. Some things are up to you. Most things are not. How your customer feels about your service is not up to you.

You can only influence.
Influencing is part of the job.
And influence doesn’t stop at delivery.
It runs before, during, and after.

My friend Pablo said this in our new podcast, Never Stop Learning: “When you deliver the software, that’s not when the software is done. The software is done when you have delivered and it lives its life in production, and it actually delivers the value you expect from it over time, without having to fix it very much.”

The before and the during get all the attention. Pablo is talking about the after. The part most organisations forget exists.

Alex didn’t forget. Alex was the before, the during, and the after — same person, same energy, same phone number.

Now Sally is the before and the after. Brian is the during. The customer’s feeling… well. Let’s try to influence it.

Thanks for reading.

I want to talk about quality.

Many opinion leaders in testing, and even the ISTQB, are trying to sever “quality” and “testing”. And partially, they have a point: testing doesn’t directly change the quality of a product. But I think testing, executed by anyone in the company, has a massive indirect impact on quality. We’re not the ones building. We shape what gets built. That matters, and I think it should be emphasized.

I think the testing and quality industry should sit down and rethink its purpose, go back to basics and revisit why there was a need in the first place. Why companies started to employ dedicated resources for testing their products. And I strongly believe it was not because they didn’t trust their programmers, it was not because others were lazy to do the work. It was because of complexity and criticality, and because of the different focus. The focus of “what can go wrong?”.

“The first test team is formed by Gerald M. Weinberg, working as manager of Operating Systems Development for the Project Mercury. Project Mercury is the first human spaceflight program of the United States.”*

This was about sending humans to space and not killing them along the way.

Stick with me, I promise this connects.

Cory Doctorow has this word: enshittification. It describes the lifecycle of big platforms. First, we get a great experience, real value, no strings attached. Then, once we’re locked in, the focus shifts to businesses. And finally, when both users and businesses are trapped, it becomes pure cash extraction. “Service owners” don’t care about anyone anymore. They killed their competitors and built their monopoly. If anyone tries something against them, they’re bought out or cancelled, muted, destroyed (and then acquired for pennies).

Lately I keep hearing the term “technofeudalism”, which is a modern economic system where big tech companies hold power similar to feudal lords. They provide diminishing value, but we need them to “survive”. We use their “land” because there’s nowhere else to go. I’m just a hobby economist, but I’m part of society and I feel the consequences of this new world order.

My personal answer to that is decentralisation and open source. Decentralisation is another deep topic, so let’s focus only on the latter. It gets misunderstood because people hear “open source” and think “free”. But making software open source was never about the price. Operation and maintenance still cost money, time, and energy. It’s much more about transparency. It’s about development driven by the people who actually use the thing. No single “lord”. No extraction endgame. A collective ownership of the tools we depend on.

Why does this matter for us? We fight for quality in our products. Shouldn’t we fight for it in our platforms too? I believe in the idea of everyone’s internet. I’m not against paying for freedom or advertisements. I’m against abusing systems, companies, and people. I’m against monopolies. And I think we, people working in tech, should see more clearly than anyone that where we’re heading is broken, and that we have the power to change it.

Forgetting who you serve. That’s the disease. I’m assuming you believe in better software. Technology should serve humanity, not rule it. Enshittification and monopolies poison that belief every single day.

As the year ends, let’s meditate on that. And maybe, just maybe - get a little angry about it.

Thank you for being here. See you in the next one.

*Testing References — History of Testing

Where are the test reports? Who’s responsible for UAT and where can I find the timing? Wait, I thought high-priority issues should be hotfixed immediately - why is this one scheduled for sprint 25/8?

Chaos.

The same questions, over and over. Everyone’s sweating, working hard, but nothing works the way it’s supposed to.

Most project chaos comes down to one root cause: nobody established what everyone needs to know. That’s a communication problem, and it’s fixable. So fix it. I know, I know. Sounds like advice from the most useless coach you’ve ever worked with. But hear me out.

When you’re getting the same basic questions throughout a project, always via Teams or Slack because “it’s just a quick question”, your flow is already ruined. You’re frustrated. You want to send an impulse message. But you’re a nice person. You’re kind to people. So you answer. Nicely. Again.

What if you could write that rude email, but nobody would ask the recurring questions because they already know the answer? For every question that’s been asked before, the answer is already there.

The best solution is what I call the Beacon.

You might call it a dashboard, a charter, a home page, an FAQ, a PID if you’re into PRINCE2. I call it the Beacon because it’s always the first thing you check when you need information. It shows you the way.

Okay, so you create the page. You’re done. Everyone’s happy. Could be the end of the letter but…

I have more to say.

You have the document, but nobody’s reading it. You even sent an email about it. But we’re busy. Emails that start with “Hi All” or “Dear Colleagues” go straight into the Important folder, to be read when we have time for a deep breath. Spoiler alert: we never have time.

That’s why I prefer a meeting. I try to keep them short and interesting, starting with a big hook for the audience:

“If you pay attention now for 30 minutes, we’ll save critical hours throughout the project.”

I don’t give them the one-pager immediately. I tell them to pay attention. Write their questions in the chat immediately. This way I get attention and instant feedback.

The meeting where we share the Beacon’s light.

Let’s call it a kickoff, because that was the most common name used by companies I worked with. I always default to an actual, synchronous, everyone-in-the-room (or on the call) meeting. Because reading is optional. Showing up is less optional. You send a doc, people skim it, maybe. You get them in a room, they have to at least pretend to pay attention. And more importantly: they can ask questions. They can say “wait, what does that mean?” right there, in the moment, instead of carrying their confusion into week five.

Okay, you’ve got people in the room. Now what do you actually cover?

Where we are and why we’re here. It’s important to say that we’re at the kickoff meeting for the XYZ project, where I’ll show you everything that counts as basic knowledge for this project. You’re here because you’re part of this project and your role involves testing.

Timeline of the project. High-level plan. A quick Gantt, an overview of the main milestones and timeframes. Not the detailed sprint-by-sprint breakdown.

Ownerships and stakeholders. Basically a RACI, but don’t make it too complicated. Business areas, technical teams (in agile setups: POs), architects, testers or lead testers. The list depends on the size of your project or company. Which decisions are made by whom. Who sets priority, severity, delivery dates, expected releases… anything similar.

Common language and the basic bug stuff. What does a bug look like? What’s the flow? Priority and severity levels, with descriptions. What do we mean by “done” or “ready for retest”? What do we mean by “regression”, “critical bug”? Every team has slightly different definitions. Nail them down now. Because three weeks from now, when the dev says “it’s done” and you say “it’s not tested yet,” you’ll want to point back to this moment where you all agreed that “done” includes passing integration tests.

Where stuff lives. Requirements, test cases, bug tracker, CI/CD pipeline, monitoring dashboards, the Slack channel, the Jira board, the Google Drive folder someone created six months ago that has the “really_final_october_revision_final_v3” architecture diagram. All of it. One place. One table of contents. It doesn’t matter if it’s Notion or Confluence or an Excel file. Just make it the single source of truth and tell people “if it’s not here, it doesn’t exist.”

Rules, requirements, communication. As a test lead or manager responsible for testing, you have to say what your requirements are. First check the Beacon, then ask questions. Communication channels, which questions go where, what’s the response time. If you’re only communicating via Jira tickets, make that clear. I usually cover meeting structure here too, because it’s part of communication. Recurring meetings: when they happen, what they mean, why they’re important, what the agenda is.

What is the FAQ? With the Beacon you create a place for the source of truth so why not include a frequently asked questions section? Start with the questions you know people will ask, then grow it as new ones come up. Update it weekly. Bring up the newly added questions during sync meetings. Show this on the kickoff.

And I have one more slide, one more topic at the end. I always clarify the human side of how we work together. I require transparency and honesty, and the team will get my protection. Protection means I’ll be the one in the uncomfortable meeting explaining why we need more time or budget. Protection means when a stakeholder complains about testing delays, I’m the shield, not the team. But this only works if they tell me on Tuesday that something’s wrong, not on Friday when we’re supposed to go live. I want their honesty and transparency because with that, we can do something. So the slide has only a few words, but you talk about it in detail, because you have to share and make the team understand why it’s important, why those few words matter.

Maybe a bunch of this stuff is already in the company documentation, strategy, governance, whatever. I get it, this can feel repetitive. But repetition is kind of the point. You’re creating the map everyone uses, not the hundred-page manual nobody reads.

Here’s where it goes wrong.

The meeting that never happened (or didn’t include the test part). I learned this one the hard way. V-model project, traditional setup. PM scheduled the kickoff meeting. Invited the architect, the BA, the business stakeholders. Forgot the testing team. Completely. I found out two weeks in when someone asked during a coffee break, “they have no info about testing, because no one came from the test team.” So I quickly organized a separate test kickoff. Except now everyone’s annoyed because the PM was nice enough to make the decisions without me about bug handling. Don’t let this happen to your project. Communicate with the PM.

The meeting with no structure and no confidence. If you abuse the trust of their time, you’ll become another person who requires something. You won’t be a partner in their eyes.

The meeting with the wrong amount of info. Too deep and you lose half the people. Too shallow and you’re wasting their time, saying nothing. We want the right amount. Make the meeting about them. Make them interested in what you’re saying. It’s not easy, but if you prepare, and you prepare right, it can be done.

My biggest meeting involved more than 200 people. We finished the project on time, on budget. Of course it wasn’t only because of this meeting. But I didn’t feel like people were hunting me down with questions I’d answered a hundred times. Our meetings were effective even though there were people from business and people from IT (with big differences in knowledge and vocabulary), but they understood each other. The Beacon was updated weekly. At the same time when the implementation started, the UAT test case writing was starting as well. Most problems surfaced early because people asked questions. We had our rules, which we laid down at the beginning, at the kickoff meeting.

My smallest involved only three teams, fewer than 15 people. A really small agile organization developing one application. When I put together the document, they liked the idea immediately, because they had their first point of contact and it was not a person but a 24/7 available document. Some coworkers pushed back that the information wasn’t precise, and they didn’t want to use it because they would rather ask the person responsible. So I made a kickoff meeting. I confronted the skeptics with their own arguments, turned out they wanted to have the “startup feeling” (whatever that is). Ways of working change. People change. We learn. Even in small organizations or teams, if we keep the Beacon lit and maybe even repeat the meeting quarterly or once every six months, it gives value to everyone.

This is the unsexy work. Nobody’s putting “ran a great kickoff meeting” on their LinkedIn. But it’s the work that saves you. There are two big bonuses if you do this right: you’ll be a trusted leader within the team, and the work together will be much more fluid.

So what happens after?

You ran the meeting. Great. Now what? Someone (usually the test lead or PM) takes the notes, the links, the decisions, and puts them somewhere everyone can access. That’s your artifact. Your wiki page, your Confluence doc, your whatever. And here’s the key: it has to stay alive. Especially in agile. Your team wiki isn’t a “set it and forget it” thing. It evolves. Someone joins the team? Update it. A tool changes? Update it. A decision gets reversed? Update it. In traditional projects, you might lock it down after the kickoff and treat it as the baseline. In agile, it’s a living document. Either way, make it clear where the truth lives.

Keep it alive. In traditional projects, you might only revisit this at major milestones. End of a phase, mid-project review, whatever. In agile, it’s more continuous. Every PI planning, every new epic, every time the team composition changes, you’re basically doing mini kickoffs. Not full meetings every time, but at least a “here’s what’s new, here’s what’s changed.” The team that has a well-maintained wiki and checks it regularly is the team that doesn’t waste time asking the same questions twice.

So make the meeting. Build the Beacon. Keep it alive. Your future self, the one who’s not answering the same question for the eighteenth time, will thank you.

I need your help. I’m writing this newsletter for you.

Hit the reply and tell me:

• What’s the thing in testing, quality or process engineering that’s driving you crazy right now?
• Do you prefer deep dives like this, or shorter, tactical emails? I will read and answer. Until next time!

Thanks for reading.

Follow up

Last week’s newsletter was too long. I get it. More blog post than email. I’m thinking about this: maybe I send focused emails and save the deep dives for a blog.

For now, here’s a one-pager. Same content, without stories. Think of it as the tl;dr version.

Until next time. Thanks for reading.

You know that moment: the clock’s red, fingers flying, Carmina Burana in your ears. You slam the last numbers into a report, hit send, and…
Two hours later: “Can we change something so the management approves this release?”

Been there. Too many times. So, let’s make testing visible and understandable. Grab a coffee: this one’s going to be long.

We’ll talk about two flavours of reporting a little mixed, because it makes more sense to keep all reporting under one umbrella:

• quality reports (holistic, trend-oriented, mainly for (change)management, medium/long-term)
• testing reports (sprint/release/project…-focused, for team, project, organisation, trends and measurements, short/medium term)

So, here we go: The PPT Framework

The PPT in details:

Plan

The reporting must be planned. Just like you plan your test execution, you need to think about what should be shared in each phase of delivery. We talk about progress and closing here because we need to see our goals from the start. That’s how we align our way toward them. Plan what to report during delivery, and what to report after delivery.

• Kick off: When everyone is in the room, tell them what information will be available and where. Define the scope of measurements and trends, why they matter, and where they’ll live. You don’t need everything in one place (though it helps), but you do need a clear Table of Contents with all relevant links. Be prepared -> this will become the bookmark everyone uses. Later, if things change, trust will drop. And we don’t want that.
• Progress: Up-to-date information should always be available: what’s done, what’s open, what’s next. We’ll see more examples of this in the Personalize section.
• Closing: After every cycle, hold a retrospective or lessons learned. We have to learn from our mistakes, and celebrate what went well. After release, show the outcomes of testing and analyse progress trends. Plan time for the improvements you want to implement for the next delivery.
• Continuous: This part is more quality-oriented. It’s about the long-term strategy. All improvements from Closing come right into this part. That’s why I said it’s more of a (change)management thingy. Keep a living metric set that evolves with strategy.

Personalize

Shape the message to the context and receiver (team, project, organisation). Same truth, different lens, because everyone needs a different level of detail.

• Team view (today/tomorrow clarity): What’s ready, what’s risky, where help is needed. Micro-level: flaky tests, environment stability, hotspots in code.
• Project view (peer, release confidence): Trend of completion vs. plan, risk register with owners, dependencies (both ways: who’s waiting on us, who we’re waiting for). It’s important not to just aggregate the pass rate, but also not to drown in tiny details. Focus on readiness by critical user journeys.
• Organisation view (strategy & outcomes): This depends on the size of the organisation. Here you can include escaped defects, results of root cause analyses, or cost-of-quality trends (prevention/appraisal vs. internal/external failure). Show the business value. Why testing matters and why it’s worth the investment.

Tell (Story, Risks, Mitigations)

• Turn data into a story: about risks, choices, and consequences. This is the most important part. This gives the meaning to the numbers. All three parts of Tell depend heavily on the target (see Personalize).

• For the team report, you don’t need a big story, they have it as a live show day-by-day, but give context, like: scope: green, schedule: yellow, resources: green. Add environment indicators if possible (pulled from monitoring dashboards).

• For the project level the dependencies are key, describe the status briefly but focus on collaboration and how scope, schedule, and resources interact. Mention risks that could impact other teams.

• For the organisation level, go higher: use indicators, colours (RAG scale, or whatever your company uses), and talk about what happened, where we stand, and where we’re going. Start with “What changed since last time?” Then describe the current status and its impact on scope, schedule, and resources (human, environment, data, etc.). Mention the biggest pain point, next steps, and challenges. Highlight only the most critical risks and how you plan to reduce or manage them. Make visible any pending decisions, show the available options.

Make your work visible. You and your team matter, show it to others. Reporting isn’t paperwork, think of it differently. Give it a spin.

Steal my PPT, use it, and tell me what felt awkward and what clicked.

As always, feel free to reply to this letter. I’ll read every message and answer your questions. Until next time!

Thanks for reading.

*Fun fact: I first named the framework “Plan Target Story,” but then realised that PTS by D might be… controversial.