Testowanie manualne vs automatyczne: jakie proporcje i kiedy automatyzacja się zwraca

Testowanie manualne vs automatyczne to w praktyce nie wybór jednego z dwóch, tylko pytanie o proporcje: jaką część zestawu regresji opłaca się oddać skryptom, a jaką świadomie zostawić ludziom. Automat wygrywa tam, gdzie test uruchamiacie wiele razy i wynik jest jednoznaczny; człowiek tam, gdzie liczą się osąd, kontekst i ciekawość. Ten tekst daje Wam narzędzia do tej decyzji: kalkulator progu opłacalności całego zestawu liczony przyrostowo, kolejność automatyzacji, model proporcji oparty na piramidzie i kwadrantach z sylabusa ISTQB v4.0 oraz rytm pracy zespołu, w którym oba podejścia się uzupełniają.

Jeśli szukacie zestawienia różnic i macierzy decyzji dla pojedynczego przypadku testowego, opisaliśmy je osobno w artykule testowanie manualne i automatyczne: jakie są różnice. Bilans zalet i wad automatyzacji znajdziecie w tekście o zaletach i wadach automatyzacji testów. Tutaj patrzymy na cały zestaw testów i cały zespół.

Dlaczego „manualne czy automatyczne” to złe pytanie?

Pytanie „manualne czy automatyczne” pada zwykle wtedy, gdy regresja rośnie szybciej niż zespół, albo gdy ktoś z zarządu przeczytał, że automatyzacja „rozwiązuje problem testów”. Kłopot w tym, że odpowiedź dla całego projektu nie istnieje. W tym samym sklepie internetowym test naliczania rabatu przez API opłaca się zautomatyzować w pierwszym tygodniu, a ocena, czy nowy koszyk jest zrozumiały dla klienta, nigdy nie będzie zadaniem dla skryptu.

Sylabus ISTQB Certyfikowany Tester v4.0 ujmuje to dyplomatycznie: wśród ryzyk automatyzacji wymienia zarówno użycie narzędzia tam, gdzie lepiej sprawdzi się testowanie manualne, jak i nadmierne poleganie na narzędziu z pominięciem krytycznego myślenia. Oba ryzyka biorą się z tego samego błędu: decyzji podjętej dla całego projektu zamiast dla konkretnego testu.

Czym jest testowanie manualne, a czym automatyczne?

Krótko, bo pełne definicje są w artykule o różnicach. Testowanie manualne to wykonanie testu przez człowieka: tester przechodzi kroki przypadku testowego albo prowadzi sesję eksploracyjną i ocenia wynik. Testowanie automatyczne to wykonanie testu przez skrypt albo narzędzie, które porównuje rzeczywisty wynik z oczekiwanym, zwykle w potoku CI po każdej zmianie.

Ważne rozróżnienie, o którym zapomina się w dyskusjach: automatyzujecie wykonanie i porównanie wyników, a nie myślenie. Projekt przypadku testowego, dobór danych, decyzja, co jest wynikiem oczekiwanym, i analiza niezaliczonego testu pozostają pracą człowieka w obu podejściach.

Jakie mity krążą o obu podejściach?

W wielu tekstach o tym temacie, także w starszej wersji tego artykułu, powtarzały się dwa uproszczenia. Warto je sprostować, bo prowadzą do złych decyzji budżetowych.

Źródło: sylabus ISTQB CTFL v4.0.1, 2024; John Micco, Google Testing Blog, 2016.

Po ilu cyklach regresji automatyzacja się zwraca? Kalkulator progu opłacalności

Najważniejsza poprawka do typowej dyskusji to policzenie progu nie dla abstrakcyjnej „automatyzacji”, tylko dla konkretnej części zestawu regresji. Potrzebujecie trzech liczb, które zespół zna z doświadczenia albo zmierzy w jednym cyklu regresji.

N = K / (H_m - H_a)

K    jednorazowy koszt zbudowania automatów dla wybranej
     części zestawu regresji (godziny pracy)
H_m  godziny ręcznego wykonania tej części w jednym cyklu
H_a  godziny utrzymania automatów i analizy ich wyników
     w jednym cyklu, także fałszywych alarmów
