10 oznak braku kontroli przez Twojego dostawcę software’u

Kupowanie software’u, czy to jako projektu, czy jako stałej usługi rozwoju, jest trochę jak wynajmowanie ekipy do remontu mieszkania. Możesz mieć świetną umowę, piękny harmonogram i błyszczące slajdy. A potem i tak wszystko rozbije się o jedno pytanie: czy ta ekipa naprawdę kontroluje jakość, czy tylko dowozi „coś”, a poprawki będą Twoim codziennym sportem. W IT to bywa jeszcze trudniejsze, bo jakość potrafi wyglądać dobrze przez kilka sprintów, a rachunek przychodzi później, gdy rośnie liczba zmian, integracji i użytkowników.

Dobra wiadomość jest taka, że brak kontroli nad jakością da się rozpoznać szybciej, niż myślisz. Zła wiadomość jest taka, że wiele firm patrzy na złe sygnały, ale je racjonalizuje, bo przecież dowożą, bo przecież są mili, bo przecież mamy już podpisane. Ten artykuł jest po to, żebyś miał listę konkretnych sygnałów ostrzegawczych i wiedział, o co pytać, zanim problem stanie się kosztowny.

Wracając do metafory remontu: dobra ekipa budowlana potrafi pokazać Ci, na jakim etapie jest tynkowanie, ile dni zostało do końca i co się stanie, jeśli zmienisz zdanie co do koloru ścian w połowie prac. Zła ekipa mówi „będzie dobrze” i znika za drzwiami na dwa tygodnie. W IT różnica jest dokładnie taka sama, tylko że skutki są mniej widoczne gołym okiem, dopóki nie spojrzysz na właściwe metryki. Poniższe dziesięć sygnałów to właśnie te metryki i zachowania, które odróżniają ekipę od systemu.

Dziesięć sygnałów w skrócie, zanim rozwiniemy każdy z osobna

Źródło: metodyka i praktyka własna Quality Island z audytów jakości dostawców.

Pierwszy sygnał: nie potrafią powiedzieć, ile defektów trafia na produkcję

Jeśli dostawca nie mierzy defect escape rate albo nie umie go wyjaśnić, to jest ogromna czerwona flaga. Nie dlatego, że wszyscy muszą mieć idealne metryki. Dlatego, że firma, która kontroluje jakość, zawsze wie, ile problemów ucieka i gdzie ucieka. Jeżeli słyszysz odpowiedzi w stylu to zależy, nie mamy takich danych, u nas jest mało bugów, to znaczy, że jakość jest zarządzana intuicją, a intuicja nie skaluje się przy większym projekcie.

W praktyce nie chodzi nawet o samą liczbę. Chodzi o to, czy dostawca pokazuje trend i czy umie wskazać, które obszary produktu generują ryzyko. Bez tego nie ma kontroli, jest reakcja. Warto przy pierwszej rozmowie zapytać wprost, jaki był defect escape rate w ostatnim kwartale i jak się zmienia w czasie. Dostawca, który ma kontrolę, odpowie liczbą i trendem w kilka sekund, bo to pytanie zadaje sobie sam co tydzień. Dostawca bez kontroli zacznie tłumaczyć, dlaczego to trudne do policzenia, co samo w sobie jest odpowiedzią.

Drugi sygnał: testy są traktowane jak etap na końcu, a nie jak system

Dostawca bez kontroli jakości zwykle działa tak. Najpierw development, potem szybkie testy, potem poprawki, potem wydanie. To wygląda jak proces, ale w rzeczywistości jest to wodospad w dwutygodniowych sprintach. Kontrola jakości zaczyna się za późno, więc każdy błąd kosztuje więcej, a Ty dostajesz produkt, który jest „prawie gotowy”, tylko że prawie gotowy to w praktyce najdroższy stan.

Dostawca, który ma kontrolę, buduje jakość w procesie. Ma jasne Definition of Done, ma code review, ma automatyczne testy w CI, ma bramki jakościowe i ma monitoring. I co ważne, potrafi Ci to pokazać w liczbach, a nie w obietnicach.

Warto tu rozróżnić dwie rzeczy: to, że dostawca w ogóle ma automatyzację, i to, że ta automatyzacja jest dobrze dobrana. Sama liczba testów w CI niczego nie gwarantuje, jeśli są w złych miejscach i chronią mało istotne ścieżki kosztem krytycznych. Pisaliśmy o tym szerzej w tekście o tym, co się naprawdę opłaca automatyzować, a co nie.

