W wielu projektach QA pojawia się za późno. Czasem dopiero wtedy, gdy „wszystko jest gotowe i trzeba tylko przetestować”. Problem polega na tym, że na tym etapie wiele decyzji zostało już podjętych, wiele błędów zostało już wbudowanych w produkt, a koszt ich poprawy jest dużo większy. Pomijanie QA może wyglądać jak oszczędność, ale bardzo często jest tylko przesunięciem kosztu na później - z większym mnożnikiem i pod większą presją.

To pierwszy artykuł z serii „Dojrzałe QA w praktyce”. Reszta serii - automatyzacja, rozwój procesu, doświadczenie, rozwój indywidualny i refleksja o ciągłym rozwoju - schodzi z tego punktu wyjścia: jakość zaczyna się przed implementacją, nie po niej.

QA to nie tylko klikanie gotowej aplikacji

Najpopularniejszy mit o QA mówi, że tester to osoba, która „na końcu sprawdza, czy działa”. Ta definicja jest wygodna dla planu projektu - łatwo wstawić blok „testy” pomiędzy „wytwarzaniem” a „wydaniem”. Niewygodna dla rzeczywistości - bo zostawia zespół z bardzo wąską ścieżką naprawy błędów.

Dobre QA uczestniczy w projekcie dużo wcześniej. Pełna lista obszarów wpływu wygląda tak:

  • analiza wymagań i scenariuszy biznesowych,
  • identyfikacja ryzyk i obszarów krytycznych,
  • zadawanie trudnych pytań na spotkaniach uszczegóławiania wymagań,
  • doprecyzowanie kryteriów akceptacji,
  • planowanie strategii testów,
  • testowanie eksploracyjne podczas wytwarzania,
  • automatyzacja tam, gdzie ma sens,
  • wsparcie wydania i ocena gotowości,
  • analiza defektów po wdrożeniu i informacja zwrotna do następnego cyklu.

Niemal wszystkie te obszary są tańsze, gdy QA wchodzi wcześnie. Niemal wszystkie są droższe, gdy QA wchodzi na końcu.

Co naprawdę oznacza pominięcie QA?

To nie jest tylko brak osoby z rolą „tester” w zespole. Pominięcie QA oznacza często brak:

  • niezależnej perspektywy - nikt nie patrzy na produkt z punktu widzenia użytkownika, ryzyka i procesu, tylko implementacji,
  • krytycznej analizy wymagań - wymagania trafiają do kodu w stanie, w którym były napisane, nawet jeśli mają luki,
  • kontroli regresji - nie ma systematycznego sprawdzania, czy stare funkcje nadal działają,
  • spójnego podejścia do ryzyka - różne osoby oceniają ryzyko inaczej i niespójnie,
  • wiedzy o jakości produktu - przed wydaniem nikt nie potrafi powiedzieć, w jakim stanie naprawdę jest aplikacja,
  • jasnej informacji, czy można bezpiecznie wdrażać - decyzja o wydaniu jest opinią, nie sumą sprawdzonych faktów.

Każdy z tych punktów oddzielnie wydaje się akceptowalny. Razem tworzą lukę, którą ktoś musi pokryć - najczęściej w awaryjnym trybie po produkcji.

Koszt błędu rośnie z czasem

To prawdopodobnie najmocniej zbadana zasada w inżynierii oprogramowania, a jednocześnie najczęściej ignorowana w planowaniu projektów.

  • Błąd w wymaganiach wykryty podczas analizy można poprawić rozmową.
  • Błąd wykryty po implementacji wymaga zmiany kodu, czasem testów i dokumentacji.
  • Błąd wykryty po wdrożeniu może oznaczać reklamację, utratę klienta, poprawkę awaryjną, stres zespołu, dłuższe spotkania i kolejne tygodnie poprawek powiązanych.

Konkretny przykład.

Wymaganie: „Użytkownik może zmienić adres dostawy”.

Pytania QA, które warto zadać na analizie:

  • Czy może zmienić adres po opłaceniu zamówienia?
  • Czy może zmienić kraj?
  • Co z kosztami dostawy, jeśli zmienia się region?
  • Co z fakturą, jeśli zmienia się dane odbiorcy?
  • Co jeśli paczka jest już przekazana kurierowi?
  • Co jeśli klient zmienia adres, ale system magazynowy nie obsłuży aktualizacji?

