Strategia testowania w organizacji: czego uczy nas case PKO BP

Strategia testowania rzadko wygląda jak dokument. Częściej wygląda jak seria decyzji podejmowanych w pośpiechu tuż przed wydaniem: co zdążymy przetestować, co odpuszczamy, kto bierze odpowiedzialność, jeśli coś pęknie na produkcji. Firma bez spisanej strategii testów nie oszczędza na jakości, tylko płaci za nią osobno przy każdym wydaniu, zamiast raz ułożyć zasady i trzymać się ich. Ten artykuł pokazuje, czym realnie jest strategia testowania, z czego się składa i dlaczego zarząd kupuje ją łatwiej, gdy mówi się o niej językiem ryzyka i kosztu, nie żargonem testerskim. Punktem odniesienia jest case PKO BP, jeden z naszych najmocniejszych dowodów w sektorze regulowanym.

Czym jest strategia testowania, a czym na pewno nie jest

Strategia testowania to nie jest dokument, który powstaje raz i ląduje w folderze na dysku współdzielonym. To zestaw powtarzalnych decyzji: co testujemy przed każdym wydaniem, kto o tym decyduje, jakie ryzyko akceptujemy, a jakie zatrzymuje release. Bez tych decyzji spisanych z góry, zespół podejmuje je od nowa za każdym razem, pod presją terminu, czyli w najgorszych możliwych warunkach do myślenia o ryzyku. Sam dokument w folderze współdzielonym też nie ratuje sytuacji: działa mniej więcej jak karnet na siłownię w portfelu, samo posiadanie jeszcze nikomu nie poprawiło formy.

W praktyce widzimy trzy fałszywe wersje strategii, które nie działają. Pierwsza: strategia jako lista narzędzi, czyli „testujemy w Playwright, zgłoszenia w Jirze”. To opis warsztatu, nie strategia. Druga: strategia jako slogan zarządu, w rodzaju „jakość jest u nas priorytetem”, bez jednego zdania o tym, co to znaczy w praktyce przy konkretnym wydaniu. Trzecia, najbardziej kosztowna: strategia, która istnieje wyłącznie w głowie jednej osoby. Gdy ta osoba jest na urlopie, zespół testuje po omacku, a firma odkrywa, że miała proces tylko dopóki ktoś konkretny pamiętał, jak on wygląda.

Dobra strategia testowania odpowiada na pięć pytań, i to niezależnie od wielkości firmy: co testujemy przed każdym wydaniem, kto podejmuje decyzję o tym, że wydanie jest gotowe, jakie ryzyko akceptujemy świadomie, a jakie zatrzymuje release, jak długo trwa regresja i czy ten czas jest do zaakceptowania przy obecnym tempie wydań, oraz kto przejmuje odpowiedzialność, jeśli mimo wszystko coś wyjdzie na produkcję. Jeżeli w waszej organizacji na któreś z tych pytań odpowiada „to zależy, kogo zapytasz”, strategii testowania jeszcze nie macie, niezależnie od tego, ile dokumentów o jakości leży w firmowym Confluence.

Dlaczego zarząd nie kupuje żargonu testerskiego

Zespoły QA i testerzy mówią o pokryciu testami, piramidzie testów, klasach ryzyka. Zarząd i finanse słyszą inny język: koszt awarii, ryzyko operacyjne, prędkość wydawania nowych funkcji. Jeśli argument za strategią testowania brzmi technicznie, przegrywa z argumentem za nową funkcją, który zawsze brzmi biznesowo. Dlatego najskuteczniejsze rozmowy o strategii testowania, które prowadzimy z klientami, zaczynają się nie od narzędzi, tylko od jednego pytania: ile kosztuje was dziś błąd, który wychodzi na produkcję zamiast zostać złapanym wcześniej.