To nie są liczby z branżowego raportu, tylko z jednego naszego wdrożenia: automatyzacja testów i uporządkowanie procesów QA u klienta z branży e-commerce skróciło regresję przed releasem z pięciu dni do dziesięciu godzin. Podajemy je tutaj, bo pokazują konkretnie, jak wygląda różnica między dostawcą, który „testy robi na końcu”, a dostawcą, który ma to w systemie: nie kilka procent lepiej, tylko inny rząd wielkości.

Trzeci sygnał: regresja trwa długo, jest ręczna i wszyscy się do tego przyzwyczaili

Jeśli za każdym releasem jest wielodniowa regresja manualna, a zespół mówi, że tak musi być, to prawie zawsze oznacza brak inwestycji w automatyzację tam, gdzie daje zwrot. Taki dostawca będzie dowoził wolniej, będzie rzadziej releasował i będzie częściej wpadał w tryb gaszenia, bo feedback jest spóźniony.

Co gorsza, długa regresja ręczna bywa usprawiedliwiana jako dowód dbałości o jakość. To jest mylące. Dbałość o jakość to szybki feedback i stabilna bramka, nie tygodniowe klikanie. Tygodniowe klikanie to sygnał, że proces nie skaluje się z produktem, i że każdy kolejny kwartał wzrostu produktu będzie ten problem tylko pogłębiał, nie łagodził.

Uwaga: sama obecność testów end to end u dostawcy jeszcze o niczym nie świadczy. Rozrośnięta, niestabilna suita E2E potrafi kosztować więcej niż jej brak, bo daje złudne poczucie bezpieczeństwa zamiast realnej ochrony. Po czym poznać, że automatyzacja dostawcy sama wpadła w ten problem, opisaliśmy w tekście o testowym spaghetti.

Czwarty sygnał: dużo bugów wraca, mimo że były już naprawione

To jest klasyczny objaw słabej kontroli jakości. Jeśli to samo wraca, to znaczy, że nie ma skutecznych testów regresyjnych, nie ma analizy przyczyny źródłowej albo nie ma standardów, które zapobiegają powtórce. Dostawca może być bardzo sprawny w naprawianiu bugów, ale jednocześnie słaby w zapobieganiu im. A to jest różnica między ekipą, która robi jakość, a ekipą, która robi poprawki.

Dobre zespoły po poważnym defekcie robią krótkie postmortem, wyciągają wnioski i wprowadzają zabezpieczenie. Nie kolejną obietnicę, tylko konkret, test, check w CI, zmianę w Definition of Done, ulepszenie review. Jeśli dostawca nie ma takiego nawyku, to będziesz płacił za te same klasy problemów w kółko.

Piąty sygnał: testy są flaky albo środowiska są niestabilne i nikt nie traktuje tego poważnie

Flakiness to cichy zabójca. Jeśli testy raz przechodzą, raz nie, a odpowiedź brzmi to pewnie środowisko, to znaczy, że nikt nie kontroluje fundamentów. A bez fundamentów jakość jest loterią. Najgorsze jest to, że flakiness uczy ludzi ignorowania sygnałów. A jeśli ignorujesz sygnały, to prędzej czy później przepuszczasz realny defekt.

Dostawca z kontrolą jakości ma metryki flakiness, ma właściciela stabilności testów, ma izolację danych i środowisk, a czerwone buildy są traktowane jak alarm, nie jak tło. Warto zapytać wprost, jaki procent testów jest oznaczony jako niestabilny i kto odpowiada za jego obniżanie. Brak odpowiedzi na to pytanie jest odpowiedzią samą w sobie.

Szósty sygnał: nie ma jasnych kryteriów akceptacji i Definition of Done

Jeśli wymagania są miękkie, a akceptacja dzieje się na końcu jako „czy działa”, to będziesz miał spory, poprawki i rozjechane oczekiwania. Dostawca bez kontroli jakości często lubi takie rozmycie, bo daje pole manewru. Dostawca z kontrolą jakości chce jasności, bo jasność pozwala budować testy, automaty i przewidywalność.

