Greetings!

Welcome to Go Forth and Test

Hi. I’m Kevin. This is post #1, so let’s get the awkward introductions out of the way.

I’ve been a quality engineer since 2012. Fourteen years of writing tests, building frameworks, breaking things, and occasionally fixing what I broke. I’m a Senior SDET at Ramsey Solutions, and I’ve spent most of my career at the intersection of two tribes that don’t talk to each other nearly enough: developers and testers.

That gap is why this blog exists.

The problem with most testing content

Most testing blogs are written for QAs by QAs, and they reinforce the same patterns we’ve been stuck in for years. How to click a button in Selenium. How to organize your Page Objects. How to make your test suite 3% less flaky than the disaster it currently is.

Meanwhile, developer blogs talk about testing like it’s a checkbox. Write your unit tests, get your coverage number up, move on. Nobody’s teaching developers how to think like testers, and nobody’s teaching testers how to think like developers.

So we end up with teams where the devs say “SDETs are just bottlenecks” and the SDETs say “devs don’t test anything,” and everyone is annoyed and nothing gets better.

I’d like to be a small part of fixing that.

What this blog is going to be

It’s going to be about testing. That’s the anchor. Every post flows from there. Sometimes I’ll branch into adjacent topics — AI, framework design, engineering culture, whatever — but testing is always the “in.”

It’s going to be opinionated. I’ve spent 14 years forming takes, and I’m going to share them. Some examples of takes I hold and will eventually write about:

• The test pyramid isn’t wrong. It was written by a developer for developers, and QAs inherited it without the context. When QAs can’t read anything but E2E tests, they don’t trust anything but E2E tests. So we write Selenium suites for everything. That’s not a pyramid problem — that’s a communication and skill problem.
• Playwright isn’t just better than Selenium. It’s trying to solve every problem test writers have, and most teams using it are barely scratching the surface of what it can do. I have a lot to say about this. It’ll be a recurring series.
• AI is not the enemy of testing. I’m a full adopter. I use it every day building test frameworks, and I’ll write about exactly how.
• Developers and SDETs should be on the same team, not on opposite sides of a ticket. Both sides need to learn from each other. I’ll keep coming back to this one because it’s the whole ballgame.

It’s going to be practical. I’m an engineer who actually ships this stuff. You’ll see real code, real patterns, real tradeoffs. When I show you a technique, I’ve used it. When I tell you something doesn’t work, I’ve tried it and watched it fail.

It’s going to cover multiple languages where it matters. Playwright has bindings for Java, TypeScript, Python, and .NET. Most Playwright content lives entirely in the JavaScript world, which is fine if you’re in the JavaScript world — but a lot of us aren’t. I’ll show the same patterns across multiple bindings when it’s useful.

Who this is for

Testers who want to level up and think more like engineers. Developers who want to write tests that don’t embarrass them. Engineering managers who want their teams to stop yelling at each other. Junior folks trying to figure out which direction to grow. And anyone who’s ever inherited a test suite and wondered what on earth the last person was thinking.

If you want copy-paste tutorials with no opinions, this isn’t going to be your favorite blog. If you want to think harder about why you’re testing what you’re testing, stick around.

Why now

Honest answer: because I’m smarter than I was five years ago. I have more to offer, more patterns to share, and more opinions I’ve had the time to stress-test. The worst time to start a blog is whenever you’re waiting for the “right time.” The second-worst is five years from now. So here we are.

New posts will (hopefully) drop once or twice a week. Some will be short reactions, some will be deeper dives. All of them will be about testing, automation, and the stuff that actually comes up when you’re doing this work for real.

Thanks for being here on day one.

Go forth and test!

— Kevin

P.S. Full disclosure: I use AI to help me write these posts. I’m a tester, not a novelist, and if a robot can say what I mean more clearly than I can, I’m going to let it. The ideas, opinions, scars, and bad decisions are all mine. The em-dashes might be the AI’s fault.