Dyrektor IT ma dziś dwa równoległe zmartwienia. Pierwsze jest oczywiste: dowozić zmiany szybciej, bezpieczniej, bez awarii. Drugie jest mniej widowiskowe, ale potrafi zaboleć mocniej: nie wpaść w układ, w którym płaci się za testowanie, a jakość wcale nie rośnie. Jeśli kiedykolwiek mieliście poczucie, że współpraca z zewnętrzną firmą QA bardziej przypominała kupowanie roboczogodzin niż kupowanie spokoju i przewidywalności, to wiecie, o czym mowa.
- Zacznijcie od prostego pytania: po co Wam zewnętrzne QA
- Jak czytać ofertę, żeby nie dać się oczarować
- Checklista dla dyrektora IT: osiem pytań przed podpisaniem umowy
- Co powinno być w umowie, a czego nie da się w niej zapisać
- Jak porównywać oferty, żeby porównać to samo
- Jak wygląda dowód, który warto brać na poważnie
- Najczęstsze błędy przy wyborze i jak ich uniknąć
Ten artykuł jest o wyborze partnera do testów oprogramowania w sposób, który ma sens biznesowy. Nie chodzi o to, żeby znaleźć najtańszych testerów. Chodzi o to, żeby znaleźć firmę, która faktycznie zmniejszy ryzyko, skróci czas reakcji na problemy i odciąży zespół, a nie dołoży kolejny kanał komunikacji, który trzeba będzie utrzymywać. W tytule jest checklista, więc ją dostaniecie, ale w wersji, która nadaje się do realnych rozmów z dostawcami. Bez papierologii. Za to z pytaniami, które szybko odsiewają firmy dobrze brzmiące w prezentacji, a słabsze w praktyce.
Zacznijcie od prostego pytania: po co Wam zewnętrzne QA
To moment, w którym wiele organizacji robi błąd. Wysyła zapytanie ofertowe, zbiera oferty, porównuje stawki i liczbę osób, a dopiero potem próbuje dopasować to do swoich problemów. Tymczasem wybór firmy do testów oprogramowania powinien zacząć się od diagnozy, a nie od zakupów.
Nie jesteście w tej decyzji sami. Według Global Outsourcing Survey 2024 firmy Deloitte, przeprowadzonego wśród ponad 500 menedżerów, 80 procent z nich planuje utrzymać albo zwiększyć inwestycje w outsourcing do zewnętrznych dostawców. Ten sam raport Deloitte podaje, że 83 procent badanych korzysta już z AI w ramach usług zlecanych na zewnątrz, więc pytanie „kto i jak sprawdza pracę wykonaną z pomocą AI” przestało być teoretyczne. Skoro wybór dostawcy staje się rutyną, tym bardziej warto robić go metodą, a nie przeczuciem.
Zwykle chodzi o jeden z trzech scenariuszy. Albo chcecie się szybko doskalować, bo wewnętrzny zespół nie wyrabia z regresją i rosnącą liczbą integracji. Albo potrzebujecie kompetencji, których nie macie na pokładzie: automatyzacji, wydajności, bezpieczeństwa, testów mobilnych, dostępności. Albo szukacie niezależnej oceny ryzyka, bo w organizacji brakuje drugiej pary oczu, która wprost powie, gdzie jest czerwone pole. Do tego scenariusza najlepiej pasuje niezależny audyt QA z rekomendacjami, a nie od razu wieloletni kontrakt. Do tego dochodzi czwarty scenariusz, coraz częstszy w sektorze regulowanym: testy musi wykonać podmiot niezależny od producenta oprogramowania, bo tak każe regulator albo umowa z klientem.
Te cele oznaczają różne modele współpracy. Jeśli nie nazwiecie ich na starcie, możecie skończyć z dostawcą, który robi wszystko wystarczająco, ale nic naprawdę dobrze. A w QA przeciętność bywa droga.
Źródło: metodyka i praktyka własna Quality Island z ponad 100 firm, które skorzystały z usług lub szkoleń.
Jak czytać ofertę, żeby nie dać się oczarować
Oferty firm testowych często brzmią podobnie. Każdy ma doświadczenie, każdy stosuje najlepsze praktyki, każdy pracuje zwinnie. W realnej selekcji liczy się to, czy dostawca potrafi przełożyć te deklaracje na konkret: jakie ryzyka potrafi wyłapać, jak wygląda jego proces pracy, jak raportuje i jak szybko jest w stanie dać Wam rzetelną informację, czy release jest bezpieczny.
Z perspektywy dyrektora IT ważne są trzy rzeczy: przewidywalność, transparentność i odpowiedzialność. Przewidywalność oznacza, że wiecie, co dostaniecie i kiedy. Transparentność oznacza, że widzicie postęp, ryzyka i problemy bez wyciągania tego z ludzi na siłę. Odpowiedzialność oznacza, że dostawca nie znika za zdaniem „to nie po naszej stronie”, tylko pomaga rozwiązać problem, nawet jeśli źródło jest gdzie indziej. Jeśli oferta nie mówi jasno, jak firma działa w tych trzech obszarach, to jest sygnał ostrzegawczy. W QA ładne PDF-y nie łapią błędów.
Checklista dla dyrektora IT: osiem pytań przed podpisaniem umowy
1. Czy rozumieją Wasz produkt i ryzyko, czy tylko wykonują testy
Dobra firma QA zacznie dopytywać i szybko przejdzie do ryzyk biznesowych: krytyczne ścieżki, utrata danych, dostępność, integracje, zgodność, obciążenie, bezpieczeństwo. Słabsza firma ucieknie w ogólniki i opowie, że wszystko zależy. Pierwsze spotkanie mówi o dostawcy więcej niż oferta.
2. Jak wygląda ich tydzień pracy z zespołem produktowym
Kiedy są w refinemencie, jak przygotowują testy do user stories, jak szybko dostarczają feedback, co robią, gdy wymagania są niejasne, jak eskalują ryzyka i kto podejmuje decyzje o akceptacji. Chodzi o to, czy potrafią działać w rytmie developmentu, a nie obok niego. Jeśli QA ma być zewnętrzne, komunikacja musi być prostsza, a nie bardziej skomplikowana.
3. Jakimi metrykami będą raportować
Dyrektor IT nie potrzebuje raportów o liczbie wykonanych testów. Potrzebuje sygnałów, które pokazują, jak zmienia się ryzyko i koszt: trend defektów w krytycznych obszarach, liczba regresji po wydaniu, czas wykrycia i odtworzenia problemu, długość regresji przed releasem. Jeśli dostawca nie umie mówić językiem metryk i dopasować go do Waszego kontekstu, będziecie zarządzać współpracą intuicją. Dobry punkt odniesienia to metryki DORA: raport Accelerate State of DevOps 2024 od zespołu DORA w Google Cloud mierzy przepustowość i stabilność dostarczania, między innymi odsetek wdrożeń kończących się awarią i czas przywrócenia usługi.
4. Co zautomatyzują najpierw i czego nie zautomatyzują wcale
Tu najłatwiej przepalić budżet. Dobra firma powinna umieć powiedzieć, co automatyzować najpierw i dlaczego, gdzie nie automatyzować, jak będzie zarządzać danymi testowymi, jak zadba o stabilność testów i jak wpasuje to w CI. Jeśli słyszycie tylko „zrobimy narzędzie X i będzie dobrze”, to za mało. Zapytajcie wprost, jak wyglądałaby automatyzacja testów w Waszym CI po pierwszym kwartale i kto będzie ją utrzymywał, gdy projekt przejdzie w fazę rozwoju.
Według raportu DORA 2024 wzrost wykorzystania AI o 25 procent wiązał się z szacowanym spadkiem stabilności dostarczania o 7,2 procent i przepustowości o 1,5 procent, choć jakość dokumentacji rosła w tym samym badaniu o 7,5 procent. Ten sam raport podaje, że 39 procent respondentów ma niewielkie albo żadne zaufanie do kodu generowanego przez AI. Wniosek dla wyboru dostawcy: im szybciej Wasz zespół pisze kod, tym bardziej potrzebujecie kogoś, kto sprawdza go równie szybko.
5. Jak wygląda ich doświadczenie w testach niefunkcjonalnych
W wielu organizacjach największe koszty biorą się nie z braku testów funkcjonalnych, tylko z wydajności, bezpieczeństwa, konfiguracji, obserwowalności i integracji. Jeśli Wasze ryzyko leży w tych obszarach, poproście o konkretny przykład projektu: co wykryli, jak, jaki był efekt. Bez historii nie ma zaufania.
6. Jak wygląda onboarding
Tu wygrywa się albo przegrywa pierwsze dwa miesiące. Zapytajcie o plan wejścia w projekt: dostęp do środowisk, dane, repozytoria, narzędzia, kanały komunikacji, sposób podejmowania decyzji. Jeśli onboarding jest mglisty, współpraca będzie mglista. Dostawca, który ma za sobą wiele wejść w cudze systemy, ma ten plan gotowy i pokaże go od ręki. W naszych projektach pierwsze tygodnie najczęściej nie idą na pisanie testów, tylko na czekanie na dostępy do środowisk i dane testowe, więc zapytajcie dostawcę, czego potrzebuje od Was pierwszego dnia.
7. Jak dbają o ciągłość zespołu
W QA zrozumienie produktu jest wszystkim. Jeżeli co chwilę zmieniają Wam się ludzie, płacicie za onboarding w kółko, a tempo spada. Zapytajcie, jak dostawca dba o stabilność zespołu, jak zabezpiecza zastępstwa i jakie minimum doświadczenia mają osoby, które trafią do Waszego projektu. Zabezpieczeniem jest też wiedza po Waszej stronie: jeśli własny zespół zna podstawy testowania i automatyzacji, łatwiej ocenia pracę dostawcy, a terminy takich szkoleń znajdziecie w kalendarzu szkoleń Quality Island.
8. Jak rozstrzygają konflikty o priorytet defektu i decyzję o wydaniu
Konflikty pojawią się zawsze. Ktoś powie, że błąd jest krytyczny, ktoś inny, że to edge case. Ktoś będzie naciskał na release, ktoś inny na stop. Sprawdźcie, czy dostawca ma jasne podejście do klasyfikacji defektów i eskalacji ryzyka oraz czy potrafi mówić o wpływie na biznes, a nie tylko o technicznych szczegółach.
Co powinno być w umowie, a czego nie da się w niej zapisać
W umowie da się zapisać zakres, model rozliczeń, czas reakcji na zgłoszenia, zasady zmiany składu zespołu, własność artefaktów (testy automatyczne, dokumentacja, dane testowe) i sposób raportowania. Warto też zapisać punkt odniesienia: liczby z dnia startu, do których będziecie porównywać efekt po kwartale. Nie da się w umowie zapisać zaufania, tempa uczenia się produktu ani jakości rozmów w refinemencie. To sprawdzicie tylko w pilotażu.
Dlatego dobrym wzorcem jest pilotaż na jednym obszarze, na przykład regresja jednego modułu albo automatyzacja jednej krytycznej ścieżki, z jasno nazwanym efektem. Jeśli dostawca nie chce pilotażu, bo „to nie ma sensu przy tak małym zakresie”, to Wasza pierwsza informacja o tym, jak będzie pracował przy dużym.
Jak porównywać oferty, żeby porównać to samo
Stawka godzinowa jest najłatwiejsza do porównania i dlatego najczęściej porównuje się tylko ją. Tymczasem dwie oferty z tą samą stawką mogą różnić się dwukrotnie w koszcie kwartału. Poproście każdego dostawcę o to samo: plan onboardingu w tygodniach, skład zespołu z doświadczeniem każdej osoby, zasady zastępstw, sposób raportowania i trzy liczby, które obiecuje zmienić po kwartale. Dopiero wtedy stawka nabiera sensu, bo wiecie, ile godzin pójdzie na wejście w projekt, ile na rotację, a ile na właściwą pracę. Dostawca, który nie chce podać tych informacji przed umową, nie poda ich także po niej. Wybór firmy QA wyłącznie po stawce godzinowej przypomina wybór chirurga po cenie skalpela: oszczędność widać od razu, rachunek przychodzi później.
Ten rachunek bywa duży. Według raportu CISQ z 2022 roku koszt słabej jakości oprogramowania w samych Stanach Zjednoczonych wyniósł co najmniej 2,41 biliona dolarów, a skumulowany dług techniczny około 1,52 biliona dolarów. Z naszego doświadczenia wynika, że różnica między dostawcami rzadko leży w stawce, a prawie zawsze w tym, ile z tego długu pomagają spłacić, a ile po cichu dokładają.
Jak wygląda dowód, który warto brać na poważnie
Referencja bez liczb to opinia. Referencja z liczbami to dowód. Przykład tego, jak powinien wyglądać opis efektu: w projekcie dla Argos, firmy e-commerce, automatyzacja testów i uporządkowanie procesów QA skróciły regresję przed wydaniem z pięciu dni do dziesięciu godzin, liczba awarii w okresach szczytowych spadła o 72 procent, liczba błędów krytycznych na produkcji o 46 procent, a konwersja wzrosła o 12 procent dzięki stabilnemu checkoutowi. Te liczby pochodzą od klienta. Właśnie o taki poziom konkretu pytajcie każdego dostawcę: co, u kogo, o ile i według czyich danych.
Drugi rodzaj dowodu to zakres pracy w organizacji o podobnej skali i rygorze. Dla banku (PKO BP) był to audyt istniejących procesów QA, opracowanie i wdrożenie strategii jakości dla całej organizacji oraz szkolenia zespołów. Dla firmy z branży medycznej (ChaosGears) budowa dokumentacji testowej i odbiorczej, procesów automatyzacji i realizacja procedur odbiorczych. Nie każdy projekt ma liczby, ale każdy ma zakres, który da się porównać z Waszym.
„Nie kupujcie testerów. Kupujcie zmianę w trzech liczbach: liczbie incydentów, czasie regresji i czasie wydania. Reszta to sposób dojścia.”
Najczęstsze błędy przy wyborze i jak ich uniknąć
Pierwszy błąd to wybór po stawce godzinowej. Tańsza stawka przy dłuższym onboardingu i większej rotacji wychodzi drożej w kwartał, a tego nie widać w porównaniu ofert. Drugi błąd to brak właściciela po Waszej stronie. Zewnętrzny zespół bez osoby, która ma czas na decyzje i odpowiedzi, produkuje zgłoszenia zamiast wyników. Trzeci błąd to zakup „pełnego QA” bez nazwania celu. Wtedy dostawca robi to, co umie najlepiej, a nie to, czego najbardziej potrzebujecie. Czwarty błąd to pominięcie pytania o własność testów automatycznych. Jeśli po zakończeniu współpracy testy zostają u dostawcy albo są napisane tak, że nikt ich u Was nie utrzyma, kupiliście usługę, nie aktywo.
- Wybór firmy do testów zaczyna się od diagnozy, nie od zapytania ofertowego: przepustowość, kompetencja, niezależna ocena albo wymóg regulacyjny to cztery różne zakupy.
- Oferta ma odpowiadać na trzy rzeczy: przewidywalność, transparentność i odpowiedzialność. Lista narzędzi tego nie zastępuje.
- Osiem pytań z checklisty odsiewa firmy dobre w prezentacji: od rozumienia ryzyka, przez metryki i onboarding, po sposób rozstrzygania sporów o release.
- Dowód to referencja z liczbami od klienta albo zakres pracy w organizacji o podobnym rygorze, nie logotypy na slajdzie.
- Pilotaż na jednym obszarze z nazwanym efektem sprawdza to, czego nie da się zapisać w umowie.
Jeśli chcecie przejść tę checklistę z nami po drugiej stronie stołu, porozmawiajmy o modelu współpracy dopasowanym do Waszego scenariusza, od pilotażu po dedykowany zespół.
Sprawdźcie modele współpracy QAPowiązane na Strefie QA
- Ile naprawdę kosztuje własny zespół QA, a ile body leasing
- 10 oznak braku kontroli przez Twojego dostawcę software’u
- Audyt niezależny od producenta: co naprawdę sprawdza kontroler
Źródła:
- Modele współpracy QA: dedykowany zespół, body leasing, zarządzanie testami, Quality Island
- Wyniki projektu Quality Island dla Argos (e-commerce), liczby potwierdzone przez klienta; zakresy projektów dla PKO BP i ChaosGears
- DORA (Google Cloud), Accelerate State of DevOps Report 2024, 2024, dora.dev/research/2024/dora-report. Wzięliśmy metryki przepustowości i stabilności dostarczania jako punkt odniesienia dla raportowania dostawcy.
- Google Cloud, Announcing the 2024 DORA report, 2024, cloud.google.com. Wzięliśmy liczby do ciekawostki: spadek stabilności o 7,2 procent i przepustowości o 1,5 procent przy wzroście wykorzystania AI o 25 procent oraz 39 procent respondentów z niskim zaufaniem do kodu z AI.
- Deloitte, Global Outsourcing Survey 2024, 2024, deloitte.com. Wzięliśmy odsetek menedżerów, którzy utrzymają albo zwiększą outsourcing (80 procent), i korzystających z AI w usługach zewnętrznych (83 procent).
- CISQ (Consortium for Information and Software Quality), The Cost of Poor Software Quality in the US: A 2022 Report, 2022, it-cisq.org. Wzięliśmy szacunek kosztu słabej jakości oprogramowania w USA (co najmniej 2,41 biliona dolarów) i długu technicznego (około 1,52 biliona dolarów).
- Metodyka i praktyka własna Quality Island z wdrożeń zewnętrznych zespołów QA