W praktyce dobrym testem jest to, czy dostawca potrafi Ci pokazać, co znaczy gotowe dla jednego user story. Jeśli to jest lista typu kod zreviewowany, testy jednostkowe, testy integracyjne, aktualizacja dokumentacji, monitoring, to jest dobrze. Jeśli to jest działa u mnie, to jest źle.

Warto też sprawdzić, czy Definition of Done jest jedno dla całego zespołu, czy każdy programista ma swoją prywatną wersję. Rozjazd między osobami jest równie groźny jak jego całkowity brak, bo oznacza, że jakość dostarczanej pracy zależy od tego, kto akurat ją robił, a nie od tego, co firma jako całość uznaje za standard.

Siódmy sygnał: jakość jest raportowana językiem aktywności, a nie wpływu

Jeśli dostawca raportuje liczbę testów, liczbę wykonanych przypadków, liczbę zgłoszonych bugów, to jest to raportowanie operacyjne, nie zarządcze. Może być przydatne, ale nie świadczy o kontroli jakości. Kontrola jakości jest wtedy, gdy dostawca mówi o trendach, ryzykach i wpływie, czyli defect leakage, MTTR, stabilność pipeline, pokrycie krytycznych ścieżek.

Jeśli raporty brzmią jak encyklopedia, a nie jak instrukcja decyzji, to znaczy, że dostawca nie umie zarządzać jakością na poziomie systemu. Dobry raport odpowiada na pytanie „co powinniśmy zrobić w tym tygodniu”, zły raport odpowiada tylko na pytanie „co się działo”.

Ósmy sygnał: release zawsze jest stresujący i wymaga heroizmu

To jest sygnał kulturowy. Jeśli każde wdrożenie to nocne czuwanie, manualne checki, modlitwa i szybkie poprawki po wydaniu, to znaczy, że proces jest oparty na heroizmie, a nie na kontroli. Kontrola jakości oznacza, że release jest nudny. Nuda w release jest oznaką dojrzałości.

Dostawca, który ma kontrolę, ma feature flags, ma rollback, ma monitoring i ma szybkie mechanizmy reagowania. Dostawca, który jej nie ma, ma stres i nadgodziny, a Wy macie ryzyko, które ktoś inny przerzuca na Waszą noc.

Dziewiąty sygnał: brak przejrzystości w danych jakości i brak dostępu do wyników

Jeśli nie masz wglądu w wyniki testów, w historię buildów, w status pipeline, w defekty i ich klasy, to znaczy, że jakość jest w czarnej skrzynce. Czasem to wynika z narzędzi, czasem z procesów, a czasem z chęci kontroli narracji. Niezależnie od powodu, dla klienta to jest ryzyko. Bo jeśli nie widzisz danych, nie widzisz trendu, a jeśli nie widzisz trendu, to dowiesz się o problemie dopiero wtedy, gdy już zaboli.

Dobrym testem tego sygnału jest proste pytanie: czy moglibyście dziś, w tej chwili, poprosić o dostęp do dashboardu buildów i dostać go w kilka minut, czy dostawca musiałby najpierw „coś przygotować”. Przygotowywanie danych na żądanie klienta prawie zawsze oznacza, że na co dzień nikt tych danych nie ogląda, a raport powstaje dopiero wtedy, gdy ktoś zapyta.

Dziesiąty sygnał: wszystko da się zrobić, ale nic nie da się oszacować

To jest sygnał, który na pierwszy rzut oka nie dotyczy jakości, ale dotyczy jej bardzo mocno. Dostawca bez kontroli jakości często nie potrafi stabilnie estymować, bo nie ma kontroli nad długiem technicznym, stabilnością testów i liczbą regresji. Wtedy wszystko jest możliwe, ale terminy pływają, bo jakość generuje nieprzewidywalną pracę w tle.

Dostawca z kontrolą jakości potrafi pokazać, skąd biorą się estymaty, jakie jest ryzyko i co może je zmienić. To jest oznaka dojrzałości procesu.

Pozorna kontrola kontra prawdziwa kontrola

Kilka z powyższych sygnałów łatwo pomylić z ich pozornym przeciwieństwem, dlatego zestawiamy je obok siebie.

Co zrobić, jeśli widzicie te sygnały

Najgorsze, co można zrobić, to przeczekać. Jeśli dostawca nie ma kontroli nad jakością, problem nie rozwiąże się sam. Możecie natomiast szybko postawić warunki, które to wymuszą.

