Testing and QA

I design test strategies, write automated tests with Playwright and Vitest, and build them into the delivery process so they run before every change goes out.

Who it is for

Mainly development teams and web agencies looking for external test automation capacity. Also companies whose software often breaks when it is changed.

What I work on

Test strategy
What is worth checking with unit, integration and end-to-end (E2E) tests, and what is not.
Test automation
Browser E2E tests with Playwright, unit and integration tests with Vitest.
Test-driven development
The failing test comes first, then the code. That shows the test really checks what it should.
Quality gate
Automated checks that stop a faulty change before it reaches production.
Accessibility testing
Automated axe checks, plus manual testing with a keyboard and the NVDA screen reader.
Reproducing bugs
A reported bug first becomes a test that shows it, then comes the fix.

Working together

  • When to ask for outside help: when manual testing slows down releases, when the same bugs keep coming back, or when nobody is available to build the test automation.
  • A way to start: a survey of the critical user flows and a limited pilot test suite. The exact scope is always agreed first.
  • What is needed to start: access to the code or a test environment, a description of the main user flows, and information about the existing CI process.

A test from this site

A browser check of the quality gate in Playwright, shortened: Escape closes the mobile menu and focus returns to the menu button. It runs before every release.

// scripts/audit/interactions.ts
await page.click('#menu-button');
await page.keyboard.press('Escape');
const closed = await page.evaluate(() => {
  const button = document.getElementById('menu-button');
  const nav = document.getElementById('site-nav');
  return button?.getAttribute('aria-expanded') === 'false'
    && getComputedStyle(nav).display === 'none'
    && document.activeElement === button;
});
if (!closed) add('menu-escape', paths.page, 'Escape must close the menu …');

What you get at the end

  • A test plan: what we check, at which level and why.
  • Automated tests in the project repository, with readable names.
  • A configured run that happens before every change goes out.
  • A write-up on adding new tests and reproducing bugs.

How I set it up

  1. 1. Risk. Where would a bug hurt most? That is where testing starts.
  2. 2. Fast feedback. Most checks are fast unit tests. The slower E2E tests cover the critical paths.
  3. 3. Part of the process. Tests run before every change goes out, and the result is clear: pass or fail.
  4. 4. Maintainable. Readable test names, one behaviour per test, mocks only where they cannot be avoided.

Tools

Playwright, Vitest, axe-core, Lighthouse, TypeScript, Node.js, Git

Frequently asked questions

Do I need 100% coverage?

No. Coverage shows which lines ran, not whether a test would notice a bug. I prefer fewer tests that fail when the behaviour breaks.

What should be tested first?

Whatever a bug would cost the most: sign-in, payment, saving data, forms. These get E2E tests, the rest of the logic gets fast unit tests.

Can it be added to an existing project?

Yes. Playwright and Vitest run next to the existing code without rewriting anything. I usually start with E2E tests for the critical paths, because they give the most safety the quickest.

levikaldor.hu quality gate: SEO, accessibility, GDPR and Lighthouse, automated

Let's talk

Are you a development team or an agency that needs help with testing? Briefly describe the product and we can agree on the scope of a pilot.

Discuss test collaboration

Put the project together step by step, with an informative estimate