W testowaniu jest jeden problem, o którym mówi się za rzadko. Większość zespołów nie robi rzeczy spektakularnie źle. Większość zespołów robi rzeczy prawie dobrze. I właśnie to „prawie” jest najgroźniejsze, bo antywzorce w QA rzadko wyglądają jak katastrofa. One wyglądają jak normalna praca. Testy są wykonywane, raporty wysyłane, bugi zgłaszane, wydania się dzieją. A mimo to produkcja płonie, regresja trwa wieki, a zespół czuje, że ciągle goni.
- Antywzorzec 1: liczymy aktywność zamiast skuteczności
- Antywzorzec 2: regresja jako muzeum dawnych bugów
- Antywzorzec 3: automatyzujemy wszystko przez UI
- Antywzorzec 4: QA jako policjant na końcu procesu
- Antywzorzec 5: brak strategii danych testowych
- Antywzorzec 6: raport, którego nikt nie czyta
- Antywzorzec 7: testujemy tak samo wszystko
- Dlaczego antywzorce wracają, mimo że wszyscy je znają
- Czego nie robić: dwie pułapki naprawy
Antywzorce nie krzyczą. Antywzorce po cichu zjadają jakość, czas i zaufanie. Poniżej siedem najczęstszych, które widzimy w zespołach od startupów po duże organizacje, wraz z konkretnymi naprawami. Bez religii narzędzi. Z naciskiem na to, co naprawdę zmienia wynik.
Antywzorzec 1: liczymy aktywność zamiast skuteczności
To najczęstszy początek kłopotów, bo wygląda jak dojrzałość. Ktoś wprowadza metryki, ktoś liczy testy, ktoś liczy defekty i nagle QA ma KPI. Problem w tym, że metryki aktywności nagradzają produkcję artefaktów, nie ochronę ryzyka. Jeśli mierzycie liczbę testów, zespół będzie pisał testy, także takie, które niczego nie bronią. Jeśli mierzycie liczbę bugów, zespół będzie zgłaszał drobnicę, bo każdy bug wygląda tak samo w liczniku. Jeśli mierzycie pokrycie, łatwo wpaść w pokrywanie łatwych obszarów zamiast krytycznych.
Jak to rozpoznacie. Macie świetne liczby w raportach, a incydenty nadal się zdarzają. QA jest zajęte, ale nie widać różnicy w stabilności. Raport pokazuje pracę, ale nie pokazuje trendu ryzyka.
Jak to naprawić. Zamiast metryk aktywności wprowadzacie metryki skutku: liczba defektów, które dotarły na produkcję, czas przywrócenia sprawności, czas feedbacku z pipeline, odsetek niestabilnych testów, pokrycie krytycznych ścieżek. Do tego jedna konserwatywnie policzona metryka kosztu incydentów. Wtedy rozmowa przestaje być o tym, ile zrobiliśmy, a zaczyna być o tym, ile problemów nie dotarło do klienta.
Antywzorzec 2: regresja jako muzeum dawnych bugów
Ten antywzorzec rośnie latami i jest karmiony najlepszymi intencjami. Bug wyszedł na produkcji, więc dopisujemy test do regresji, żeby to się nie powtórzyło. Tylko że nikt nie usuwa starych testów, nikt nie łączy duplikatów, nikt nie przenosi scenariuszy na niższy poziom. Po roku regresja jest archiwum traum. Zespół klika rzeczy, które dawno nie są ryzykiem, a jednocześnie wciąż nie ma pewności przed wydaniem, bo regresja jest tak duża, że staje się niewiarygodna i niedomykalna. Taka regresja przypomina strych po dziadkach: wszyscy wiedzą, że trzeba posprzątać, ale każde pudełko wraca na półkę, bo „może się jeszcze przydać”.
Jak to rozpoznacie. Regresja trwa coraz dłużej, ale nie rośnie zaufanie do wdrożeń. Coraz częściej słyszycie „nie zdążymy” albo „puścimy bez pełnej regresji”. Zespół nie wie, po co część testów istnieje.
Jak to naprawić. Wprowadzacie cykl życia testu. Każdy test w regresji ma właściciela i uzasadnienie ryzyka. Raz w miesiącu przegląd dwudziestu najwolniejszych i najbardziej niestabilnych. Usuwacie duplikaty, przenosicie scenariusze niżej, ograniczacie testy end to end do krytycznych przebiegów. I rozdzielacie regresję na szybki smoke dla krytycznych ścieżek i głębszą regresję cykliczną. Regresja ma dawać decyzję, a nie poczucie, że się napracowaliśmy. Wiemy, że to działa, bo w naszym projekcie dla Argos skróciliśmy tak regresję przed releasem z 5 dni do 10 godzin: nie przez dopisywanie kolejnych testów, tylko przez ich przegląd, wyrzucenie martwych i przeniesienie scenariuszy na niższe poziomy.
Antywzorzec 3: automatyzujemy wszystko przez UI
Jeden z najdroższych błędów, bo zaczyna się logicznie. Użytkownik klika UI, więc testujmy UI. Problem w tym, że UI jest najdroższym miejscem do testowania: wolne, kruche i zależne od wszystkiego. Testy UI psują się od zmian w układzie, od animacji, od selektorów, od danych, od środowisk, od czasu. Gdy większość automatyzacji to UI, pipeline rośnie, niestabilność rośnie, a zespół przestaje ufać wynikowi. Nie jest to zresztą kwestia wprawy: Jeff Listfield pokazał na blogu testowym Google w 2017 roku na danych z ich własnych systemów, że im większy i bardziej zintegrowany test, tym większa jego podatność na niestabilność.
Jak to rozpoznacie. Większość czerwonych buildów to błędy testów, nie błędy produktu. Debugowanie jednego faila zajmuje długo. Pipeline trwa tak długo, że część testów odpala się rzadko.
Jak to naprawić. Przenosicie większość pokrycia na API, kontrakty, integracje i testy komponentów. UI zostaje jako cienka warstwa smoke na krytycznych ścieżkach. Jeśli musicie utrzymać testy end to end, tniecie je na krótsze scenariusze, izolujecie dane i dbacie o stabilne selektory. Szerzej o tym, co się naprawdę opłaca automatyzować, a co nie, piszemy osobno, a jeśli chcecie przebudować piramidę testów z kimś, kto robił to wielokrotnie, zajrzyjcie do naszej usługi automatyzacji testów.
Niestabilne testy to nie dowód na słaby zespół. Według prezentacji Johna Micco z Google Research (2018) prawie 16 procent z 4,2 miliona testów Google wykazywało jakiś poziom niestabilności, a na samo powtarzanie flaky testów szło od 2 do 16 procent zasobów obliczeniowych ich CI. Ten sam materiał Google Research podaje, że mimo ciągłego sprzątania 1,5 procent przebiegów testów i tak kończy się wynikiem flaky. Skoro nawet Google nie zszedł do zera, celem nie jest zero, tylko architektura testów, która niestabilność izoluje, zamiast ją ignorować.
Antywzorzec 4: QA jako policjant na końcu procesu
Ten antywzorzec zabija morale i tworzy konflikt, choć nikt go nie planuje. QA jest na końcu, więc widzi wszystkie problemy najpóźniej. A gdy widzi je najpóźniej, musi blokować albo ryzykować. Zespół zaczyna postrzegać QA jako hamulec, QA zaczyna czuć się winne, a produkt płaci za to poprawkami na ostatnią chwilę.
Jak to rozpoznacie. Sprint kończy się zdaniem „nie zdążyliśmy przetestować”. QA dostaje build na ostatnie dni. Poprawki wchodzą w panice tuż przed wydaniem.
Jak to naprawić. Przesunięcie w lewo, ale przez pracę na backlogu, nie przez spotkania. QA wchodzi w refinement, dopina kryteria akceptacji, ryzyka i scenariusze, zanim kod powstanie. Definicja ukończenia zawiera testy jednostkowe i integracyjne po stronie programistów, a QA koncentruje się na ryzyku i krytycznych przebiegach. QA nie jest bramkarzem. QA jest radarem.
Antywzorzec 5: brak strategii danych testowych
Antywzorzec, który potrafi zniszczyć najlepszą automatyzację. Macie testy, ale nie macie danych. Konta współdzielone, brak resetu, brak izolacji, środowiska żyją własnym życiem. Wtedy testy są loterią, a loteria w CI kończy się ignorowaniem wyników.
Jak to rozpoznacie. Testy padają, bo konto jest zablokowane, bo w koszyku zostały stare produkty, bo limit został wyczerpany, bo środowisko jest w innym stanie niż oczekiwany. QA spędza czas na przygotowywaniu danych, a nie na testowaniu.
Jak to naprawić. Traktujecie dane testowe jak produkt. Zestawy danych do krytycznych scenariuszy, mechanizm resetu, izolacja kont, jasno opisane zależności, możliwość tworzenia danych przez API. W wielu zespołach samo uporządkowanie danych obniża niestabilność testów bardziej niż jakakolwiek zmiana w kodzie testów. Z naszego doświadczenia przy ponad 450 000 napisanych testów automatycznych w Quality Island to właśnie dane i środowiska, nie kod testów, są najczęstszym pojedynczym źródłem niestabilności.
Antywzorzec 6: raport, którego nikt nie czyta
Raport z testów ma dwadzieścia stron, wykresy w trzech kolorach i tabelę z liczbą przypadków. Zarząd nie wie, czy można wydać. Product nie wie, co jest ryzykiem. Programiści nie wiedzą, co naprawić najpierw. Raport spełnia formalność i nie zmienia żadnej decyzji.
Jak to rozpoznacie. Na spotkaniu o wydaniu ktoś pyta „to w końcu możemy, czy nie?”, mimo że raport wyszedł dzień wcześniej. Nikt nie potrafi wskazać, które pozycje raportu wpłynęły na jakąkolwiek decyzję w ostatnim kwartale.
Jak to naprawić. Jedna strona, trzy sekcje: stan krytycznych ścieżek (przeszło albo nie), otwarte ryzyka z wpływem na biznes, rekomendacja wydania z warunkami. Liczby przypadków testowych trafiają do załącznika. Raport ma odpowiadać na pytanie „czy możemy wydać i co ryzykujemy”, nie dokumentować pracowitość. O tym, dlaczego dashboard jakości kłamie, pisaliśmy wcześniej.
Antywzorzec 7: testujemy tak samo wszystko
Każda zmiana dostaje ten sam zestaw testów, niezależnie od tego, czy dotyczy koloru przycisku, czy integracji płatności. To wygląda na rzetelność, a jest brakiem analizy ryzyka. Zespół spędza tyle samo czasu na zmianie, która nie może nic zepsuć, co na zmianie, która może zatrzymać sprzedaż.
Jak to rozpoznacie. Plan testów jest szablonem, nie decyzją. Nikt nie pyta „co ta zmiana może zepsuć”, tylko „które testy odpalamy”. Najgroźniejsze błędy przechodzą, bo czas poszedł na sprawdzanie oczywistości.
Jak to naprawić. Testowanie oparte na ryzyku: przy każdej zmianie trzy pytania. Których krytycznych ścieżek dotyka. Jaki jest najgorszy scenariusz, jeśli się nie uda. Co musi zostać sprawdzone, żeby ten scenariusz wykluczyć. Reszta testów dostaje tyle uwagi, ile zasługuje, czyli czasem żadnej. Jeśli zespół nigdy nie pracował z analizą ryzyka, najszybciej nadrobicie to warsztatowo: terminy szkoleń z testowania i analizy testowej znajdziecie w kalendarzu szkoleń Quality Island.
Źródło: metodyka i praktyka własna Quality Island z audytów procesów QA.
Dlaczego antywzorce wracają, mimo że wszyscy je znają
Bo każdy z nich jest lokalnie racjonalny. Liczenie testów jest łatwe. Dopisanie testu po incydencie jest odpowiedzialne. Automatyzacja przez UI jest intuicyjna. QA na końcu procesu jest tradycją. Brak danych testowych to skutek pośpiechu, nie złej woli. Długi raport wygląda na rzetelny. Ten sam plan dla każdej zmiany daje poczucie bezpieczeństwa. Antywzorce nie biorą się z braku wiedzy. Biorą się z tego, że nikt nie ma czasu zatrzymać się i sprawdzić, czy to, co robimy, nadal chroni to, co ma chronić.
Jest jeszcze jeden powód, dla którego antywzorce trwają: nikt nie liczy ich kosztu. Regresja, która trwa trzy dni zamiast trzech godzin, kosztuje tyle samo co etat, ale nie ma swojej rubryki w budżecie. Czerwone buildy z winy testów kosztują godziny programistów, ale nikt ich nie sumuje. W skali makro policzył to CISQ: według raportu The Cost of Poor Software Quality in the US z 2022 roku zła jakość oprogramowania kosztowała amerykańską gospodarkę co najmniej 2,41 biliona dolarów, a około 1,52 biliona z tej kwoty to narosły dług techniczny, czyli dokładnie te nawyki, których nikt nie posprzątał, zanim stały się kosztem. Dopiero gdy policzycie te godziny na danych z jednego kwartału, antywzorzec przestaje być nawykiem, a staje się pozycją kosztową z właścicielem. I wtedy naprawa dostaje priorytet, bo ma cenę.
Dlatego najskuteczniejsza naprawa nie jest jednorazowa. To rytuał przeglądu, który raz na kwartał zadaje siedem pytań z tabeli wyżej i sprawdza odpowiedzi na danych, nie na wrażeniach.
„Antywzorzec nie jest błędem zespołu. Jest nawykiem, który kiedyś miał sens i nikt nie sprawdził, czy nadal go ma.”
Czego nie robić: dwie pułapki naprawy
Pierwsza pułapka to naprawianie wszystkiego naraz. Siedem antywzorców, siedem inicjatyw, zero efektu, bo zespół nadal musi dowozić produkt. Dwa antywzorce na kwartał to realne tempo. Druga pułapka to naprawa narzędziem. Nowy framework nie naprawi braku strategii danych, a nowy dashboard nie naprawi raportu, który nie odpowiada na pytanie o wydanie. Narzędzie wchodzi na końcu, kiedy wiadomo, jaką decyzję ma wspierać.
Jeśli chcecie zobaczyć, które z siedmiu antywzorców żyją u Was, w Quality Island robimy to w formie audytu procesu QA: przegląd na danych, nazwane antywzorce, kolejność napraw według kosztu. Najczęściej okazuje się, że dwa z nich odpowiadają za większość bólu, a reszta znika przy okazji.
- Antywzorce w QA wyglądają jak normalna praca: testy się wykonują, raporty wychodzą, a produkcja i tak płonie.
- Siedem najczęstszych: metryki aktywności, regresja jako muzeum, wszystko przez UI, QA na końcu, brak strategii danych, raport bez decyzji, ten sam plan dla każdej zmiany.
- Każdy ma prosty objaw widoczny z zewnątrz i pierwszy krok naprawy, który nie wymaga nowego narzędzia.
- Antywzorce wracają, bo każdy jest lokalnie racjonalny. Lekarstwem jest kwartalny przegląd na danych, nie jednorazowa akcja.
- Naprawiajcie dwa antywzorce na kwartał, zaczynając od tych, które kosztują najwięcej.
Jeśli chcecie sprawdzić na danych, które antywzorce żyją w Waszym procesie testowania, zróbmy przegląd i ułóżmy naprawy według kosztu.
Sprawdźcie audyt QAPowiązane na Strefie QA
- Dlaczego Twój dashboard jakości kłamie, i jak to naprawić
- Testy regresyjne w dużych projektach: jak przestać bać się każdego wdrożenia
- Automatyzacja testów: co się naprawdę opłaca automatyzować, a co nie
Źródła:
- DORA (Google Cloud), Accelerate State of DevOps Report, 2024, stąd zestaw metryk skutku (odsetek nieudanych zmian, czas przywrócenia sprawności) jako punkt odniesienia dla metryk QA
- John Micco, Google Research, Advances in Continuous Integration Testing at Google, 2018, stąd liczby o niestabilności testów: prawie 16 procent z 4,2 miliona testów, 2 do 16 procent zasobów obliczeniowych na powtórki, 1,5 procent przebiegów z wynikiem flaky
- CISQ, The Cost of Poor Software Quality in the US, 2022, stąd koszt złej jakości oprogramowania w gospodarce USA: co najmniej 2,41 biliona dolarów, w tym około 1,52 biliona długu technicznego
- Jeff Listfield, Google Testing Blog, Where do our flaky tests come from?, 2017, stąd zależność między rozmiarem testu a jego podatnością na niestabilność
- Quality Island, dane własne z audytów procesów QA i projektów klienckich (m.in. Argos: skrócenie regresji przed releasem z 5 dni do 10 godzin), stan na 2026