Źródło: metodyka i praktyka własna Quality Island.

Jeśli dostawca nie jest w stanie tego zrobić, to nie dlatego, że nie chce. Najczęściej dlatego, że nie umie. A wtedy decyzja biznesowa jest prosta.

Kiedy najlepiej to sprawdzić: przed podpisem, nie po

Najczęstszy błąd, jaki widzimy, to zadawanie tych pytań już w trakcie współpracy, kiedy pierwsze sygnały zaczynają boleć. Wtedy rozmowa jest trudniejsza, bo dostawca broni tego, co już dostarczył, a Wy jesteście związani umową i harmonogramem, który trudno przerwać bez kosztów. Dziesięć sygnałów z tego artykułu działa najlepiej jako lista pytań na etapie wyboru dostawcy, nie jako lista skarg po fakcie.

Jeśli już jesteście w trakcie współpracy i zauważacie te sygnały, najlepszy moment na reakcję to najbliższy przegląd kwartalny albo odnowienie umowy, nie środek sprintu. Poproście o odpowiedzi na piśmie, nie tylko ustnie na spotkaniu: dostawca, który naprawdę ma kontrolę, przygotuje je bez problemu, bo te dane i tak gdzieś już ma.

Kiedy warto sprawdzić to niezależnie, nie tylko zapytać

Zadanie tych trzech pytań na spotkaniu daje pierwszy sygnał, ale odpowiedzi dostawcy same siebie nie zweryfikują. Jeśli zależność od tego konkretnego dostawcy jest duża, albo jeśli branża, w której działacie, wymaga wykazania należytej staranności przed regulatorem czy klientem, warto sięgnąć po niezależny audyt jakości dostawcy, prowadzony przez firmę z zewnątrz, bez interesu w wyniku.

Nasza perspektywa

W Quality Island regularnie oceniamy jakość procesów dostawców z perspektywy klienta, między innymi w projekcie dla Argos w e-commerce, gdzie automatyzacja testów i uporządkowanie procesów QA skróciły regresję przed releasem z pięciu dni do dziesięciu godzin, obniżyły liczbę awarii w szczycie ruchu o 72 procent i zmniejszyły liczbę błędów krytycznych na produkcji o 46 procent. Te liczby nie są tu po to, żeby robić wrażenie. Są po to, żeby pokazać, jak wygląda w praktyce różnica między dostawcą bez kontroli a dostawcą z kontrolą, gdy ktoś faktycznie ją zmierzy.

Pierwszy wniosek z tej pracy: sygnały z tego artykułu rzadko występują pojedynczo. Firma, która nie mierzy defect escape rate, prawie zawsze też nie ma dashboardu dla zarządu i prawie zawsze też ma stresujące release’y, bo to są objawy tej samej przyczyny, nie dziesięć osobnych problemów.

Drugi wniosek: zmiana jest szybsza, niż firmy się spodziewają, jeśli dotyczy struktury procesu, a nie tylko dokładania kolejnych testów. Skrócenie regresji z pięciu dni do dziesięciu godzin nie wzięło się z napisania większej liczby testów, tylko z automatyzacji właściwych rzeczy i uporządkowania tego, co już istniało.

Trzeci wniosek: klient rzadko musi wybierać między „zerwać współpracę” a „tolerować dalej”. Najczęściej wystarczy postawić konkretne, mierzalne warunki i dać dostawcy realny czas na pokazanie postępu, na przykład jeden kwartał z jasno zdefiniowanym dashboardem jakości. Dostawca, który chce i potrafi się poprawić, zrobi to widocznie. Dostawca, który tylko chce, ale nie potrafi, ujawni to samo w tym procesie, zanim strata czasu urośnie do rozmiarów, których nie da się już łatwo odwrócić.

Powiązane na Strefie QA

• Automatyzacja testów: co się naprawdę opłaca automatyzować, a co nie
• Testy end to end na dużą skalę: jak unikać testowego spaghetti
• Testy bezpieczeństwa aplikacji: minimalny zestaw działań dla zarządów

Źródła:

• Case study klienta Quality Island: Argos, e-commerce, zakres pracy i wyniki potwierdzone przez klienta
• Niezależny audyt jakości oprogramowania, Quality Island
• Metodyka i praktyka własna Quality Island z audytów jakości dostawców