Bez tych pytań zespół zbuduje funkcję, która działa technicznie, ale nie obsługuje realnego procesu biznesowego. Po wdrożeniu okaże się, że pierwsi klienci, którzy próbowali zmienić adres po wysłaniu paczki, dostali pomieszane faktury - i mamy tygodniową poprawkę awaryjną oraz rozmowę z biznesem.

Każde z tych pytań mogło zająć 5 minut na spotkaniu uszczegóławiania wymagań. Każde nieotrzymane pytanie kosztuje godziny lub dni po fakcie.

QA pomaga wykrywać luki w wymaganiach

To rola, którą trudno opisać w punktach historyjki. A jednak to często najbardziej wartościowa praca QA.

QA powinno pytać, zanim coś zostanie zbudowane:

  • Co się stanie, gdy użytkownik poda błędne dane?
  • Co się stanie, gdy integracja zewnętrzna nie odpowie?
  • Jak system zachowa się przy braku uprawnień?
  • Co z duplikatami danych?
  • Co z danymi historycznymi, które powstały przed tą zmianą?
  • Co z wydajnością przy 10× większym ruchu?
  • Co z obsługą wyjątków, które jeszcze nie istnieją?
  • Co z migracją z poprzedniej wersji?

Każde z tych pytań zazwyczaj odkrywa coś, czego nikt jeszcze nie zauważył. Czasem to brakujący scenariusz brzegowy. Czasem nieobsłużony stan błędu. Czasem fundamentalna luka w projekcie, która jeszcze nie była widoczna.

W zespołach, gdzie QA pyta na analizie, liczba defektów wykrytych po wdrożeniu spada wyraźnie. Nie dlatego, że więcej osób testuje. Dlatego, że mniej błędów w ogóle powstaje.

Brak QA prowadzi do fałszywego poczucia bezpieczeństwa

Programista może przetestować swój kod. Zwykle patrzy na niego z perspektywy implementacji: „czy to robi to, co napisałem”. QA patrzy z perspektywy ryzyka, użytkownika i procesu: „czy to robi to, czego organizacja potrzebuje, w warunkach, w jakich będzie używane”.

To nie jest brak zaufania do programistów. To inna perspektywa.

Programista często sprawdza, czy rozwiązanie działa zgodnie z tym, jak zostało zbudowane. QA sprawdza, czy rozwiązanie ma sens w kontekście tego, jak będzie używane.

W projektach bez QA bardzo łatwo dotrzeć do wydania z poczuciem, że „wszystko przetestowane”. Często okazuje się, że przetestowane były ścieżka pozytywna i kilka założeń programisty. Co działo się na obrzeżach - nikt nie wie.

QA chroni nie tylko produkt, ale też zespół

Dobre QA jest ochroną przed konkretnymi, łatwo policzalnymi kosztami:

  • mniej nagłych poprawek awaryjnych po wdrożeniu,
  • mniej chaosu w ostatnim tygodniu sprintu,
  • spokojniejsze planowanie wydania, bo zespół wie, co jest gotowe,
  • mniej nieporozumień między biznesem a technologią, bo wymagania są wcześniej dopytane,
  • mniej stresu po godzinach, bo problemy są wcześnie identyfikowane.

To są też koszty miękkie - wypalenie, rotacja, frustracja zespołu. Trudniej je policzyć, ale ich brak widać natychmiast.

„Nie mamy czasu na testy” - paradoks, który warto rozbroić

Argument „nie mamy czasu na QA” pojawia się w prawie każdym napiętym projekcie. Warto rozbroić go konkretnym rachunkiem.

Zespół nie ma czasu na QA, ale potem ma czas na:

  • analizę błędów produkcyjnych z logów,
  • poprawki na szybko z dyżurem do późna,
  • dodatkowe spotkania kryzysowe,
  • tłumaczenie się klientowi,
  • cofanie wdrożeń i przywracanie poprzedniej wersji,
  • ręczne poprawianie danych po poprawce awaryjnej,
  • planowanie nieprzewidzianego sprintu „naprawa”.

Suma tych godzin niemal zawsze jest większa niż czas, który zespół zaoszczędził, pomijając QA. Różnica: czas na QA jest przewidywalny i planowany. Czas na poprawki awaryjne jest chaotyczny i obciąża ludzi pod presją.

