DEV Community: Enis Kovac

What If You Could Test Your Web App Just by Describing What to Test?

Enis Kovac — Wed, 18 Mar 2026 14:13:43 +0000

That's the question we kept coming back to when building Lama.

Not "how do we make test scripting faster?" Not "how do we reduce selector fragility?" Those are symptoms. The real question was simpler: why does testing still require you to think like a machine when you already know exactly what you want to verify?

You know the checkout flow needs to work. You know the login should reject bad credentials. You know the returns flow should redirect correctly. That knowledge exists in your head right now — in plain English.

The gap between knowing what to test and having a test that proves it works — that's what we built Lama to close.

How It Works

Lama is an AI-powered IDE for testing. You open it, type what you want to test in plain English, and the agent takes over.

You type:

Test the checkout flow.

Lama opens a real browser, navigates to your application, and works through it the way a human tester would — clicking buttons, filling forms, verifying pages load correctly, checking that the right things appear after each action. Every browser interaction surfaces as a tool call in the chat panel alongside the agent's reasoning, so you can follow exactly what it's doing and why.

Once it has explored the flow, Lama writes a production-ready test file. Not a proprietary script. Not a recorded macro. A real checkout.spec.ts in Playwright:

import { test, expect } from '@playwright/test';

test.describe('Checkout flow', () => {

  test.beforeEach(async ({ page }) => {
    // Log in and seed cart before each test
    await page.goto('/login');
    await page.getByLabel('Email').fill('testuser@acme.com');
    await page.getByLabel('Password').fill('s3cureP@ss');
    await page.getByRole('button', { name: 'Sign in' }).click();
    await expect(page).toHaveURL(/dashboard/);

    // Add item to cart via API for speed
    await page.request.post('/api/cart/items', {
      data: { productId: 'prod_abc123', quantity: 2 }
    });
  });

  test('completes checkout with valid card and verifies order', async ({ page }) => {
    await page.goto('/cart');
    await expect(page.getByTestId('cart-item-count')).toHaveText('2');

    await page.getByRole('button', { name: 'Proceed to checkout' }).click();
    await expect(page).toHaveURL(/checkout/);

    // Fill shipping details
    await page.getByLabel('Full name').fill('Jane Smith');
    await page.getByLabel('Address').fill('123 Main St');
    await page.getByLabel('City').fill('New York');
    await page.getByLabel('ZIP code').fill('10001');
    await page.getByRole('button', { name: 'Continue to payment' }).click();

    // Fill payment details inside Stripe iframe
    const stripeFrame = page.frameLocator('iframe[name="stripe-card"]');
    await stripeFrame.getByPlaceholder('Card number').fill('4242424242424242');
    await stripeFrame.getByPlaceholder('MM / YY').fill('12/26');
    await stripeFrame.getByPlaceholder('CVC').fill('123');

    await page.getByRole('button', { name: 'Pay now' }).click();

    // Wait for redirect and verify confirmation
    await expect(page).toHaveURL(/order-confirmation/);
    await expect(page.getByText('Order confirmed')).toBeVisible();
    await expect(page.getByTestId('order-id')).not.toBeEmpty();

    // Verify confirmation email trigger (mocked)
    const emailRequest = page.waitForRequest(req =>
      req.url().includes('/api/notifications/email') && req.method() === 'POST'
    );
    await expect(emailRequest).resolves.toBeTruthy();
  });

  test('shows error for declined card and stays on payment page', async ({ page }) => {
    await page.goto('/checkout');
    const stripeFrame = page.frameLocator('iframe[name="stripe-card"]');
    await stripeFrame.getByPlaceholder('Card number').fill('4000000000000002'); // Stripe decline card
    await stripeFrame.getByPlaceholder('MM / YY').fill('12/26');
    await stripeFrame.getByPlaceholder('CVC').fill('123');

    await page.getByRole('button', { name: 'Pay now' }).click();

    await expect(page.getByText('Your card was declined')).toBeVisible();
    await expect(page).toHaveURL(/checkout/);
  });

});

Standard Playwright. No wrapper. No proprietary format. It lives in your repo and runs in your CI like any other test your team wrote.

You then ask it to test another flow:

Now test the returns flow.

Same process. A returns.spec.ts appears in the editor.

No recording sessions. No selector hunting. No boilerplate.

Beyond Test Generation

Writing the tests is only part of it.

