Pytanie „testy manualne czy automatyczne” pada niemal na każdym projekcie, w którym pomagam, zwykle w wersji „automatyzujmy wszystko, bo tak nowocześniej”. W praktyce to nie jest wybór „albo–albo”, tylko decyzja o tym, gdzie ludzki tester wnosi więcej wartości, a gdzie tę robotę powinien wykonać kod. Poniżej pokazuję, kiedy opłaca się jedno, kiedy drugie i jak poukładać to sensownie.
Testy manualne czy automatyczne: czym się różnią
Test manualny to człowiek, który świadomie przechodzi przez aplikację: klika, obserwuje, kojarzy fakty i zauważa rzeczy, których nikt nie kazał mu sprawdzać. Test automatyczny to kod, który wykonuje z góry zdefiniowane kroki i porównuje wynik z oczekiwaniem, szybko, powtarzalnie i bez zmęczenia.
Kluczowa różnica: człowiek myśli, kod sprawdza. Automat świetnie odpowiada na pytanie „czy to nadal działa tak jak wczoraj”. Nie odpowie za to na pytanie „czy to w ogóle ma sens dla użytkownika”. Dlatego to nie konkurencja, tylko dwa różne narzędzia do różnych zadań.
Kiedy testy manualne się opłacają
Manual wygrywa wszędzie tam, gdzie liczy się ocena, kontekst i elastyczność, a nie liczba powtórzeń. U klientów widzę, że najwięcej realnych błędów wychodzi właśnie z testów manualnych na wczesnym etapie.
- Testy eksploracyjne: tester szuka błędów bez scenariusza, „czując” aplikację. To tu wychodzą najciekawsze bugi.
- UX i wygląd: czy formularz jest zrozumiały, czy komunikat błędu nie straszy, czy layout nie rozjeżdża się na telefonie. Automat sprawdzi, że przycisk istnieje; nie oceni, czy jest w dobrym miejscu.
- Nowe, świeżo pisane funkcje: dopóki wszystko zmienia się z dnia na dzień, automat trzeba by przepisywać codziennie. Szkoda czasu.
- Krótkie i zmienne projekty: MVP, kampania na kilka tygodni, prototyp. Zanim automat się zwróci, projekt się skończy.
Dobry test manualny też wymaga dyscypliny, pomaga w tym porządny przypadek testowy, żeby wiedza nie siedziała tylko w głowie jednej osoby.
Kiedy opłacają się testy automatyczne
Automatyzacja świeci wszędzie tam, gdzie coś jest powtarzalne, stabilne i nudne dla człowieka, a jednocześnie krytyczne, gdy się zepsuje.
- Regresja: sprawdzanie, że stare funkcje działają po każdej zmianie. Najlepszy kandydat do automatyzacji, bo robi się to w kółko.
- Stabilne, kluczowe ścieżki: logowanie, koszyk, płatność, generowanie faktury. Rzeczy, które muszą działać zawsze.
- CI/CD: testy uruchamiane automatycznie przy każdym wdrożeniu, zanim zmiana trafi na produkcję. To temat sam w sobie, opisuję go w tekście o wpięciu testów w pipeline.
- Duża liczba wariantów danych: sto kombinacji pól, które ręcznie zajęłyby dzień, a kod przechodzi w minuty.
Jeśli dochodzicie do etapu automatyzacji E2E, wcześniej czy później pojawi się wybór narzędzia, o tym piszę w porównaniu Selenium czy Playwright.
Koszt i ROI: kiedy automatyzacja naprawdę się zwraca
Tu najczęściej podejmowane są błędne decyzje. Automatyzacja nie jest darmowa: test trzeba napisać, a potem, co ważniejsze, utrzymywać. Każda zmiana w aplikacji może zepsuć test, który wtedy trzeba poprawić. To realny, powtarzający się koszt, nie jednorazowy wydatek.
Prosta zasada, którą stosuję: automatyzuj to, co jest jednocześnie powtarzalne, stabilne i ważne. Jeśli scenariusz wykonasz raz albo zmienia się co tydzień, taniej i sensowniej przejść go ręcznie.
| Sytuacja | Rekomendacja |
|---|---|
| Ścieżka wykonywana przy każdym wdrożeniu | Automatyzuj |
| Funkcja pisana od zera, ciągle się zmienia | Manual, na razie |
| Ocena wyglądu i wygody użytkownika | Manual |
| Setki kombinacji danych, ten sam schemat | Automatyzuj |
| Jednorazowa weryfikacja przed startem kampanii | Manual |
Uproszczony rachunek: koszt automatu to napisanie plus utrzymanie przez cały czas życia testu. Zwraca się dopiero wtedy, gdy suma ręcznych przebiegów, które zastąpi, przewyższy ten koszt. Dla scenariusza uruchamianego codziennie w CI/CD dzieje się to szybko. Dla scenariusza odpalanego raz na kwartał, często nigdy.
Jak wybrać: podejście hybrydowe i piramida testów
W praktyce zdrowy projekt nie wybiera jednego wariantu, łączy oba. Pomaga w tym klasyczna piramida testów, czyli pomysł na to, ile i jakich testów mieć.
- Podstawa, testy jednostkowe (automatyczne): najwięcej, najszybsze, najtańsze w utrzymaniu. Sprawdzają pojedyncze fragmenty logiki.
- Środek, testy integracyjne/API (automatyczne): mniej niż jednostkowych, sprawdzają współpracę modułów.
- Szczyt, testy E2E (automatyczne) i testy manualne: najmniej, najdroższe, ale najbliższe realnemu użytkownikowi. Tu mieszczą się też eksploracja i UX.
Antywzorzec, który regularnie widzę u klientów, to odwrócona piramida, czyli tzw. rożek lodowy: mnóstwo powolnych, kruchych testów E2E i prawie nic niżej. Efekt, testy trwają wieki, ciągle się psują i zespół przestaje im ufać. Lepiej przenieść ciężar w dół, a manualem obłożyć to, co wymaga oceny człowieka.
Od czego zacząć konkretnie? Najpierw ustalcie, co jest krytyczne dla biznesu i co się często zmienia, dobrym punktem startu jest plan testów, który to porządkuje.
Jak QA Sensei w tym pomaga
Jestem Paweł Szewczyk, od 20 lat pracuję w IT, od siedmiu jako inżynier jakości. W ramach QA Sensei pomagam firmom ustawić proporcje manual/automat tak, żeby wydawać pieniądze tam, gdzie realnie skracają czas i wyłapują błędy, a nie tam, gdzie modnie. Zaczynam od przeglądu tego, co macie i co boli, potem proponuję, co automatyzować w pierwszej kolejności, a co zostawić testerowi. Robię testy manualne i automatyczne, a mój sposób pracy jest prosty i bez korpo-waty. Pracuję zdalnie w całej Polsce, a w okolicach Wrocławia także u klienta. Jeśli zastanawiasz się, czy warto oddać testy na zewnątrz, pomocny będzie też tekst o outsourcingu QA.