QA nie blokuje projektu. QA pokazuje ryzyko

Słaby model QA wygląda tak: tester mówi „nie ma zgody na wydanie”. Reszta zespołu czuje się zablokowana.

Dobry model QA wygląda inaczej: QA dostarcza informacji.

  • Co działa.
  • Co nie działa.
  • Co jest ryzykowne.
  • Co można świadomie zaakceptować jako znany problem.
  • Co trzeba poprawić przed wdrożeniem.
  • Jakie są konsekwencje każdej z opcji.

Decyzja o wydaniu pozostaje po stronie zespołu i biznesu. Ale podejmowana jest na podstawie faktów, nie nadziei.

Kiedy QA powinno wejść do projektu?

Najlepsza odpowiedź: tak wcześnie, jak się da. Praktycznie oznacza to udział na każdym etapie cyklu, z innym ciężarem.

Rozpoznanie / analiza

QA pomaga zadawać pytania i identyfikować niejasności. Nie pisze jeszcze testów. Pisze pytania.

Projektowanie rozwiązania

QA pomaga myśleć o przypadkach brzegowych, danych, integracjach i ryzykach. Tu często rodzą się pierwsze szkice strategii testowej.

Implementacja

QA testuje przyrostowo. Wspiera programistów, przygotowuje dane testowe, pisze automaty na to, co stabilne. Nie czeka na „gotową wersję”.

Wydanie

QA ocenia gotowość. Wystawia listę znanych ograniczeń, ryzyk i obszarów, których nie objęły testy. Daje informację, nie blokuje.

Produkcja

QA analizuje błędy, informacje zwrotne od użytkowników, monitoring. Wyciąga wnioski dla następnego cyklu - co powinno wejść do automatów, gdzie wymagania potrzebują doprecyzowania, co dodać do listy kontrolnej wydania.

Mit „testowanie spowalnia projekt”

Słyszę to często. Najczęściej w projektach, w których nie da się oszacować, jak długo trwa naprawa błędów produkcyjnych, ile godzin pochłaniają poprawki awaryjne i ile rotacji w zespole wynika z frustracji „ciągłych pożarów”.

W projektach, gdzie QA wchodzi wcześnie, faktyczne tempo dostarczania jest bardziej przewidywalne. Nie zawsze szybsze w pierwszym sprincie. Ale stabilne w 5., 10. i 20. sprincie. To samo zespół, ten sam zakres - różny poziom „tarcia” w dostarczaniu.

To największa wartość dojrzałego QA: nie szybkość chwilowa, tylko trwała przewidywalność.

Co jeśli zespół jest mały i nie ma dedykowanego QA?

To realna sytuacja w wielu zespołach. Brak osoby z rolą „tester” nie zwalnia z odpowiedzialności za jakość.

Co działa w małych zespołach bez dedykowanego QA:

  • QA jako kompetencja, nie etat - programista pełniący rolę QA na rotacji, świadomy strategii testów i myślenia o ryzyku,
  • QA-coaching z zewnątrz - okresowe wsparcie eksperta, który audytuje proces, nie pisze testów na co dzień,
  • wbudowane praktyki - przegląd kodu z perspektywą QA, spotkania uszczegóławiania wymagań z listą kontrolną pytań, obowiązkowa definicja ukończenia z kryteriami jakości.

To nie zastępuje dedykowanego QA w większym zespole, ale eliminuje najgorszy stan: brak myślenia o jakości w ogóle.

Podsumowanie

Pominięcie QA rzadko oznacza realną oszczędność. Najczęściej oznacza przesunięcie ryzyka na później, gdzie koszt naprawy jest większy, a presja znacznie wyższa. To nie tylko więcej godzin pracy - to też więcej stresu, mniej zaufania użytkowników i mniej kontroli nad tym, w jakim stanie jest produkt.

Jeśli QA w Twoim projekcie pojawia się dopiero na końcu, warto potraktować to jako sygnał ostrzegawczy. Jakość nie powstaje w ostatnim tygodniu przed wydaniem. Powstaje od pierwszych rozmów o wymaganiach.

Co dalej w serii

To pierwszy artykuł serii „Dojrzałe QA w praktyce”. Kolejny tekst: kiedy warto automatyzować testy, a kiedy automatyzacja jest stratą czasu - naturalne przedłużenie tej dyskusji o konkretne decyzje narzędziowe.