Testy?! A po co mi to? – historia współczesnego kamikaze

O tym, czy testy są potrzebne.

Jeśli jeszcze nie wiecie, w swoim życiu zawodowym miałem epizod z testowaniem, kiedy zaczynałem pracę jako programista. Trochę godzin poświęcałem na prowadzenie testów, pisanie masy specyfikacji oraz raportów. Były to testy z pogranicza programowania i badań nad elektroniką.

Jest to dla mnie dość wartościowe doświadczenie, ponieważ wiem, jak wygląda droga projektu IT od dokumentów, przez development aż po sprawdzenie, czy wszystko działa jak było to zapisane w dokumentacji. Pisałem trochę o tym tutaj – Projekt a testy.

Obecnie jako programista na wciąż na co dzień testuję – sam siebie poprzez unit testy. Nabyte umiejętności nie poszły na marne. Jeśli zobaczycie oferty dla programistów C++, prawie zawsze znajdziecie tam wśród poszukiwanych technologii Gtest 😉

Po kilku projektach widzę, że testy odgrywają jedną z kluczowych ról dla sukcesu. Uświadomiłem sobie jak odpowiedzialną rolą jest pozycja testera i jaki ma to wszystko wpływ na sprawny przebieg projektu.

Firmy często dla zachowania odrębności zespołu programistów od zespołu testowego, outsourcują testy, analizy i sprawdzanie jakości.

Dziś będzie właśnie o jednej z firm, która takie zlecenia wykonuje, mianowicie o Testspring. Siedziba firmy mieści się w moich rodzimych stronach, czyli w Katowicach. Zaufało im sporo poważnych firm i chcieli opowiedzieć mi trochę o testowaniu. Przeprowadziłem rozmowę z CEO Habibem Moskinem.

Inżynier domu: Jak zmieniło się Twoim zdaniem podejście do testowania na przełomie ostatnich lat?

Habib Moskin: Choć wydaje się, że miało to miejsce wieki temu, pamiętam kiedy musiałem potencjalnym klientom tłumaczyć co to są testy. Potem musiałem już tylko tłumaczyć, dlaczego są potrzebne. Teraz tłumaczę, dlaczego powinni wybrać moją firmę. 😉 Ostatnie lata były przełomowe dla branży IT. Przede wszystkim zauważono zalety płynące z wdrożenia kompletnego procesu zapewnienia jakości. Ma to związek z rosnącą popularnością metodyk zwinnych. To specyficzne podejście do wytwarzania oprogramowania, które zakłada, że powinniśmy budować software z klocków. Małych, funkcjonalnych części, prezentowanych jak najszybciej klientowi. Zalety? Po pierwsze, na bieżąco kontrolujemy zadowolenie odbiorcy, który widzi postępy i może je opiniować. Po drugie, dzięki krótkim cyklom, mamy lepszą kontrolę nad tym, jak pracujemy. Po każdej iteracji powinniśmy zastanowić się nad tym, co poszło nie tak, co sprawiło, że byliśmy mniej efektywni, a następnie zmienić to w kolejnym cyklu. Takie podejście jest prawie niemożliwe bez odpowiednio zaplanowanego procesu testów. Dzisiaj testerzy nie tylko zajmują się oprogramowaniem, ale pomagają przy pracach z wymaganiami, uczestniczą w prezentacjach produktów dla klienta czy przeprowadzeniu szkolenia użytkowników. Odciążają członków zespołu, którzy mogą skupić się w stu procentach na swoich zadaniach. Do tego przyczyniają się do skutecznego tworzenia oprogramowania, ponieważ wyłapują wszystkie pomyłki i problemy na wczesnych etapach. O wiele łatwiej jest przecież zmienić zapisy wewnętrznie sprzecznego wymagania niż poprawiać oprogramowanie, które już zostało wydane klientowi, a błąd pojawił się gdy użytkownik próbował wykonać jakąś akcję. To chyba najlepiej obrazuje zmiany w podejściu do testowania. Z fanaberii zamieniliśmy się w potrzebnych i docenianych członków zespołu. Najnowsze trendy wspierają moje przekonanie o wielozadaniowości testerów. Szybko rozwijające się narzędzia pozwalają na automatyzację wielu zadań, wymagając od nas coraz większej wszechstronności i gotowości na zmiany. Z drugiej strony duże skupienie zespołu na produkcie przesuwa na testerów ciężar oceny pod kątem poprawności procesów biznesowych, zgodności z wymaganiami prawnymi czy oczekiwaniami użytkownika. Obecnie ciężko rozróżnić poszczególne role testowe (analityk, manual, automatyk). Przechodzimy przeobrażenie z inżynierów testów w stronę specjalistów do spraw zapewnienia jakości. Oczekuje się od nas szerokiego spojrzenia, interdyscyplinarności, biegłości w użyciu narzędzi (które do niedawna uznawane były za narzędzia programistyczne), ale również rozległych umiejętności miękkich.

