David Talks Quality Again

Do. Learn. Repeat.

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.

Get a Little Angry

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

17:01

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.