Mamy na to policzalną odpowiedź z jednego z naszych wdrożeń. W projekcie dla Argos, klienta z branży e-commerce, uporządkowanie procesów QA i automatyzacja testów skróciły regresję przed wydaniem z 5 dni do 10 godzin, a liczba awarii w okresach szczytowych spadła o 72 procent. To jest dokładnie ten język, który przekonuje zarząd: nie „lepsza jakość kodu”, tylko „krótszy czas do wydania i mniej nocnych telefonów w sezonie”. Pełny rozkład tego wdrożenia, z metodą i wszystkimi liczbami, pokazujemy w osobnym artykule o skróceniu testów regresyjnych z 5 dni do 10 godzin na przykładzie case Argos.

Ile kosztuje brak strategii: liczby z rynku

Nie musicie brać tego zdania na wiarę. Według World Quality Report 2024-25, badania przeprowadzonego przez OpenText, Capgemini i Sogeti wśród ponad 1750 menedżerów wysokiego szczebla z 33 krajów, 57 procent organizacji przyznaje, że nie ma kompleksowej strategii automatyzacji testów. Ten sam raport podaje, że 64 procent firm zmaga się z zależnością od systemów legacy, czyli od kodu, którego wszyscy się boją i którego nikt nie chce testować. Jeśli w Waszej firmie zasady testowania żyją głównie w głowach kilku osób, Wasz zespół jest więc w licznym towarzystwie. Tyle że to towarzystwo płaci słony rachunek: raport CISQ z 2022 roku, przygotowany przez Herba Krasnera, wycenił koszt złej jakości oprogramowania w samych Stanach Zjednoczonych na 2,41 biliona dolarów rocznie. Z tej kwoty około 1,52 biliona dolarów to według tego samego raportu skumulowany dług techniczny, czyli dokładnie to, co przyrasta po cichu, gdy decyzje o testowaniu zapadają ad hoc przy każdym wydaniu.

Co z tych liczb wynika dla Was? Spisana strategia testowania nie jest luksusem dojrzałych organizacji, tylko polisą o składce niewspółmiernej do kwot po drugiej stronie rachunku. Wasza firma nie musi mierzyć się z bilionami z raportu CISQ. Wystarczy jedna wpadka na produkcji w Waszym najgorętszym tygodniu sprzedaży, żeby brak zasad przestał być teorią, a zaczął być pozycją w wynikach kwartału, o którą Wasz zarząd zapyta pierwszy.

Case PKO BP: strategia jakości dla całej organizacji

Najmocniejszym dowodem, jaki mamy na to, że strategię testowania da się zaprojektować i wdrożyć w skali całej organizacji, jest nasza współpraca z PKO BP. Zakres nie ograniczał się do jednego zespołu ani jednego produktu. Obejmował opracowanie, przygotowanie i wdrożenie strategii jakości oprogramowania dla całej organizacji, audyt istniejących procesów QA oraz szkolenia i warsztaty dla zespołów QA.

To jest dokładnie ta skala klienta, przy której samodzielne poukładanie strategii testowania od zera bywa trudniejsze niż w mniejszej firmie, nie łatwiejsze. Bank ma wiele zespołów, wiele systemów o różnym poziomie krytyczności, ślad dokumentacyjny wymagany przez regulatora i wielu interesariuszy, którzy muszą się zgodzić co do tego, co znaczy „gotowe do wydania”. Strategia testowania w takiej organizacji nie może być zapisana w głowie jednej osoby, bo żadna jedna osoba nie ma wglądu we wszystkie zespoły naraz. Musi być spisana, przekazywalna i egzekwowalna niezależnie od tego, kto akurat prowadzi dany projekt.

Dla firm z sektora regulowanego dochodzi jeszcze jeden wymiar: audyt QA sprawdza w banku więcej niż w typowym software housie, bo obejmuje ślad dokumentacyjny, niezależność testów i zarządzanie ryzykiem operacyjnym. Rozkładamy to dokładnie w osobnym artykule o audycie QA w sektorze regulowanym na przykładzie case PKO BP, gdzie pokazujemy, czym różni się taki audyt od audytu w firmie bez presji regulacyjnej.

Jak przełożyć jakość testów na język, który rozumie zarząd

