Month: July 2025

Quality as a discipline started in the factory.

It was about making sure that when you produced ten thousand widgets, every single one met the spec.

Consistency was king. Defects were the enemy.

Deming, Juran, Crosby—all emphasized reducing variation and building trust through repeatability.

But in SaaS, the game is different.

We’re not stamping out physical products.

We’re providing a service—one that changes every week, maybe every day.

And our customers don’t experience it as something they buy once and hold. They experience it as something they rely on—something that either works for them, or doesn’t.

So what does it mean to lead quality in that context?

Quality as Experience, Not Output

In a SaaS world, the thing customers value isn’t just “the product” (in the traditional sense). It’s the whole experience:

How reliably it works when they need it. How easy it is to do what they came to do. How quickly they get help if something goes wrong. Whether they trust updates to make things better, not worse.

That’s why I think of SaaS quality like this:

Quality is the degree to which the service consistently enables the customer to achieve their desired outcomes with confidence and ease.

It’s not just fewer bugs.

It’s fewer surprises.

It’s less friction.

It’s more trust.

What Makes This Harder (and More Interesting)

In manufacturing, you can inspect the product before it ships.

If it meets the standard, it’s done.

In SaaS, nothing is ever done.

Your code is deployed to production and immediately starts living a new life—interacting with real data, real users, real constraints.

You can’t inspect your way to quality. You have to design for it, observe it, and adapt continuously.

This changes the role of QA and quality leadership.

You’re not just testing features—you’re stewarding an experience.

How I Think About Leading Quality in SaaS

Here’s how I’m learning to approach it:

1. Expand the Horizon Beyond Code

Yes, bugs matter. But so do outages, confusing workflows, slow support responses, and brittle integrations.

Leading quality means caring about the entire journey, not just what’s in Git.

2. Make Value the North Star

Defect rates tell part of the story, but not the whole story.

The real question is: Does this change make our customer’s life better?

That’s the metric that matters.

3. Treat Releases as Living Things

Shipping isn’t the finish line—it’s the starting point.

We need monitoring, telemetry, feature flags, and fast feedback loops to keep learning from what’s in production.

4. Coach Teams to Own Quality

In a service, quality is everyone’s job. Developers, designers, support, marketing—they all touch the experience.

My role is less about gatekeeping and more about shaping a shared mindset.

5. Design for Resilience

Manufacturing aimed for zero defects. SaaS should aim for graceful failure and fast recovery.

Rollbacks, fallbacks, clear communication—these are features, too.

Where AI and Continuous Delivery Fit

AI is changing the game.

Tools like Playwright MCP or automated observability help us find issues faster, automate the boring stuff, and spot patterns humans miss.

But AI is still just a tool.

It doesn’t define quality for us—it amplifies whatever system we already have.

Deming would still ask:

What’s the system that produces these results?

In SaaS, that system isn’t a production line—it’s a living network of code, people, and feedback.

AI fits when it supports learning and improvement, not just speed.

The Leadership Shift

Leading quality in SaaS means shifting from inspecting outputs to shaping a system.

It means asking:

Where are we building trust? Where are we losing it? How can we learn faster?

And it means connecting dots across the organization:

From engineering to customer outcomes. From features to value. From incidents to learning.

Because in SaaS, what customers buy isn’t code.

It’s confidence.

Moving Toward Service-Quality Leadership

If I had to sum it up, I’d say quality leadership in SaaS is about:

Seeing the whole picture – not just defects, but outcomes. Building resilience – not just preventing failure, but recovering with grace. Inviting ownership – making quality a shared mindset, not a department. Measuring what matters – focusing on value, not vanity metrics. Keeping the customer at the center – because they’re not buying your features; they’re buying what those features let them do.

In manufacturing, quality was about building the same thing right every time.

In SaaS, it’s about continually earning trust.

That’s a harder problem. But it’s also a more meaningful one.

—

Beau Brown

Testing in the real world: messy, human, worth it.

I’ve been experimenting with Playwright’s MCP server tool inside Cursor, and honestly—it’s kind of magic.