ID: Czym różni się dobre jakościowo wytestowanie od słabego?

HM: Ciężko jednoznacznie odpowiedzieć na takie pytanie. Wszystko zależy od kontekstu. W rzeczywistości rzadko mamy możliwość wykonania wszystkich czynności testowych. Ze względu na budżet, czas i inne kwestie projektowe. Dlatego warto kierować się trzema zasadami. Po pierwsze, w jaki sposób najmniejszym kosztem zminimalizować największe ryzyka produktowe (związane z wytwarzanym oprogramowaniem). Po drugie, oparcie się o zasady, a nie analogie. Po trzecie, pamiętać, że najważniejszy jest użytkownik. Często musimy decydować które części software’u przetestować, bo nie ma czasu na wszystko. Dobry tester upewni się, że wszystko to, czego najbardziej chciałby dokonać użytkownik, będzie możliwe do wykonania łatwo, szybko i skutecznie. Chyba można uznać za odpowiedź na to pytanie. Dobre jakościowo wytestowanie zapewnia zadowolenie użytkownika końcowego. Choć trzeba pamiętać, że to szerokie pojęcie. Przecież użytkownik będzie zadowolony nie tylko z przyjaznego interface’u, ale też z tego, że jego dane są bezpieczne – o czym wcale nie musi świadomie myśleć, przynajmniej do momentu wycieku tych danych.

ID: Czy wyobrażasz sobie w obecnych czasach projekt IT bez testów? Czym grozi słabe wytestowanie produktu?

HM: Dla żartów zacząłem ostatnio powtarzać, że tylko jakość może uratować świat. Choć muszę przyznać, że trochę w to wierzę. Software jest wszechobecny. Nie jesteśmy w stanie bez niego egzystować. W obecnych czasach nawet gdy odkręcamy wodę w kranie, polegamy na jakimś oprogramowaniu. Czy w takim razie możemy pozwolić sobie na niską jakość? Hipotetyczna sytuacja. Ktoś jedzie autem. Używa telefonu. Nie powinien używać? Ja to wiem, Ty to wiesz. Ale to, że nie wolno, nie znaczy, że ktoś tego nie zrobi. No więc użytkownik próbuje coś wykonać, niech to będzie choćby przeglądanie strony sklepu z ubraniami. Trwa promocja. Akcja zakupu jest niepotrzebnie skomplikowana. Software kiepski. Użytkownik śpieszy się do pracy, ale nie chce przegapić promocji. Software coraz bardziej przykuwa jego uwagę… Można rysować dalsze scenariusze, jak kto chce. Problem przyczynowości jest dla nas taki, że zazwyczaj obserwujemy bezpośrednie skutki naszych akcji i tyle. W przypadku oprogramowania skutki jednego błędu, nawet w najbardziej niepoważnych aplikacjach, mogą być bardzo poważne, choć trudno je jednoznacznie przewidzieć. Czy moja historia wydaje się naciągana? W takim razie możemy porozmawiać o Boeingach 737 MAX. W dwóch katastrofach ginie 346 pasażerów. Przyczyna? Źle działające oprogramowanie MCAS mające chronić przed automatycznym obniżeniem nosa samolotu w przypadku awarii sensorów. Tu skutek jest bardziej widoczny. Przy takiej ilości urządzeń elektronicznych, które tworzą ze sobą skomplikowane ekosystemy danych, bezpośrednio wpływające na nasze życie, nie możemy sobie pozwolić na brak odpowiedniej jakości! Uważam, że jakość, to nie tylko prawo użytkownika czy klienta, ale i obowiązek wytwórcy! Testy to jedyny dowód na to, że zamawiany produkt został wykonany należycie. Proszę wyobrazić sobie budowę, na której to robotnicy sami sobie odbierają kolejne etapy budowy, aby na koniec przekazać inwestorowi klucze do jego nowego, wspaniałego domu… Najważniejsza praca na nadchodzące pięć lat to już nie zwiększanie świadomości wśród software house’ów, tylko wśród użytkowników. ONZ od 2016 traktuje prawo dostępu do Internetu na równi z innymi prawami człowieka. Dlatego kolejny krok to uznanie, że każdy człowiek ma prawo oczekiwać jakości oprogramowania. Skoro nie możemy przed softwarem uciec, nie mamy na niego wpływu, powinniśmy mieć zagwarantowaną pewność, że wszystkie czynniki, które wpływają na nasze życie, zostały odpowiednio przetestowane i mają odpowiedni poziom jakości.

