Why Haiku
Testing required a programmer. We think that's wrong.
Not because understanding software requires code. Not because QA leads, product managers, or founders lack the knowledge to describe what software should do. But because every test framework, from Selenium to XCTest to Cypress to pytest, was built by engineers, for engineers. They assumed the author of a test is the same person who can write a for-loop.
That assumption locked out most of your team.
Your QA lead has filed a thousand bugs. Your PM wrote the user stories. Your founder knows every edge case. None of them have a path into your test suite. Not because they lack the understanding. Because the tools demand code.
Why testing matters
A test is a promise. It says: here is what our software should do. When it passes, you have confidence. When it fails, you know where to look.
That promise has a name: intent. The intent of a test is the behavior that matters: what the user does, what the system should do in response, what the outcome should be. Intent is separate from implementation. But in a typical test suite, the two are tangled together. The intent hides inside selector strings, mock setups, and assertion chains. You have to read the code to excavate it. Most of your team can't.
“It carries the complete intent.” That's the phrase we keep returning to. A plain English test has nowhere to hide its intent. The sentence isthe intent. Anyone who reads it knows exactly what promise is being kept. Anyone who edits it knows exactly what promise they're changing.
When intent is visible, testing stops being a specialist activity. The QA lead can write it. The PM can challenge it. The engineer can run it. That's a different kind of confidence, one that belongs to the whole team.
What we believe
Tests should be authored in the language you think in, not the language the machine runs.
Take a plain English description of a user flow: “Launch the app. Enter your email. Tap Sign In. Verify the dashboard appears.” That is not a sketch of a test. It is the test. It carries the complete intent. Everything else is something Haiku handles for you: the selector logic, the assertion framework, the runner configuration.
The .haiku file is the only thing you write and maintain. Plain English in, passing tests out.
Anyone can author a test.
If you can describe what software should do, whether as a sentence, a user story, or a numbered list of steps, you can write a .haiku file. No framework knowledge required. No selector syntax. No language runtime.
Tests don't drift.
Plain English intent doesn't go stale the way selector-based tests do. When your UI changes, you update the sentence. Not hunt through CSS class names or XPath queries. The source is readable. The source is honest.
Your whole team is in the room.
QA leads, product managers, and engineers can all read, write, and challenge the same test file. Testing becomes a shared activity, not a specialist skill.
If you share this belief, we built this for you.
Haiku is in early access. The CLI is available now. Join the waitlist. We'll let you know when it's ready, and we'd love to hear what you think.