N    liczba cykli regresji, po której ta część się zwraca

Jeśli H_a >= H_m, ta część zestawu nie zwróci się nigdy.

Policzmy to na przykładowym zestawie 300 przypadków testowych, z których każdy wykonany ręcznie zajmuje średnio 15 minut, czyli 75 godzin na pełną regresję. Kluczowe jest liczenie przyrostowe: każda kolejna porcja automatów jest droższa w napisaniu i utrzymaniu niż poprzednia, bo najpierw automatyzujecie to, co najprostsze i najstabilniejsze. Liczby są przykładowe, ale rzędy wielkości odpowiadają temu, co widzimy w projektach klientów.

Źródło: przykład Quality Island, 2026; wzór progu opłacalności N = K / (H_m − H_a) liczony przyrostowo.

Z tej tabeli wynika odpowiedź na pytanie o proporcje: w tym przykładzie rozsądny cel to około 70% zestawu regresji w automatach, a pozostałe 30% to świadomie testy manualne, czyli 22,5 godziny pracy ludzi na cykl zamiast 75. Każdy kolejny procent automatyzacji kosztuje więcej, niż oszczędza. Ostatnie 10% automatyzacji to jak malowanie płotu, który sąsiad przestawia co dwa tygodnie. Wasz próg może wypaść przy 50% albo przy 85%, ale zawsze wyznacza go koszt utrzymania, a nie ambicja.

Rachunek zalet i wad automatyzacji z perspektywy budżetu i ryzyka opisujemy w artykule o zaletach i wadach automatyzacji testów. Przykład z praktyki: w projekcie dla Argos 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%. Cały przebieg opisaliśmy w case study jak skrócić testy regresyjne.

W jakiej kolejności automatyzować zestaw regresji?

Tabela wyżej działa na poziomie porcji zestawu. Która porcja jest „najprostsza i najstabilniejsza”, rozstrzygacie, oceniając pojedyncze przypadki testowe. Macierz decyzyjną z pięcioma kryteriami i progiem punktowym dla jednego przypadku testowego opisaliśmy w artykule testowanie manualne i automatyczne: jakie są różnice. Tu wystarczy zasada porządkowania zestawu przed liczeniem progu.

Często ten sam przypadek testowy dzieli się na dwie części. Ocena, czy komunikat błędu jest zrozumiały dla klienta, wymaga człowieka, ale sprawdzenie, czy komunikat w ogóle się pojawia, jest idealnym zadaniem dla automatu.

Jakie proporcje wybrać: piramida testów i kwadranty testowe

Kalkulator pokazuje próg w godzinach. Do ustalenia proporcji w całym projekcie sylabus ISTQB v4.0 podsuwa dwa modele, które dobrze się uzupełniają.

Piramida testów (sekcja 5.1.6) pokazuje, że testy na dole są małe, odizolowane i szybkie, więc potrzeba ich dużo, a testy end-to-end na górze są wolne i potrzeba ich niewiele. W praktyce oznacza to, że automatyzację zaczynacie od testów modułowych i API, a automatów przez interfejs użytkownika macie najmniej. Więcej o warstwach w artykule o piramidzie testów.

Źródło: sylabus ISTQB CTFL v4.0.1, sekcja 5.1.7, kwadranty testowe Briana Maricka, 2024.

Kwadranty dają Wam gotową odpowiedź na pytanie, gdzie testy manualne są nie do zastąpienia: w Q3. Testowanie eksploracyjne i ocena użyteczności to praca, w której człowiek znajduje błędy, o których nikt nie pomyślał, pisząc przypadki testowe. Do takich sesji przydaje się zestaw pytań z artykułu Web Testing Heuristic Checklist.

Jak łączyć oba podejścia w jednym sprincie?

W dojrzałym zespole oba podejścia pracują w jednym rytmie. Tak wygląda typowy sprint w projektach, które prowadzimy.

Źródło: praktyka Quality Island, 2026.