Once you have test files, you can organize them into groups through a simple context menu — by feature, sprint, priority, or however your team thinks. The Tests panel gives you a flat view of everything, with a single "Run All" button.

When you run them, you watch the queue move in real time — each test cycling through queued → running → passed. A results summary bar at the end shows what passed and what needs attention.

It's a complete testing workspace: write, organize, run, review — without leaving the app.

What We're Not Claiming

Lama is in research preview. It's genuinely useful today for standard web application testing and generates accurate, runnable tests across a wide range of flows.

But it's not magic, and we'd rather be honest about the edges:

Works best on standard web flows — forms, navigation, state changes
Mobile testing is not supported yet
Visual regression testing is not yet included

We're building in public and iterating on real feedback. The research preview exists precisely so we can learn from people using it on real applications — not demo apps.

Why This Matters to Developers

The average QA engineer spends a significant chunk of their week not actually testing — but writing and maintaining the infrastructure that enables testing. That overhead is why test coverage feels expensive. That's why teams skip sprints. That's why "we'll do it next week" keeps getting said.

And for developers who want to verify their own implementation — not hand it off to QA — the barrier of setting up a full test suite often makes it easier to just ship and hope.

Lama doesn't solve deadline pressure or org culture. But it does make the mechanical part — turning what you know into working test code — fast enough that the friction largely disappears.

When writing a test takes two minutes instead of two hours, the decision to skip it stops making sense.

Try It

Free to use. Top up AI credits as you go — no subscription, no monthly commitment.

If you're a QA engineer, a developer wanting to verify your own work, or a founder who can't justify a dedicated QA hire yet — we'd genuinely love your feedback.

🔗 lamaqa.com

Honest feedback — positive or negative — is exactly what the research preview is for.

The System Is Set Up to Skip QA. Here's What We Can Actually Fix.

Enis Kovac — Mon, 16 Mar 2026 13:23:04 +0000

I've been building software for over a decade.

Agency work, startups, enterprises, freelance projects. Different industries, different stacks, different team cultures.

But some things are always the same.

The developer staying late because a bug slipped through. The PM explaining to a client why something is broken in production. The QA engineer who knew something was off but didn't have enough time to verify it properly.

Nobody wanted that outcome. Everyone was doing their best. The process just wasn't set up to prevent it.

It's Not a People Problem

Most software quality problems aren't about people not caring. They're structural.

The incentives push toward speed. The tooling makes quality expensive. So quality loses — not because teams are negligent, but because the math doesn't work in quality's favor.

Think about how a typical sprint plays out:

PM scopes the work. Takes longer than planned. Deadline stays fixed.
Dev builds it. Takes longer than planned. Deadline stays fixed.
QA gets what's left. Which is usually not enough.

Nobody decided this was acceptable. It just kept happening until it felt normal.

And at the end of that chain, the QA engineer is left with a choice: do a partial job under pressure, or hold the line and become "the reason we missed the deadline."

That's not a QA problem. That's a system problem.

Can the System Be Fixed?

Honestly? I'm not sure.

The incentives, the deadline culture, the way organizations prioritize shipping over stability — those are deeply embedded. No tool is going to fix a company culture that treats QA as optional.

But here's what I do think can be fixed:

What happens when that huge scope lands on QA's table with half the time it needs.

That's the specific, concrete, solvable problem. Not the politics. Not the culture. Just — when the pressure is on and the time is short, how do we make sure the critical flows still get tested?

The Technical Reality of "No Time to Test"

When QA time gets squeezed, what actually gets cut?

Usually it's automation. Manual smoke testing survives because it feels faster in the moment. Automated test scripts get deferred because writing them takes time.

And that deferral compounds. The longer you go without automation, the more ground you have to make up. Until eventually the backlog is so large it never gets addressed.

Here's what a basic Playwright test for a checkout flow looks like:

import { test, expect } from '@playwright/test';

test('complete checkout with valid card', async ({ page }) => {
  await page.goto('/cart');
  await page.getByRole('button', { name: 'Proceed to checkout' }).click();
  await page.getByLabel('Card number').fill('4242424242424242');
  await page.getByLabel('Expiry').fill('12/26');
  await page.getByLabel('CVC').fill('123');
  await page.getByRole('button', { name: 'Pay now' }).click();
  await expect(page.getByText('Order confirmed')).toBeVisible();
});