Konkretna technika, która u nas działa: zamiast zdania „musimy zwiększyć pokrycie testami”, mówimy „ten obszar produktu generuje X zgłoszeń miesięcznie, każde kosztuje zespół wsparcia i developmentu Y godzin, a 80 procent z nich powtarza ten sam wzorzec błędu”. To samo ryzyko, ale opisane w walucie, którą zarząd realnie rozlicza: godziny, pieniądze, powtarzalność. Testerzy mierzą pokrycie i liczbę scenariuszy. Zarząd mierzy koszt przestoju i utracone przychody. Strategia testowania, która nie tłumaczy jednego na drugie, zostaje wewnętrznym dokumentem QA, nie decyzją firmy.

Druga rzecz, która pomaga w tej rozmowie: konkretna liczba zamiast ogólnika. „Duża liczba błędów krytycznych” nie przekonuje nikogo, kto widział dziesiątki podobnych zdań w prezentacjach. „46 procent mniej błędów krytycznych na produkcji” przekonuje, bo da się to zestawić z budżetem i sprawdzić za kwartał. Dlatego każda strategia, którą projektujemy, ma od początku wybraną metrykę do raportowania zarządowi, ustaloną zanim ruszy wdrożenie, nie wymyśloną po fakcie, żeby uzasadnić koszt projektu.

Sześć elementów, z których faktycznie składa się strategia testowania

Gdy zdejmiemy z tego pojęcia żargon, strategia testowania w organizacji sprowadza się do sześciu konkretnych decyzji, spisanych z góry, a nie wymyślanych na nowo przy każdym wydaniu.

1. Poziomy testów i podział odpowiedzialności. Kto testuje jednostkowo, kto integracyjnie, kto akceptacyjnie, i czy te granice są w ogóle spisane, czy każdy zespół rozumie je inaczej.
2. Kryteria wejścia i wyjścia dla wydania. Co musi być prawdą, żeby wydanie mogło wystartować, i co musi być prawdą, żeby mogło się zakończyć. Bez tego kryterium staje się zdanie „chyba jest okej”, wypowiadane pod presją terminu.
3. Zarządzanie ryzykiem, nie tylko pokryciem. Które ścieżki są krytyczne dla biznesu i dostają więcej uwagi, a które mogą poczekać. Strategia bez priorytetów ryzyka traktuje formularz kontaktowy tak samo poważnie jak proces płatności.
4. Miejsce testów w cyklu CI/CD. Czy testy są bramką przed wdrożeniem, czy czymś, co i tak nikogo nie zatrzymuje. Piszemy o tym szerzej w artykule o TestOps i QualityOps, gdzie pokazujemy, jak połączyć testowanie z automatyzacją i procesem wydawniczym w jeden spójny system.
5. Dokumentacja, która przetrwa rotację zespołu. Strategia zapisana wyłącznie w doświadczeniu jednej osoby nie jest strategią organizacji, tylko jej ryzykiem kluczowej osoby.
6. Kompetencje zespołu dopasowane do strategii, nie odwrotnie. Jeśli strategia zakłada testy wydajnościowe i bezpieczeństwa, a zespół ich nie ma, strategia zostaje na papierze. Decyzja o tym, kiedy w ogóle wchodzić z testowaniem, a kiedy jeszcze nie ma czego stabilizować, to osobne pytanie, które rozbieramy w artykule o Shift Left Testing.

Żaden z tych sześciu punktów nie wymaga wielkiego budżetu na start. Wymaga decyzji i zapisania jej, zanim zacznie się jej brakować w najgorszym możliwym momencie, czyli tuż przed dużym wydaniem.

Dowód liczbowy: co realnie daje spisana strategia

Argument „będzie lepiej” jest łatwy do wypowiedzenia i trudny do udowodnienia, więc zamiast obietnicy pokazujemy dwa potwierdzone wdrożenia.