Zauważcie, że automatyczna regresja zwalnia ludzi właśnie po to, żeby mieli czas na eksplorację nowych obszarów. To jest korzyść, którą sylabus ISTQB wymienia wprost: więcej czasu dla testerów na projektowanie nowych, głębszych i skuteczniejszych testów. Plan wprowadzania tego rytmu krok po kroku opisuje artykuł na portalu Strefa QA o planie wdrożenia automatyzacji testów na 6 miesięcy.

Jakie błędy przy wyborze podejścia widzimy najczęściej?

• Automatyzacja wszystkiego naraz. Zespół pisze automaty do każdego przypadku z arkusza, łącznie z jednorazowymi i wymagającymi oceny człowieka, i po pół roku utrzymuje więcej kodu testów niż testuje.
• Automaty tylko przez interfejs. Test, który mógłby sprawdzić logikę przez API w 2 sekundy, przechodzi przez przeglądarkę w 40 sekund i psuje się przy każdej zmianie wyglądu.
• Brak właściciela niestabilnych testów. Test raz zielony, raz czerwony zostaje w zestawie miesiącami, aż zespół przestaje patrzeć na wynik.
• Rezygnacja z testów manualnych po wdrożeniu automatów. Znika eksploracja, a z nią błędy w obszarach, których nikt nie opisał w przypadkach testowych.
• Decyzja bez liczb. Nikt nie zmierzył godzin ręcznej regresji ani kosztu utrzymania automatów na cykl, więc dyskusja o opłacalności to zderzenie opinii.

Od czego zacząć w Waszym zespole?

Zacznijcie od jednego popołudnia z zestawem regresji. Zmierzcie godziny jednego pełnego cyklu ręcznej regresji, podzielcie zestaw na cztery porcje z sekcji o kolejności automatyzacji i dla każdej policzcie próg N. Pojedyncze przypadki do porcji przypiszecie macierzą z artykułu o różnicach między testowaniem manualnym i automatycznym. W większości zespołów, z którymi pracowaliśmy, wynik mieści się na jednej stronie i od razu pokazuje, które automaty pisać w najbliższym sprincie, a które testy na zawsze zostaną w rękach ludzi.

Jeśli chcecie, żeby tę analizę zrobił z Wami zespół, który robił to w bankowości, e-commerce i branży medycznej, prowadzimy doradztwo w automatyzacji testów i automatyzację testów od podstaw, a regresję manualną możemy przejąć w ramach usługi testy regresyjne. Zespół, który chce pisać automaty sam, przygotujemy na szkoleniu Automatyzacja testów z narzędziem Playwright, a wspólny język kwadrantów, piramidy i ryzyk automatyzacji daje szkolenie Certyfikowany Tester Poziom Podstawowy v4.0.

Powiązane na blogu Quality Island

• Testowanie manualne i automatyczne: jakie są różnice i kiedy wybrać każde podejście
• 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: co to jest, warstwy i proporcje
• Testy manualne: czyli co?

Pełna lista źródeł

• ISTQB, Certified Tester Foundation Level Syllabus v4.0.1, 2024. Sekcja 5.1.6 piramida testów, 5.1.7 kwadranty testowe, 6.2 korzyści i ryzyka automatyzacji testów.
• SJSI, Sylabus ISTQB Certyfikowany Tester Poziom Podstawowy w. 4.0, wersja polska 4.0.0.1, 2025. Polskie nazwy kwadrantów i ryzyk automatyzacji.
• John Micco, Google Testing Blog, Flaky Tests at Google and How We Mitigate Them, 2016. Około 1,5% uruchomień z wynikiem niestabilnym, niemal 16% testów z niestabilnością, około 84% przejść z zaliczonego na niezaliczony z udziałem testu niestabilnego.
• Ham Vocke, martinfowler.com, The Practical Test Pyramid, 2018. Praktyczne zastosowanie piramidy testów i przenoszenie testów na niższe poziomy.
• Dane własne Quality Island, 2026: case study Argos (regresja z 5 dni do 10 godzin, spadek błędów krytycznych o 46%, liczby potwierdzone przez klienta), ponad 450 000 napisanych testów automatycznych, kalkulator progu opłacalności zestawu.