ID: Masz może jakiś ciekawy przykład, gdzie testy odegrały ważną rolę, ponieważ bez nich produkt mógłby zakończyć się bardzo źle?

HM: Problemem źle przetestowanego, niejakościowego software’u jest to, że nie daje on o sobie znać do momentu wystąpienia awarii. Bez testów, każdy produkt może wywołać nieoczekiwane skutki. Jednak nie dowiemy się tego do czasu, kiedy to nastąpi. Najwięcej wiemy o przypadkach, w których faktycznie niedostateczne testy skończyły się katastrofalnie. Mariner 1, Spirit Rover, Mars Climat Orbiter, Gemini 5… Jako że interesuję się astronomią i podbojem kosmosu, mógłbym długo wymieniać nazwy misji kosmicznych, które załatwił jakiś błąd. Jeśli chodzi o bardziej przyziemne przykłady – możemy porozmawiać o Therac-25. To maszyna stosowana przy naświetleniach, która miała ratować życie. Istnieje 6 potwierdzonych przypadków, kiedy jej działanie doprowadziło do urazu lub śmierci. Jak mogło się to wydarzyć? Nowa wersja Therac’a zastępowała starszą. Dokonano pewnych modyfikacji w konstrukcji maszyny. Zabrakło odpowiednich testów, które ujawniłyby na czas usterkę. Nowa maszyna była bardziej zaawansowana technologicznie. Kilka sprzętowych mechanizmów bezpieczeństwa chroniących przed naświetleniem zbyt dużą dawką promieniowania zostało zamienionych na ich odpowiedniki programistyczne. W teorii Therac-25 nie mógł naświetlać pacjentów zbyt dużymi dawkami. Dlatego początkowo producent odmawiał uznania, że wina może leżeć w maszynie. Po czasie okazało się, że wprawni terapeuci mogli używać konsoli maszyny z taką prędkością, że terapia rozpoczynała się przed ustawieniem odpowiednich filtrów, co skutkowało wypadkami. Ten przypadek chyba najlepiej obrazuje potrzebę odpowiednich testów. 

ID: Działacie od samego początku z projektem, od pisania unit testów wraz z dokumentacją czy wkraczacie, kiedy produkt jest już na ukończeniu?

