What developers should test, and what QA should test

I’ve heard “who should test this?” in every team I’ve worked in. Usually it gets asked after the bug has already reached production. That’s why I prefer to agree on the split up front.

The general rule

The developer is responsible for making sure the code does what they intended. QA is responsible for making sure the product does what the user needs. Those are two different questions, and each one calls for different tests.

What developers test

• Unit tests for business logic: calculations, validation, data transformations.
• Integration tests of their own code against the database, a queue or an external API.
• Edge cases they know about from the implementation: empty data, limits, network errors.
• Testability: code that can be tested without spinning up the whole environment.

What QA tests

• Test strategy: what carries the most risk and where it’s worth investing time.
• Exploratory testing: deliberately looking for behavior nobody anticipated.
• Critical E2E paths: sign-up, payment, booking, anything that brings in money.
• Accessibility and user experience: keyboard, screen reader, error messages.

A shared language: acceptance criteria

This works best when acceptance criteria are written together, before anyone starts writing code. Gherkin helps, because people can read it without knowing how to program. It isn’t tied to English either, so you can write it in Polish too.

Feature: Booking a session

  Scenario: The user sees the price before going to the calendar
    Given I am on the "Testing and QA" path page
    When I go to the session details
    Then I see how long the session lasts
    And I see the price for 60 minutes

A scenario like this can later be turned into an automated test. Who writes it is up to the team to agree on. In my teams, the developer usually writes the test for a new feature, and QA extends it with the cases the developer didn’t anticipate.

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

test('price is visible before booking', async ({ page }) => {
  await page.goto('/mentoring/software-testing-qa/');
  const box = page.getByRole('complementary', { name: 'Session details' });

  await expect(box.getByText('60 min')).toBeVisible();
  await expect(box.getByText(/PLN/)).toBeVisible();
});

Where the gaps usually appear

I see the most bugs at the boundary: the developer assumes QA will check the integration, and QA assumes the developer covered the edge cases. One simple practice helps: for every task, we write down in its description what was tested and by whom.

Finally

The split doesn’t have to be perfect. It has to be explicit. If nobody on your team can say who’s responsible for testing a given feature, start there, before you buy yet another test automation tool.