That's one flow. One happy path. Under pressure, this is the test that either gets written in 20 minutes or gets pushed to "next sprint."

Most of the time, it gets pushed.

What We Built

This is the exact problem we set out to solve with Lama.

No proprietary format. No lock-in. Real code that lives in your repo, runs in your CI, and works whether or not you keep using Lama.

The goal isn't to fix broken team culture. The goal is to make sure that when the pressure is on and the scope is huge — quality doesn't have to be the thing that pays the price.

We just launched as research preview. Free to use, credits top up as you go.

If you've felt this pressure firsthand — I'd genuinely love to hear how your team handles it.

🔗 lamaqa.com

Automated Testing Isn’t Hard. Making Time for It Is.

Enis Kovac — Fri, 13 Mar 2026 09:17:55 +0000

A few months ago I found myself googling "why do teams skip automated testing."

I already knew the answer. I just wanted to see if everyone else did too.

They do.

And yet teams keep skipping it. Projects keep shipping without proper coverage. Bugs keep reaching production. And the cycle repeats itself every sprint.

So if everyone knows the problem, why does nothing change?

It Comes Down to Two Things

The first is tooling.

Writing automated tests has always been harder than it should be. You need to identify the right selectors. Write assertions. Handle async timing. Think through edge cases. And the moment someone renames a CSS class or moves a button, your carefully written test suite breaks and you're back to square one.

It's not that engineers can't do it. It's that it takes time nobody has. So it gets deprioritized. Then skipped. Then forgotten.

The second is deadlines.

"We'll do it properly next week."

That's the sentence that kills test coverage in most teams. It sounds reasonable in the moment. The deadline is real. The pressure is real. Skipping one sprint of automation feels like a small trade-off.

But next week never comes.

The backlog grows. The coverage shrinks. Features pile on top of untested features. And eventually nobody remembers when proper automated testing was last a priority, because it's been so long that it just feels normal to ship without it.

What Happens When You Skip It Long Enough

You ship bugs that a 10-minute test would have caught.

You spend an evening on an emergency hotfix that could have been avoided.

You write the client email that carefully avoids saying what it's actually saying.

And your team's confidence in what they're shipping quietly erodes, sprint by sprint, release by release.

The cost of skipping testing isn't paid immediately. It's paid in instalments. Which makes it easy to keep deferring until the bill is too big to ignore.

Why We Built Lama

This dynamic is the entire reason Lama exists.

Not to replace QA engineers, they're the ones who actually understand quality. But to remove the friction that makes automated testing feel like a luxury instead of a baseline.

Lama is an AI QA agent that navigates your app in a real browser and generates native Playwright, Cypress, or Selenium test code from a plain English description. You describe the flow. It writes the test. No proprietary format, no lock-in, just real code that lives in your repo and runs in your CI like anything your team wrote.

The goal is simple: make automated testing cheap enough that "we'll do it next week" stops being a sentence anyone needs to say.

One Week In

We launched the public beta this week.

The feedback has been better than I expected, and more honest than I expected, which I appreciate even more.

There's still a long road ahead. Building something people actually use and trust takes time. But the problem is real. The people feeling it are real. And that keeps you going on the weeks when everything feels hard.

If you're curious, free to use, top up credits as you go.

🔗 lamaqa.com

We'll Test It Properly Once Things Slow Down

Enis Kovac — Thu, 12 Mar 2026 10:00:08 +0000

"We'll Test It Properly Once Things Slow Down"

They won't. Here's what actually happens.

I've heard this line more times than I can count.

In startups burning through runway. In enterprises with dedicated QA teams. In agencies with 50 developers and a process document nobody reads.

"We'll test it properly once things slow down."

Things never slow down.

So testing gets squeezed. Then skipped. Then something reaches production that shouldn't have, and suddenly the whole team has time. Time for the incident call. Time for the hotfix. Time for the post-mortem. Time for the client apology email that someone has to carefully word so it doesn't sound like what it actually is.

A bug that a 10-minute test would have caught.

Why this keeps happening

It's not laziness. It's not incompetence.

It's that writing proper automated tests takes time — time that feels like it's coming out of shipping time, even though skipping it costs far more later.

A typical Playwright test for a login flow:

import { test, expect } from '@playwright/test';

test('successful login', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Password').fill('password123');
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page).toHaveURL(/dashboard/);
});

That's one test. One flow. One happy path.