HM: Zawsze marzą nam się projekty, w których ktoś przychodzi do nas z koncepcją swojego oprogramowania. Omawiamy ją, a dopiero potem pomagamy wybrać odpowiedni software house o którym wiemy, że dba o zapewnienie odpowiedniego poziomu jakości. Oczywiście, w praktyce bywa różnie. Wynika to po części z potrzeb rynku, z budżetów, a po części z usług, które świadczymy. Oprócz klasycznych testów prowadzonych w ramach projektów, w których nasi testerzy wchodzą w zespół i stają się jego częścią, prowadzimy też takie usługi, jak na przykład testy akceptacyjne. Czasem ważne jest dla klienta sprawdzenie produktu końcowego i upewnienie się, że spełni wymagania biznesowe co do procesów i norm. To szczególnie popularne przy wdrożeniach przemysłowych czy w logistyce. Czasem prowadzimy tylko audyty bezpieczeństwa lub sprawdzamy wydajność na kolejnych etapach projektu. Świadczymy też usługi consultingowe, które pomagają naszym partnerom skupić się na tym wszystkim, co poza testami skutkuje wysoką jakością. Odpowiem więc klasycznym – to zależy.

ID: Zatrudniacie trochę testerów, czym cechuje się dobry tester? Kiedy rekrutujecie kogoś do siebie, jakich osób szukacie?

HM: Potrzebujemy przede wszystkim zdolnych ludzi, którzy są w stanie bardzo szybko doszkalać się, korzystać z wiedzy zgromadzonej w firmie i skutecznie ją wykorzystywać. Ze względu na nasze doświadczenie i bardzo specyficzny profil firmy odeszliśmy od klasycznych procesów rekrutacyjnych. Mamy dwa sposoby pozyskania dobrego specjalisty. Czasem szukamy ludzi z doświadczeniem, częściej wybitnych ludzi, którzy mają wszystkie zadatki na dobrego testera, aby potem ich wyszkolić. W obu przypadkach nasz pierwszy etap rekrutacji zupełnie pomija CV kandydata. Jedyne, co nas na tym etapie może zainteresować, to wiedza dziedzinowa albo jakieś unikalne umiejętności – na przykład praca z mikrokontrolerami lub znajomość rynku finansowego. Z racji doświadczenia i potrzeb szukamy przede wszystkim ludzi spełniających nasze wymagania. Masło maślane? Wymagania rekrutacyjne są odzwierciedleniem tego, co obserwujemy na rynku. Obraz pracy testera zmienia się bardzo dynamicznie, dlatego podczas rekrutacji sprawdzamy przede wszystkim możliwości kandydata w zakresie jego umiejętności kojarzenia faktów, logicznego myślenia, sposobu przetwarzania danych, rozwiązywania problemów czy możliwości poznawczych. Chcemy też ludzi, którzy będą potrafili zrozumieć, jakie mechanizmy i procesy stoją za jakością. Tacy kandydaci są w stanie dzielić nasze podejście i będą każdorazowo wybierać najlepsze metody i techniki według zasad, którymi się kierujemy. Dlaczego tyle energii wkładamy w wybór współpracowników? Ponieważ firma to przede wszystkim ludzie. Nie możemy tylko kreować się na liderów zapewnienia jakości. Musimy nimi faktycznie być.

Jak widać, morał jest jeden – trzeba testować. To nie tylko testy dla testów, pokrycia itp. Testy mają znaleźć odzwierciedlenie w najlepszym określeniu jakości. Słowa CEO Testspring są potwierdzeniem moich wrażeń co do projektów IT i testowania. Należy poświęcić temu etapowi powstawania produktu dużą uwagę.

Klienci, którzy otrzymują produkt IT, oczekują najwyższej jakości, konkurencja jest bowiem niesamowita. Każdy słyszał o słynnej polskiej wytwórni gier i ich nie do końca udanej premierze 😉 Ile było patchowania zaraz po. Reakcja na giełdzie też nie najzdrowsza, niesmak pozostawiony na zawsze. Żaden twórca chyba nie chce tego przeżywać.

Musimy wypuszczać produkt sprawdzony, inaczej może się skończyć katastrofą lub po prostu śmiercią interesu. Nie bądźmy kamikaze.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *