Testowanie manualne i automatyczne: jakie są różnice i kiedy wybrać każde podejście

Testy automatyczne to testy wykonywane przez skrypt, który sam klika, wysyła żądania i porównuje wynik z oczekiwanym, a testy manualne wykonuje i ocenia człowiek. Testowanie manualne i automatyczne nie konkurują ze sobą: różnią się kosztem, szybkością i tym, jakie błędy potrafią znaleźć. Ten artykuł daje Wam macierz decyzyjną, która dla każdego przypadku testowego mówi, czy go automatyzować, oraz prosty przykład wyliczenia zwrotu.

Na blogu mamy dwa teksty o tej parze pojęć, więc krótko, który do czego służy. Ten odpowiada na pytanie, czym się różnią i jak zdecydować o pojedynczym teście. Artykuł testowanie manualne vs testowanie automatyczne pokazuje, jak ułożyć proporcje w całym zespole i jak policzyć próg opłacalności dla portfela testów. Pełny bilans korzyści i kosztów automatyzacji znajdziecie w tekście o zaletach i wadach automatyzacji testów.

Czym są testy manualne, a czym testy automatyczne?

W teście manualnym człowiek wykonuje kroki i decyduje, czy wynik jest poprawny. Może przy tym korzystać z narzędzi, na przykład DevTools, Postmana czy SQL, ale ocena należy do niego. Warsztat ręczny ze wzorami przypadku testowego, karty sesji i raportu błędu opisujemy w artykule o tym, czym są testy manualne i jakie są ich rodzaje.

W teście automatycznym kroki i ocenę zapisuje się w kodzie. Poniżej ten sam przypadek, który w artykule o testach manualnych wykonuje człowiek: darmowa dostawa od 200,00 zł. Test w Playwright przechodzi przez koszyk i sprawdza koszt dostawy przed progiem i po nim:

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

test('darmowa dostawa od 200,00 zł', async ({ page }) => {
  await page.goto('https://sklep.example.com/koszyk');
  await page.getByRole('button', { name: 'Dodaj produkt A' }).click();
  await expect(page.getByTestId('koszt-dostawy')).toHaveText('14,99 zł');
  await page.getByRole('button', { name: 'Dodaj produkt B' }).click();
  await expect(page.getByTestId('koszt-dostawy')).toHaveText('0,00 zł');
});

Ten skrypt wykona się w kilka sekund, o każdej porze i tysiąc razy z rzędu identycznie. Nie zauważy jednak, że koszt dostawy wyświetla się szarą czcionką na szarym tle, bo nikt mu nie kazał na to patrzeć. Na tym polega cała różnica: automat sprawdza dokładnie to, co mu zapisaliście, i nic więcej. Jeśli zaczynacie od narzędzia, porównanie znajdziecie w tekście Selenium, Cypress czy Playwright.

Czym różni się testowanie manualne od automatycznego w praktyce?

Tabela zestawia różnice, które realnie wpływają na decyzje w projekcie. Wiersze z kosztem i stabilnością są ważniejsze niż wiersz z szybkością, choć to szybkość zwykle pada jako pierwszy argument.

Wiersz o reużywalności prostuje częsty mit: przypadki testowe manualne są używane wielokrotnie, w każdej regresji i przy każdym retestcie. Różnica nie polega na tym, czy test da się powtórzyć, tylko na tym, ile kosztuje każde powtórzenie.

Czy testy automatyczne są niezawodne?

Nie, i to najważniejsza rzecz, którą warto wiedzieć przed budżetowaniem automatyzacji. Test automatyczny potrafi raz przejść, a raz nie przejść na tym samym kodzie, z powodu czasu odpowiedzi, kolejności zdarzeń albo współdzielonych danych. Google opisał skalę zjawiska w swoim Google Testing Blog (2016):

Wniosek nie brzmi: nie automatyzujcie. Brzmi: liczcie utrzymanie i analizę porażek jako stały koszt automatyzacji. Wzorce, które ograniczają niestabilność w Selenium, opisuje artykuł o wzorcach projektowych w Selenium WebDriver.

Jak zdecydować, który test automatyzować? Macierz decyzyjna z punktacją

Decyzję podejmujcie dla pojedynczego przypadku testowego, nie dla całego modułu. Oceńcie przypadek w pięciu kryteriach w skali od 0 do 3 i zsumujcie punkty. Wynik od 11 do 15 oznacza automatyzację teraz, od 7 do 10 kandydata do backlogu automatyzacji, a 6 i mniej test manualny. Jedna reguła ma pierwszeństwo przed sumą: jeśli wynik wymaga oceny człowieka (0 punktów w ostatnim kryterium), test zostaje manualny.

A tak macierz wygląda na przypadkach z typowego sklepu internetowego. Zwróćcie uwagę na onboarding: wysokie ryzyko nie wystarcza, gdy ekran zmienia się co sprint.

Ostatni wiersz pokazuje, że macierz nie jest automatem do decyzji. Migracja ma 8 punktów, ale wykona się raz, więc zamiast testu regresji piszecie jednorazowy skrypt porównujący dane. W naszych projektach macierz porządkuje rozmowę zespołu i zostawia ślad, dlaczego coś zautomatyzowaliście. Ten sam sposób myślenia ćwiczymy na szkoleniu strategia testowania od A do Z.