Now multiply that across every feature, every sprint, every time the UI changes and half your selectors break. You can see why teams push it to "later."

The tooling hasn't kept up with the pace teams are expected to ship at. So testing becomes the thing you do when you have time, which is never.

The only fix that actually works

The teams that consistently ship with confidence aren't the ones with more time.

They're the ones who made testing cheap enough to do every sprint without thinking about it.

That's the problem we built Lama to solve — an AI QA agent that navigates your app in a real browser and generates native Playwright, Cypress, or Selenium test code from a plain English description.

You describe the flow. It writes the test. You commit it, run it in CI, move on.

No proprietary format. No lock-in. Just test code that lives in your repo like any other code your team writes.

We just launched public beta, free to use, credits top-up as you go.

"We'll test it later" only works as a strategy until it doesn't.

What's the worst bug you've ever shipped because testing got pushed? Drop it in the comments — genuinely curious.

QA Is Always the Breaking Point. So We Built Something About It.

Enis Kovac — Wed, 11 Mar 2026 13:31:13 +0000

QA Is Always the Breaking Point. So We Built Something About It.

There's a pattern I've seen in almost every software team I've worked with over the past decade.

PM scopes the project. Runs over. That's fine.

Devs build it. Runs over. Also fine.

Then it lands on QA - and suddenly every hour counts.

The engineers who had nothing to do with the delays are now the reason the deadline slips. The people absorbing the entire weight of everyone else's overruns are the ones getting pressured to cut corners.

I've watched good QA engineers burn out over this. Not because the work was too hard. Because the structure was unfair.

The Technical Side of the Problem

Beyond the politics, there's a real technical burden that doesn't get talked about enough.

Writing automated test scripts is genuinely tedious work.

You need to identify selectors. Write assertions. Handle async timing. Cover edge cases. And then - the moment a developer renames a class or restructures a component - half your test suite breaks and you're back to square one.

Here's what a basic Playwright login test looks like when written by hand:

import { test, expect } from '@playwright/test';

test('successful login with valid credentials', async ({ page }) => {
  await page.goto('/login');

  await page.getByLabel('Email').fill('jane@acme.com');
  await page.getByLabel('Password').fill('s3cureP@ss');
  await page.getByRole('button', { name: 'Sign in' }).click();

  await expect(page).toHaveURL(/dashboard/);
  await expect(page.getByText('Welcome back, Jane')).toBeVisible();
});

test('shows error for invalid password', async ({ page }) => {
  await page.goto('/login');

  await page.getByLabel('Email').fill('jane@acme.com');
  await page.getByLabel('Password').fill('wrongpass');
  await page.getByRole('button', { name: 'Sign in' }).click();

  await expect(page.getByText('Invalid credentials')).toBeVisible();
  await expect(page).toHaveURL(/login/);
});

That's a simple login flow. Two test cases. Experienced engineer, maybe 15-20 minutes to write properly, including thinking through the edge cases.

Now multiply that across an entire application. Every feature. Every sprint. Every time the UI changes.

That's where the hours go.

What We Built

This is the problem we set out to solve with Lama - an AI QA agent that navigates your app in a real browser and generates test code from a plain English description.

Instead of writing the above manually, you tell Lama:

"Test the login page. Verify successful login redirects to the dashboard. Verify that an invalid password shows an error and stays on the login page."

Lama opens a real browser, navigates to your app, interacts with it, reads the DOM, and generates the test code above - ready to commit and run in your CI.

No proprietary format. No wrapper library. Pure Playwright, Cypress, or Selenium - whichever you already use.

The Part I'm Most Proud Of

The code generation is useful. But the knowledge system is the real unlock.

Every time Lama interacts with your app, it builds a map - pages, flows, components, behaviors. That knowledge persists across sessions. On team plans, it's shared across the whole team.

So when a new sprint lands and everyone's staring at QA again, your engineer isn't starting from scratch. Lama already knows the app. It just needs to know what changed.

QA knowledge that used to live in one engineer's head - or worse, nowhere - now compounds over time.

Try It

We just launched as research preview.

The app is free to use - you top up AI credits as you go, no subscription required. The free tier is enough to get a real feel for what it can do.

If you're a QA engineer tired of being last in the pipeline and first to be blamed - or a dev who just wants to quickly verify your own implementation actually works - give it a shot.

🔗 lamaqa.com

Honest feedback welcome.