Drugi dowód pochodzi z branży automotive i wynajmu aut. W projekcie dla Autono po uporządkowaniu procesu testowego liczba błędów krytycznych w procesach rezerwacji spadła o 55 procent, a system pozostał stabilny przy obciążeniu większym o 120 procent w sezonie wakacyjnym, czyli dokładnie wtedy, gdy strategia testowania albo działa, albo nie działa: pod realnym obciążeniem, nie na sucho. Do tego doszedł mierzony wzrost satysfakcji użytkowników aplikacji mobilnej.

W obu przypadkach efekt nie wziął się z dołożenia większej liczby testerów, tylko z uporządkowania tego, co i kiedy testujemy. To jest właśnie strategia w praktyce: decyzja o priorytetach, nie o liczbie rąk do pracy.

Obiekcja: u nas każdy zespół pracuje inaczej

To zastrzeżenie słyszymy niemal przy każdej rozmowie o strategii dla więcej niż jednego zespołu, i traktujemy je poważnie, bo zawiera ziarno prawdy: dwa zespoły w tej samej firmie rzeczywiście mogą mieć inny stack, inny rytm wydań i inny poziom ryzyka biznesowego. Różnica polega na tym, że strategia testowania nie ma na celu ujednolicić narzędzia, tylko ujednolicić pytania, które zespół zadaje sobie przed wydaniem. Zespół A i zespół B mogą testować w różnych frameworkach i mieć różne kryteria wejścia, ale oba powinny umieć odpowiedzieć na to samo pytanie: co się stanie, jeśli to wydanie zawiedzie, i czy jesteśmy na to gotowi.

W case PKO BP dokładnie to rozróżnienie pozwoliło wdrożyć strategię w całej organizacji bez zmuszania każdego zespołu do identycznego procesu. Wspólny szkielet decyzyjny, lokalna implementacja. To jest też powód, dla którego audyt musi poprzedzać strategię: dopiero audyt pokazuje, gdzie różnice między zespołami są uzasadnione realnym ryzykiem, a gdzie są tylko przyzwyczajeniem, którego nikt nie zakwestionował.

Audyt przed strategią, nie na odwrót

Najczęstszy błąd, jaki widzimy, to próba napisania strategii testowania bez wcześniejszego sprawdzenia, jak firma testuje dzisiaj. Strategia zaprojektowana bez audytu punktu wyjścia rozwiązuje problemy, których zespół może nie mieć, i pomija te, które realnie go bolą. Dlatego u nas kolejność jest zawsze taka sama: najpierw audyt QA, który pokazuje, gdzie dziś jest ryzyko i gdzie testowanie jest fikcją, dopiero potem strategia jakości oprogramowania szyta pod realny stan, nie pod wyobrażenie o nim.

Dla firm, w których problemem nie jest brak wiedzy technicznej, tylko brak wspólnego języka między QA, developmentem i zarządem, dobrze sprawdza się dodatkowo krok warsztatowy z decydentami. Prowadzimy warsztaty QA dla zespołów i C-level, których celem jest właśnie to: żeby zarząd i zespół techniczny wyszli z tego samego spotkania z tą samą definicją tego, co znaczy „gotowe do wydania”.

Nasza perspektywa: budowa strategii

Jak wygląda wdrożenie strategii w praktyce

Strategia testowania, która trafia do nas jako zlecenie, prawie nigdy nie zaczyna się od pustej kartki. Zaczyna się od organizacji, która już testuje, tylko robi to niespójnie między zespołami albo bez udokumentowanych zasad. Dlatego wdrożenie nie polega na wymyśleniu procesu od zera, tylko na spisaniu tego, co działa, odrzuceniu tego, co nie działa, i domknięciu luk, które audyt wskaże jako priorytetowe. W praktyce ma to zwykle cztery etapy.

