Praca nad nowym produktem software’owym przypomina trochę remont mieszkania. Masz wizję, plany, ale żeby sprawdzić, czy ściany nie są zgniłe, czy instalacja elektryczna wytrzyma, potrzebujesz kogoś z odpowiednim sprzętem i wiedzą. W kodzie tym sprzętem są testy, analizy, audyty bezpieczeństwa. Wielu zespołów programistycznych nie stać na utrzymanie pełnego zaplecza do tego na co dzień. Stąd rosnąca popularność zewnętrznych laboratoriów software’owych. Ale jak wybrać taką firmę, która nie zrobi tylko „papierkowej kontrolki”, a rzeczywiście pomoże uniknąć katastrofy? Opowiem wam o tym, na co patrzeć, bazując na własnych wpadek i sukcesach.
Kluczowy jest pierwszy kontakt i jego jakość. Jeśli od razu dostajesz gotową, sztywną ofertę bez próby zrozumienia twojego konkretnego problemu, to jest czerwona flaga. Dobra współpraca zaczyna się od rozmowy. Ja na przykład, szukając partnera do głębokiej analizy bezpieczeństwa jednego z systemów, trafiłem na www.swlab.pl. Nie zaczęli od cennika, tylko od pytania: „Co tak naprawdę chcecie zabezpieczyć i przed czym?”. Ta różnica w podejściu jest odczuwalna od pierwszej minuty. Nie jest to reklama, a przykład tego, że warto szukać miejsc, które zadają dobre pytania.
Więc jak się do tego zabrać? Oto kilka praktycznych obszarów, które warto przetestować, zanim podpiszesz cokolwiek.
Sprawdź, czy mówią twoim językiem (i nie chodzi o polski)
Każda branża ma swój żargon. IT ma go wyjątkowo dużo. Problem pojawia się, gdy laboratorium używa go, by zakryć brak konkretów. Mówienie o „synergii frameworków” czy „holistycznym audycie” nic nie znaczy. Zapytaj o metodologię. Jak konkretnie testują? Korzystają z narzędzi OWASP? Jak wygląda ich raport – czy to zrozumiała lista punktów do naprawy z przykładem kodu, czy dwustronicowe streszczenie pełne ogólników? Prawdziwi specjaliści potrafią wyjaśnić skomplikowane problemy prostymi słowami. Jeśli czujesz, że celowo się gubisz w gąszczu terminów, odchodź.
Nie wierz w stuprocentowe obietnice
Żadne laboratorium, nawet to najlepsze, nie zagwarantuje, że po jego testach twój kod będzie w 100% wolny od błędów lub całkowicie bezpieczny. To po prostu niemożliwe. Oprogramowanie jest zbyt złożone. Ostrzegam przed tym, bo spotkałem się z firmami, które tak właśnie obiecywały – „żadnych krytycznych błędów po naszym audycie”. To nieuczciwe. Rzetelny partner powie ci wprost: „Znajdziemy wiele problemów, być może nawet wszystkie krytyczne, ale nie możemy dać absolutnej gwarancji. Nasza praca znacznie minimalizuje ryzyko”. Taka uczciwość budzi zaufanie.
Poproś o case study z twojej niszy
Laboratoria często chwalą się pracą dla dużych, znanych brandów. To dobrze, ale dla ciebie ważniejsze może być, czy mają doświadczenie w twojej konkretnej dziedzinie. Testowanie aplikacji bankowej rządzi się innymi prawami niż testowanie gry mobilnej czy systemu IoT dla przemysłu. Zapytaj wprost: „Czy mieliście już klienta, który robił podobny produkt do mojego? Co było dla niego największym wyzwaniem?”. Jeśli potrafią opowiedzieć o konkretnym projekcie (oczywiście zachowując poufność), znają specyfikę. Jeśli odpowiadają ogólnikami, ich doświadczenie może być zbyt uniwersalne, by naprawdę pomóc.
Przyjrzyj się raportowi końcowemu zanim zaczniesz współpracę
To moja złota zasada. Zanim zatrudnisz laboratorium, poproś o przykładowy, anonimizowany raport z jakiegoś projektu. Nie chodzi o to, by czytać go techniczne od deski do deski, ale by zobaczyć jego strukturę. Czy błędy są posegregowane według wagi? Czy jest wyraźnie wyszczególnione, jak odtworzyć problem? Czy obok opisu błędu znajduje się rekomendacja, jak go naprawić? Suchy komunikat „wykryto podatność SQL Injection” jest bezwartościowy. Cenna jest informacja: „W pliku X.php, w linii 45, funkcja Y nie sanitizuje parametru ‘id’. Oto fragment kodu pokazujący lukę i oto przykładowa poprawka”. Taki raport jest narzędziem pracy dla twoich programistów, a nie tylko pieczątką dla kierownika.
Zweryfikuj, czy współpraca kończy się na wysłaniu pliku PDF
Największa wartość często pojawia się po dostarczeniu raportu. Czy laboratorium jest otwarte na wyjaśnienie swoich ustaleń twojemu zespołowi na spotkaniu? Czy oferuje konsultację przy wdrażaniu poprawek? Niektóre firmy uważają, że ich praca kończy się z chwilą kliknięcia „wyślij”. Tymczasem dla ciebie zaczynają się wtedy schody – trzeba zrozumieć problemy i je naprawić. Upewnij się, że w umowie lub w ofercie masz jasno określone, czy i jaki rodzaj wsparcia po dostarczeniu wyników jest wliczony w cenę. Godzina rozmowy z analitykiem bezpieczeństwa, który wytłumaczy wątpliwości, jest warta więcej niż dziesięć stron szczegółowego, ale niejasnego raportu.
Ostateczny wybór to zawsze mieszanka czynników: ceny, kompetencji i zwykłego ludzkiego wrażenia. Na co więc szczególnie uważać? Podsumujmy to w krótkiej liście.
- Unikaj pośredników. Szukaj laboratorium, które pracuje bezpośrednio z własnymi testerami i inżynierami. Komunikacja przez „agencję” lub „koordynatora” utrudnia i wydłuża proces.
- Sprawdź opinie, ale szukaj głębiej niż pierwszy wynik w Google. Zapytaj w swoim gronie zawodowym, na forach branżowych. Czasami jedna szczera rekomendacja od zaufanej osoby jest więcej warta niż dziesięć świetnie napisanych referencji na stronie.
- Nie traktuj wyboru jak jednorazowego zakupu. To ma być partner na dłużej, bo oprogramowanie się ciągle rozwija. Nowe funkcje to nowe potencjalne błędy. Zastanów się, czy ta firma to ktoś, z kim chcesz współpracować także za rok.
- Zadbaj o dobrą komunikację od samego początku. Określ jasno, kto jest twoją osobą kontaktową, a kto po stronie laboratorium. Chaos w korespondencji często zapowiada chaos w projekcie.
Wybierając laboratorium, tak naprawdę wybierasz ludzi. Ludzi, którzy przejrzą twój kod, zrozumieją twoją biznesową logikę i wskażą miejsca, gdzie może się on złamać. To nie jest transakcja, to bardziej zawiązanie sojuszu. Warto poświęcić trochę czasu na znalezienie sojusznika, który będzie patrzeć w tę samą stronę co ty – na tworzenie dobrego, solidnego oprogramowania. A ty, na co ostatnio zwróciłeś uwagę przy takim wyborze?
