Co powinien testować developer, a co QA

Pytanie „kto powinien to przetestować?” słyszałem w każdym zespole, w którym pracowałem. Zwykle zadawane już po tym, jak błąd trafił na produkcję. Dlatego wolę ustalić podział wcześniej.

Zasada ogólna

Developer odpowiada za to, żeby kod robił to, co zamierzył. QA odpowiada za to, żeby produkt robił to, czego potrzebuje użytkownik. To dwa różne pytania i oba wymagają innych testów.

Co testuje developer

• Testy jednostkowe logiki biznesowej: obliczenia, walidacje, przekształcenia danych.
• Testy integracyjne własnego kodu z bazą, kolejką czy zewnętrznym API.
• Przypadki brzegowe, które zna z implementacji: puste dane, limity, błędy sieci.
• Testowalność: kod, który da się przetestować bez stawiania całego środowiska.

Co testuje QA

• Strategię testów: co jest najbardziej ryzykowne i gdzie warto zainwestować czas.
• Testy eksploracyjne: świadome szukanie zachowań, których nikt nie przewidział.
• Krytyczne ścieżki E2E: rejestracja, płatność, rezerwacja, wszystko, co przynosi pieniądze.
• Dostępność i doświadczenie użytkownika: klawiatura, czytnik ekranu, komunikaty błędów.

Wspólny język: kryteria akceptacji

Najlepiej działa to wtedy, gdy kryteria akceptacji powstają razem, zanim ktokolwiek zacznie pisać kod. Format Gherkin pomaga, bo da się go przeczytać bez znajomości programowania, także po polsku.

# language: pl
Funkcja: Rezerwacja spotkania

  Scenariusz: Użytkownik widzi cenę przed przejściem do kalendarza
    Zakładając że jestem na stronie ścieżki "Testowanie i QA"
    Kiedy przejdę do szczegółów spotkania
    Wtedy widzę czas trwania spotkania
    Oraz widzę cenę za 60 minut

Taki scenariusz można potem zamienić na test automatyczny. Kto go napisze, to już kwestia umowy w zespole. U mnie zwykle developer pisze test do nowej funkcji, a QA rozbudowuje go o przypadki, których developer nie przewidział.

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

test('cena jest widoczna przed rezerwacją', async ({ page }) => {
  await page.goto('/mentoring/testowanie-qa/');
  const box = page.getByRole('complementary', { name: 'Szczegóły spotkania' });

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

Gdzie najczęściej powstają dziury

Najwięcej błędów widzę na styku: developer zakłada, że QA sprawdzi integrację, QA zakłada, że developer sprawdził przypadki brzegowe. Pomaga jedna prosta praktyka: przy każdym zadaniu zapisujemy w opisie, co zostało przetestowane i przez kogo.

Na koniec

Podział nie musi być idealny, musi być jawny. Jeśli w Twoim zespole nikt nie potrafi powiedzieć, kto odpowiada za testy danej funkcji, to od tego zacznij, zanim kupisz kolejne narzędzie do automatyzacji.