1. Audyt punktu wyjścia. Rozmowy z zespołami, przegląd dokumentacji, jeśli istnieje, i mapa ryzyk: które obszary produktu są krytyczne dla przychodu, a które mogą zawieść bez większych konsekwencji.
2. Projekt strategii z jednym pilotażowym zespołem. Zamiast pisać dokument dla całej organizacji na raz, wybieramy zespół, na którym da się szybko sprawdzić, czy założenia trzymają się rzeczywistości.
3. Pomiar efektu pilotażu. Konkretna metryka ustalona przed startem, na przykład czas regresji albo liczba błędów krytycznych na produkcji, odczytana ponownie po kilku tygodniach działania nowych zasad.
4. Rozszerzenie na kolejne zespoły, z lokalną adaptacją. Wspólny szkielet decyzyjny zostaje, szczegóły wykonawcze dopasowują się do specyfiki każdego zespołu, dokładnie tak, jak opisaliśmy to wyżej przy obiekcji o różnicach między zespołami.

Ten sam rytm zastosowaliśmy przy PKO BP: audyt istniejących procesów QA szedł równolegle z projektowaniem strategii, a szkolenia i warsztaty dla zespołów QA weszły dopiero wtedy, gdy szkielet decyzyjny był już ustalony. Kolejność odwrotna, czyli szkolenie zespołów z procesu, który jeszcze się zmienia, kończy się tym, że ludzie uczą się wersji, którą i tak trzeba będzie poprawić.

Od czego zacząć u siebie

Zanim zaczniecie pisać dokument strategii, odpowiedzcie sobie na trzy pytania. Pierwsze: kto dziś decyduje, że wydanie jest gotowe, i czy ta osoba potrafi to uzasadnić inaczej niż „czujemy się dobrze”? Drugie: co się stanie, jeśli ta osoba odejdzie z firmy w przyszłym miesiącu, czy proces przetrwa, czy zniknie razem z nią? Trzecie: ile realnie kosztuje was dziś błąd, który wychodzi na produkcję, licząc czas naprawy, utracone zaufanie klienta i godziny zespołu spalone na gaszenie pożaru zamiast rozwoju produktu?

Jeżeli na któreś z tych pytań nie macie dziś dobrej odpowiedzi, to nie jest powód do wstydu. To jest dokładnie ten punkt, od którego zaczyna się rozmowa o strategii testowania, zanim padnie pierwsze słowo o narzędziach.

Powiązane na blogu Quality Island

• Audyt QA w sektorze regulowanym: co pokazuje case PKO BP
• Jak skrócić testy regresyjne z 5 dni do 10 godzin: case Argos
• Outsourcing testów oprogramowania: kiedy się opłaca i jaki model wybrać
• Shift Left Testing: wady i zalety

Jeśli interesuje was szersze spojrzenie na decyzje o jakości, które kosztują dopiero rok później, na StrefieQA rozbieramy to od strony strategicznej: 5 decyzji o jakości, których na pewno pożałujecie za rok.

Pełna lista źródeł

• OpenText, Capgemini i Sogeti, World Quality Report 2024-25, 2024, capgemini.com. Stąd dane o 57 procentach organizacji bez kompleksowej strategii automatyzacji testów i 64 procentach zmagających się z systemami legacy
• CISQ (Herb Krasner), The Cost of Poor Software Quality in the US: A 2022 Report, 2022, it-cisq.org. Stąd koszt złej jakości oprogramowania w USA: 2,41 biliona dolarów rocznie, w tym około 1,52 biliona długu technicznego
• Wikipedia (na podstawie dokumentów SEC), Knight Capital Group, awaria z 1 sierpnia 2012, dostęp 2026, en.wikipedia.org. Stąd przebieg awarii: 440 milionów dolarów straty w 45 minut i przejęcie firmy w 2013 roku
• Case study klienta Quality Island: PKO BP, bankowość, zakres prac (strategia jakości oprogramowania dla całej organizacji, audyt procesów QA, szkolenia i warsztaty), 2026
• Case study klienta Quality Island: Argos, e-commerce, liczby potwierdzone przez klienta, 2026
• Case study klienta Quality Island: Autono, automotive i car rental, liczby potwierdzone przez klienta, 2026
• Dane własne Quality Island: ponad 152 zrealizowane projekty