Kiedy testy automatyczne się zwracają? Prosty przykład wyliczenia

Zwrot z automatyzacji pojedynczego testu zależy od trzech liczb: czasu ręcznego wykonania, liczby uruchomień i kosztu napisania z utrzymaniem. Przykład dla przypadku z darmową dostawą. Test ręczny zajmuje 20 minut z przygotowaniem danych, napisanie testu automatycznego 6 godzin, a utrzymanie i analiza wyników średnio 15 minut tygodniowo.

Ten sam test przy rzadkich wydaniach zwraca się po ponad roku, a przy pracy w CI po kilku dniach. Dlatego pytanie, czy automatyzacja się Wam opłaca, nie ma sensu bez pytania, jak często wydajecie. Kalkulator progu opłacalności dla całego zestawu testów, z udziałem kosztu narzędzi i infrastruktury, pokazujemy w artykule testowanie manualne vs automatyczne.

Na większą skalę wygląda to tak, jak w projekcie dla Argos, firmy e-commerce: automatyzacja testów i uporządkowanie procesów QA skróciły regresję przed wydaniem z 5 dni do 10 godzin, a liczba błędów krytycznych na produkcji spadła o 46 procent (dane klienta z case study Quality Island). Przebieg tego projektu opisujemy w artykule jak skrócić testy regresyjne z 5 dni do 10 godzin.

Co automatyzować najpierw, a czego nie automatyzować wcale?

Zasada pierwszeństwa testów API ma źródło w piramidzie testów, którą Martin Fowler opisał w TestPyramid (2012): dużo szybkich testów na niskim poziomie, mało wolnych testów przez interfejs. Warstwy i proporcje omawiamy w tekście o piramidzie testów, a wdrożenie po stronie usług to automatyzacja testów API.

Jak testy manualne i automatyczne dzielą się pracą w CI/CD?

W zespole z ciągłą integracją testy automatyczne i manualne mają przypisane miejsca w potoku. Dzięki temu nikt nie pyta, czy coś zostało przetestowane, tylko na którym etapie.

Jeśli potok nie istnieje albo testy nie są do niego podpięte, automatyzacja daje ułamek możliwej wartości. Budowę takiego potoku obejmuje usługa automatyzacji testów, w której pracujemy na doświadczeniu z ponad 450 000 napisanych testów automatycznych.

Czy testy automatyczne zastąpią testy manualne?

Nie, i nie chodzi o sentyment. Test automatyczny sprawdza oczekiwanie, które ktoś wcześniej sformułował, a najdroższe błędy to te, których nikt nie przewidział. Sylabus ISTQB CTFL 4.0 (2023) wśród siedmiu zasad wymienia, że testowanie wyczerpujące jest niemożliwe, więc ktoś musi wybierać, co sprawdzić, i oceniać to, czego nie da się zapisać w asercji. Narzędzia AI przyspieszają pisanie testów i generowanie danych, ale wynik nadal trzeba przejrzeć i zrozumieć.

Zmienia się za to rola testera manualnego. U klientów, z którymi pracujemy, coraz mniej czasu idzie na ręczną regresję, a coraz więcej na analizę wymagań, eksplorację i ocenę ryzyka. Automat przejmuje nudne klikanie, a człowiekowi zostaje to, co ciekawe, czyli psucie aplikacji w sposób, na który nikt nie wpadł. Jak rozwijać się w tym kierunku, piszemy w poradniku jak stać się lepszym testerem.

Jakich kompetencji wymaga każde podejście?

Droga od testów manualnych do automatyzacji zaczyna się od fundamentów, nie od narzędzia. Fundament daje szkolenie ISTQB Certyfikowany Tester albo kompleksowy kurs testera manualnego, a pierwszy krok w kodzie szkolenie z automatyzacji testów w Playwright lub z automatyzacji testów w Selenium. Pełną listę znajdziecie w szkoleniach z automatyzacji testów. Kandydatów z obu ścieżek łączy z firmami QA Board, a o tym, jak zespoły dzielą pracę między ludzi i automaty, rozmawia się co roku na Testing Ground Conference.

Powiązane na blogu Quality Island

• Testowanie manualne vs testowanie automatyczne: jak wybrać i kiedy łączyć oba podejścia
• Testy manualne: rodzaje i wzory do skopiowania
• Zalety i wady automatyzacji testów: kiedy się opłaca i jak policzyć ROI
• Jak skrócić testy regresyjne z 5 dni do 10 godzin: case Argos
• Piramida testów: warstwy, proporcje i techniki projektowania testów

Pełna lista źródeł

• John Micco, Google Testing Blog, Flaky Tests at Google and How We Mitigate Them (2016)
• Martin Fowler, TestPyramid (2012)
• Ham Vocke, Martin Fowler, The Practical Test Pyramid (2018)
• ISTQB, Certified Tester Foundation Level, sylabus 4.0 (2023)
• Playwright, Writing tests (2025)
• Quality Island, case study Argos i dane własne o liczbie testów automatycznych (2026)