The long way around

I build things, break things, and figure out why. That last part is the job.

I’m Kishan Gondaliya, a Senior Quality Engineer at rtCamp. I’ve been doing this since January 2022, which is long enough to have opinions and not so long that I’ve stopped noticing when they’re wrong.

A little about me

I started at Crest Data Systems, testing security and data products for companies like Palo Alto, CrowdStrike, Anvilogic and Netskope. In three years, I worked across multiple modules, integrations and plugins - Python and FastAPI on the backend, PostgreSQL and MongoDB underneath, Docker and Celery holding it together.

What that work taught me was unglamorous and useful: you cannot test a system you do not understand. Enterprise security integrations fail in ways that have nothing to do with the feature you were handed. They fail because a queue backed up, because a token expired mid-sync, because two services disagreed about what a timestamp meant. None of that is in the acceptance criteria.

So I spent less time writing test cases and more time reading architecture. The automation came after — eventually cutting our testing effort by about 40%, not because I automated everything, but because understanding the system told me what was actually worth automating.

In January 2025 I moved to rtCamp, where I work on GoDAM — a digital asset management and video platform for WordPress. Different domain, same shape of problem.

The work that shaped how I think

Quality for GoDAM means the WordPress plugin, the admin surfaces, the transcoding pipeline and the front-end player — and the places where those four disagree with each other. Playwright suites run on every change. Accessibility and security audits run against WCAG and GDPR, and they block releases rather than becoming a PDF nobody opens.

The piece I’m most pleased with is the performance work: measuring GoDAM-enabled WooCommerce storefronts against non-GoDAM baselines, so the cost of putting video on a page is a number we can argue with, rather than a vibe someone has in a meeting.

That’s the pattern I keep returning to. Most quality arguments are really measurement arguments wearing a disguise.

Why I’m writing now

Something changed in the last couple of years, and I don’t think the testing profession has caught up to it.

AI made writing code dramatically cheaper. It did not make knowing whether the code is right any cheaper at all. If anything it made it harder, because the output is fluent, confident, and wrong in ways that don’t look like the way humans are wrong. A human-written bug often has a tell. A model’s bug can read like it was written by someone who understood the problem.

So the bottleneck moved. It used to sit with implementation. Now it sits with whoever has to believe the implementation. Increasingly, that’s a quality problem — and a much more interesting engineering problem than it used to be.

What this blog will be

Things I’ve had to work out on real projects, written down while they’re still fresh and before I’ve convinced myself I understood them perfectly the whole time.

Concretely, I expect that to mean:

• Test design that survives contact with reality — why most flaky tests are a race the application lost rather than a flake, and how to tell the two apart.
• Performance and accessibility as gates, not reports — turning Lighthouse numbers and WCAG findings into something that fails a build.
• Working with AI as an engineer rather than a passenger — what I’ve found the Claude skills I publish here are good and bad at, honestly.
• The gaps between what was requested, what was built, and what users needed — the part of the job no ticket ever describes.

I’ll be wrong in public sometimes. That seems like a reasonable price.

If any of this is useful to you, the feed is the easiest way to catch the next one. If you want to argue with me about something here, I’d genuinely enjoy that — email me.