I spun up the classic TodoMVC app just to test things out, and within minutes I had working UI tests:

Add a to-do item Remove a to-do item Check that it stuck

No fuss. No deep dive into selectors. Just fast, clean interaction with a real app.

Where MCP Shines

Here’s where the Playwright MCP + Cursor combo really shines:

When you know what you want the test to do, but you don’t want to burn 30 minutes getting the TypeScript syntax just right.

In other words:

You’re not designing a robust suite (yet).

You’re just trying to get real signal fast.

That’s where this workflow flies.

AI + Testing = Acceleration (Not Replacement)

To be clear, architecting a solid test suite still takes work—strategy, structure, edge cases, naming conventions, cleanup logic. You know… all the stuff that makes tests worth running in the long term.

But that’s the beauty here:

AI isn’t replacing any of that. It’s just accelerating the ramp-up.

You can sketch ideas, try things, refine.

Then build the real suite once you know what matters.

My Takeaway So Far

Tools like this change how I think about test scaffolding:

Short feedback loops: Try something, see it run, improve it. AI as a testing assistant: Not writing everything, but getting you started. Speed without sloppiness: When used well, these tools speed you up without skipping important thinking.

If you’ve ever put off writing a test because setting up the test felt harder than the test itself… try this combo.

It’s not perfect, but it’s fast.

And sometimes, that’s exactly what you need.

⚡ Quick Start Guide: Playwright MCP + Cursor

🛠️ Step 1: Install the TodoMVC App

Clone the classic TodoMVC example or use your own small app to experiment.

git clone https://github.com/tastejs/todomvc.git cd todomvc/examples/react npm install npm start

This gives you a local app to write and run UI tests against.

🧪 Step 2: Add Playwright + MCP Support

If you haven’t already, install Playwright:

npm install -D @playwright/test npx playwright install

Then, to enable MCP in Cursor:

Visit https://docs.cursor.com/tools/mcp Scroll to the Playwright card Click “Add Playwright to Cursor”

I didn’t even need to run anything manually. I just restarted Cursor once, and it connected automatically. Your mileage may vary, but the setup was impressively smooth.

💡 Step 3: Write and Run Tests (with AI Help)

Once MCP is active, open a new tab in Cursor and run this prompt to explore your local app:

use the playwright mcp tool to explore and write tests for localhost:8080

You can experiment with other versions of the prompt to add more detail, like:

“Start by writing a basic test that adds a todo and checks that it appears.” “Write 3 test cases for deleting todos, including an edge case where the list is empty.”

The MCP connection lets Cursor explore the running app, interact with it, and generate working Playwright test scripts—without you needing to wire everything up manually.

✨ Bonus: Sample .cursorrules Prompt

@testcases - Playwright Test Skeleton You are a senior QA engineer using Playwright Test. Write a basic UI test to verify the following: [user adds a todo item, sees it listed, and deletes it]. Use TypeScript and the Playwright testing API.

Or stick with direct prompting in the Cursor composer for more control.

🧠 Pro Tips

Don’t skip test teardown—AI might forget to clean up state. Keep a scratchpad folder for rough drafts and auto-generated tests. Use this approach to validate flows before you design a full suite.

Final Thought

You still need good judgment, especially when building long-term test infrastructure. But this tooling removes so much of the friction at the beginning of the process.

It’s not about skipping craft.

It’s about skipping tedium.

And I’m here for that.

—

Beau Brown

Testing in the real world: messy, human, worth it.

---

There’s this weird phenomenon I keep bumping into—maybe you’ve felt it too.

You walk into something not knowing how hard it’s going to be.

You’ve got just enough confidence to say yes.

And then it hits: this is way harder than I thought.

It stretches you.

It exhausts you.

It humbles you.

You almost walk away—or at least wonder if you should.

But then, somehow… you get through it.

And when you come out the other side, you realize something quietly life-changing:

You’re more capable than you thought you were.

---

The Arc of “I Can’t” to “I Did”

It’s strange how growth sneaks up on you.

You start off with one set of assumptions:

• This will probably be manageable.
• I’ll work within my current limits.
• I’ll stay in the zone of what I know how to do.

And then the challenge arrives and laughs at all of that.

You have to learn faster.

Stretch wider.

Think deeper.

Lead, even when you weren’t given the title.

Test, even when no one defined the scope.

Speak up, even when your voice shakes.

It’s terrifying. And messy. And often unfair.

But then—somehow—you do the thing.

And it doesn’t kill you.

And now you can’t unknow that you’re capable of more.

That doesn’t mean you want to do it all again.

But it does mean you carry a new kind of confidence—not the loud, flashy kind, but the grounded kind that says:

“I’ve walked through fire before. I didn’t love it, but I’m still here.”

---

The Danger of Underestimating Yourself

When you’re just starting something—new role, new company, new toolset—it’s easy to look at your current skill set and assume, This is what I have to work with.

But most of the time, what you can do tomorrow doesn’t show up on today’s resume.

You only find out by being asked.

By being stretched.

By being given too much—just barely too much—and learning how to carry it anyway.

The hard part is: you don’t know what you’re capable of until you’re already in it.

There’s no shortcut to that.

---

What I’m Learning to Trust

I’m learning (slowly) that this kind of growth usually starts with a moment of ignorance—not in a shameful way, but in a pure, honest way:

I don’t know how this will go.

I don’t know what I’m capable of.

I’m about to find out.

That’s not a failure of planning.

That’s the beginning of learning.

And when I look back at the hardest, most important moments in my life and career, that’s the pattern:

• Ignorance
• Struggle
• Breakthrough
• Quiet, unshakeable strength

---

If You’re In the Middle

If you’re in the middle of that arc—where it feels like too much and you’re wondering whether you’re enough—I hope you’ll hear this:

You don’t have to know yet.

You’re allowed to struggle.

And it’s entirely possible that the part of you that’s currently overwhelmed is also the part of you that’s growing stronger.

You’re not stuck—you’re stretching.

Give it time.

Keep walking.

And don’t be surprised when, later, you look back and say:

“I didn’t know I could do that.”

But you did.

And now you know.

—

Beau Brown

Testing in the real world: messy, human, worth it.

---

I’ve been thinking about something lately—something I’ve felt but haven’t always known how to name.

It’s this:

Sometimes, the way you know someone respects you is when they come hard at you.

Not in a cruel way.

Not in a power play.

But in that sharp-edged, test-your-thinking, defend-your-ground kind of way.

They come at you because they think you can handle it.

Because your ideas matter enough to push against.

Because they see you not as fragile—but as a peer.

It’s not the best way to approach people.

It’s definitely not the gentlest.

But sometimes—it’s real.

---

A Hard Respect

I’ve had people challenge me with more heat than I was expecting:

• “Why did you do it that way?”
• “Are you sure that’s the risk we should be prioritizing?”
• “That feels like a half answer—what are you really saying?”

And in the moment, it stings.

I get defensive.

My brain scrambles to explain.

My heart wonders if I’ve lost their trust.

But later—sometimes hours, sometimes weeks—I realize:

They only challenged me that hard because they thought I had something worth challenging.

They saw me as someone who could take it, wrestle with it, and sharpen back.

And that kind of respect, while messy, is still respect.

---

It’s Not Always Healthy

Let’s be clear—this doesn’t mean aggression is leadership.

Or that we should go around testing people’s worth by throwing elbows in meetings.

Respect can also look like listening.

Like collaboration.

Like invitation instead of interrogation.

But in some circles—especially in tech, especially in leadership, especially in fast-moving teams—respect sometimes shows up through pressure:

• Prove it.
• Justify it.
• Show your reasoning.

And if no one ever challenges you?

That might feel polite—but it can also be a sign that people aren’t listening closely enough to your work.

---

What I’m Learning to Do With It

When someone comes at me hard, I try (emphasis on try) to:

1. Pause instead of reacting Sometimes the heat in their tone isn’t about me—it’s about the stakes. Or their stress. Or their own discomfort with uncertainty.
2. Hear the question behind the tone Is there a good challenge buried inside the delivery? Can I respond to the substance, not just the sting?
3. Push back without burning bridges Respect goes both ways. I can hold my ground without having to mirror the intensity.
4. Ask myself: would I rather be ignored or engaged? I’d rather someone argue with me than pretend I have nothing worth saying.

---

A Better Way Forward?

Of course, the goal isn’t to normalize hard-edged conversations as the only way to show respect.

But it’s worth recognizing the pattern.

And maybe it’s worth naming in ourselves, too:

• If I push someone, is it because I believe in them?
• Can I challenge without triggering?
• Can I honor people not just by being kind—but by being engaged?

Because sometimes, the hardest questions come from the people who are actually paying attention.

And that’s a kind of respect I’m still learning to receive.

—

Beau Brown

Testing in the real world: messy, human, worth it.

Sometimes you find yourself standing at the intersection of competing priorities, unclear expectations, and frustrated people. One leader says you’re not surfacing work clearly enough. Another insists the team should be shielded from leadership noise. Meanwhile, the engineers are just trying to get their heads around what’s actually being asked. And you’re the person in the middle—expected to translate, advocate, anticipate, absorb, and somehow not combust.

After a particularly tense conversation recently, a colleague messaged me privately and said:

“You’re really stuck between a few breakdowns in communication and philosophy. It’s tough. Don’t get discouraged. This kind of thing is more common than we admit.”

I felt seen. Not fixed, not rescued—but seen. And that mattered more than I expected.

Because when you’re in a connective role—whether you’re a QA lead, a product manager, an engineering manager, or anyone else whose job is to translate complexity into clarity—you will be caught in the crossfire from time to time. It’s not a sign of failure. It’s a sign that you’re in the place where alignment still needs to happen. That can be exhausting, yes—but it’s also sacred work.

Here’s what I’m learning to do in these moments:

1. Name what’s happening. Not to blame, but to clarify. “We seem to have different assumptions about what success looks like here.” Or, “It sounds like the priorities changed, but not everyone got the memo.”
2. Slow the tempo. When things heat up, it’s tempting to go faster, fix everything, or appease the loudest voice. But wisdom often lives in the quiet, unhurried questions.
3. Seek alignment, not agreement. Agreement can be superficial. Alignment goes deeper—it’s about shared purpose, even when tactics differ.
4. Value the bridge-builders. The people who notice what’s going on beneath the surface, who check in with kindness instead of critique—these are your people. They’re holding up the invisible scaffolding that helps teams stay standing.

I don’t have a clean ending to this story yet. But I do have more clarity about my role: I’m not here to keep everyone happy. I’m here to keep the conversation going, to hold space for misalignment long enough for something better to emerge. That takes patience. It takes people who care. And it takes the occasional reminder—from someone who gets it—that this is hard, and you’re not crazy for finding it so.

So if you find yourself caught in the middle, take heart. It means you’re needed.

And if you’re someone who notices others in that space and reaches out with a word of grace—you’re doing more good than you know.

People sometimes tell me I seem calm.

I get messages like:

“I appreciate how you don’t panic.”

“You’re one of the least reactive people I’ve worked with.”

“You appear to not be freaking out right now, and you probably should be.

And while I’m grateful for the compliment (concern?), I always feel a little strange receiving it—because it’s not the full story.

The truth is, I often don’t feel calm.

Inside, I’m paddling like crazy.

Like that classic image of a duck gliding across the surface of a pond—serene and composed above water, legs churning like mad just below.

---

The Myth of Calm = Unbothered

In tech—and especially in quality roles—there’s often pressure to appear fast, sharp, always-on.

Urgency gets confused with competence.

Panic with passion.

Noise with leadership.

So when someone shows up quietly—steadily, thoughtfully—it can read as disinterest or disengagement.

But that’s not what’s happening here.

If I seem calm, it’s not because I don’t care.

It’s because I’ve learned the cost of frantic.

---

I Was Frantic for Years

Before this, I spent years as a pastor.

And I’ll be honest: I operated in a low-level state of panic for a long time.

The needs never stopped. The boundaries blurred. It was a very meaning-full existence with some amazing human beings, but the weight of holding everyone else’s fear and hope and grief was relentless.

So I got good at looking calm while my body and brain ran in high gear.

But the toll showed up—in anxiety, fatigue, and a sense that everything depended on me.

I’m still unlearning that.

Now, in software, I carry some of that same wiring. But I also carry some tools that help me live differently.

---

What Helps Me Match the Calm I Seem to Have

Here are a few things I lean on when I really am calm—not just appearing to be:

1. Preparation

I prepare. A lot.

Probably more than I need to.

I write things down. I map risks. I over-document. I rehearse conversations in my head.

It’s not about control—it’s about relieving my brain of the need to hold everything at once. Preparation buys me clarity in moments when I don’t have time to think.

2. Systems

I have systems. Not perfect ones, but good enough.

I use checklists. Templates. A few carefully chosen tools that keep track of what’s important.

If a task comes my way, it usually lands somewhere where I’ll see it again.

This keeps the mental paddling to a minimum.

3. Trust

This one’s harder—but I’m working on it.

I trust my team.

I trust that quality doesn’t depend solely on me.

And I trust—at least half the time—that God is at work in the mess, and that I don’t have to carry the whole thing.

This isn’t about blind optimism. It’s about loosening my grip on the illusion of total control.

4. Recovery

I’ve learned to take walks. To go quiet. To log off.

I still get wound tight, but now I try to notice it sooner.

Because calm isn’t just something I give to the team—it’s something I need for myself, too.

5. Knowing What Can Wait

Unless it’s a life-threatening or business-critical bug, it can wait until morning.

Writing it up, getting it prioritized, coordinating the fix—those are tomorrow problems.

I’ve spent too many nights treating every bump in the road like an emergency. These days, I’m learning to tell the difference.

That boundary helps me keep a clearer head. It protects my energy for the moments that do matter. And it reminds me that sometimes, rest is the most responsible thing I can do.

---

Calm Isn’t a Performance

If you’re in a testing or quality role and you feel like you’re drowning quietly while others assume you’re fine—just know you’re not alone.

That duck image? It’s real. And it’s okay.

But I’m also learning that I don’t want to live underwater. I want the calm to be real, not just performed. And when it is, it’s usually because I’ve done the behind-the-scenes work to create space and margin.

For preparation.

For trust.

For faith.

For breathing.

And for remembering this:

Calm isn’t about ignoring problems.

It’s about knowing which ones actually need your full attention right now—and which ones can wait a few hours while you recover your soul.

---

Calm isn’t the absence of motion.

It’s the presence of clarity, enough structure, and a gentler pace.

And that’s something worth working toward.

—

Beau Brown

Testing in the real world: messy, human, worth it.

I’ve only recently started digging deeper into the work of W. Edwards Deming, and the deeper I go, the more I find myself nodding along.

Though he made his name in manufacturing and management decades ago, I keep stumbling on his ideas in unexpected corners of my own work—particularly in software quality, and especially now, in an AI-heavy, fully remote environment.

There’s something refreshing about how clearly he speaks into problems we’re still facing:

Short-term thinking. Blame-shifting. Siloed teams. Sloppy systems. Metrics that create the illusion of control.

He may not have written a line of code in his life, but I think Deming still has a lot to say to testers, developers, and engineering teams in 2025.

---

What Deming Believed (and Why It Still Hits)

If you’re new to Deming, like I am, here’s a quick overview.

Deming was a statistician and systems thinker who helped transform industrial production in postwar Japan and later brought his ideas back to the U.S. He insisted that quality isn’t the result of catching defects—it’s the result of building better systems that prevent defects in the first place.

Some of his most compelling principles include:

• Drive out fear
• Cease dependence on inspection
• Break down barriers between departments
• Improve constantly and forever the system of production and service
• Institute leadership (not just supervision)

At the center of it all is this:

“A bad system will beat a good person every time.”

It’s a sobering idea—but also a freeing one. Because it shifts our focus from blame to design. From people to process. From fault-finding to system-shaping.

And honestly? That shift is just as relevant today as it was 50 years ago.

---

The PDSA Cycle: A Rhythm for Real Improvement

One of the most useful tools Deming left us is the PDSA cycle:

Plan → Do → Study → Act

This is not a checklist—it’s a mindset. A rhythm of inquiry and iteration that invites teams to slow down just enough to learn from what they’re building.

In software, I see PDSA show up in subtle but powerful ways:

• Plan – Define your hypothesis. What are we trying to change or improve? What assumptions are we making? What’s the risk?
• Do – Build it. Test it. Try it out. But keep your ears and eyes open.
• Study – Did it behave as expected? Did it solve the problem? What unintended consequences showed up?
• Act – Decide what to carry forward, what to revise, and what to scrap. Then start again.

This framework pairs beautifully with agile and lean development—but only when teams have the discipline to actually pause and study before reacting or shipping again.

PDSA is one way to build learning into the bones of your software process, instead of treating it like a fire drill.

---

Deming for Remote Teams

One of Deming’s core principles was this:

Break down barriers between departments.

In his context, that meant getting marketing, engineering, design, production, and leadership to stop working in silos and start seeing themselves as part of one system with a shared aim: delivering quality.

That’s still the work today—but the barriers have changed.

We’re not just talking about different floors in the same building anymore.

Now those “departments” might be:

• In different time zones
• Operating across cultural norms
• Reporting to different companies (contractors, vendors, offshore teams)
• Speaking different native languages
• Working on different platforms or backlogs

And instead of walls and office doors, the barriers are things like:

• Infrequent communication
• Misaligned definitions of “done”
• Slower feedback loops
• Friction in scheduling real-time collaboration
• Unspoken assumptions that don’t translate across cultural lines

The danger isn’t just miscommunication—it’s fragmentation.

Quality suffers when each group optimizes for its own deliverables instead of aligning around a shared vision of what good looks like.

Deming’s insight still applies, but it takes on new urgency:

Breaking down barriers now means building systems of intentional, structured connection across distance, time, and difference.

That might look like:

• Writing clear, async-friendly test plans and release notes
• Bringing QA into product planning as early as possible, no matter where they’re located
• Normalizing documentation not as overhead, but as a bridge between minds
• Creating shared rituals across time zones (e.g., end-of-day handoff notes)
• Building cultural awareness into the way we give and receive feedback

In other words: we have to build relational tissue into remote systems on purpose.

Because if we don’t, the barriers Deming warned about don’t just stay up—they harden into assumptions, rework, and mutual distrust.

And in the end, nobody owns the quality. Everyone’s just shipping their part.

---

A Few Deming-Inspired Practices I’m Trying

As someone still learning, I’m not here to teach Deming—I’m here to reflect on where his thought is taking me. Here are a few things I’ve started trying (or trying again) with his voice in mind:

1. Pause to ask, “What system produced this problem?” Not just, Who made a mistake? But what pressures or gaps made that mistake easy to make or hard to notice?
2. Push for clarity, not just coverage. Whether it’s test cases or team charters, I’m learning that well-defined boundaries and goals do more for quality than vague velocity ever will.
3. Use AI to reduce toil, not insight. I’m experimenting with AI to handle repetitive work—but keeping the human part (judgment, pattern recognition, nuance) where it belongs.
4. Revisit our metrics. Are we measuring what matters? Or what’s easiest to measure?
5. Name risks out loud—even if the system seems “done.” Because being a steward of quality means being willing to disrupt the comfort of “almost good enough.”
6. Try PDSA on purpose. Build time into the week—not just for building or testing, but for studying what worked and what didn’t, and making small changes accordingly.

---

I’m early in my journey with Deming. But already, I see how his work offers something deeper than process diagrams or test automation patterns.

It’s a mindset.

It’s a posture of care, clarity, and responsibility—for people, for systems, and for the long-term health of what we’re building together.

And I think that’s something we still need. Maybe now more than ever.

—

Beau Brown

Testing in the real world: messy, human, worth it.

Photo source: https://deming.org/w-edwards-deming-photo-gallery/