Jeszcze jakiś czas temu powszechnie stosowało się mit, który obrazował instytucję testera jako jednostki odpowiedzialnej za uprzykrzenie pracy programistów. Był on także uznawany za bezpośrednią przyczynę opóźnień w dostarczeniu produktu końcowego. Na całe szczęście, wraz ze wzrostem świadomości uczestników projektu na każdym etapie jego rozwoju, ów mit przechodzi do historii. Dziś „nielubienie” testerów to praktyka – nazwijmy to – co najmniej archaiczna.
Wspomniany wzrost świadomości oraz zmiana mentalności środowiska IT sprawiły, że przeprowadzanie profesjonalnych, dokładnych testów stało się swego rodzaju standardem. Testerzy na dobre zagościli w zespołach wytwórczych stanowiąc ich nieodłączną część. Wszystko w trosce o to, by wytworzony produkt był odpowiedniej jakości, a jego niezawodność była wizytówką. Czymś, co przyciągnie i zatrzyma klientów na dłużej.
Trend ten cieszy się popularnością także w zespołach badawczo – rozwojowych. Te z zasady wymagają od wszystkich zespołów odpowiednio silnej kreatywności oraz otwartości na stosowanie nowych narzędzi, języków czy technologii. W tym wpisie postaramy się pokrótce przedstawić rolę testerów biorących udział w projekcie SDNbox i wyzwania, z którymi zmagają się na co dzień w trakcie pracy.
Czym zajmuje się tester?
Ogólnodostępne w internecie informacje zazwyczaj dosyć zręcznie i zwięźle opisują to, kim jest tester oprogramowania i czym tak właściwie się on zajmuje.
Tester oprogramowania to osoba odpowiedzialna za weryfikacją prawidłowego działania oprogramowania lub systemu, zaś w jego obowiązkach leży także przeprowadzanie testów funkcjonalności. Praca testera w głównej mierze polega na wykrywaniu błędów i usterek, które zostają w dalszej kolejności przekazane programistom odpowiedzialnym za dany produkt bądź jego część. Efekty podejmowanych przez niego działań to poprawa jakości lub tworzenie nowego oprogramowania.
Powyższy opis pozwala wykreować w głowie obraz testera jako osoby odpowiedzialnej za zredukowanie liczby defektów w testowanym oprogramowaniu do minimum. Za defekt możemy uznać między innymi:
- niezgodność implementacji z dostarczoną dokumentacją produktową,
- niepożądane zachowanie oprogramowania wynikające z wykonania nieprzewidzianych przez programistów czynności,
- niepoprawne (z punktu widzenia użytkownika końcowego) zachowanie programu.
Mimo, iż wspomniane obowiązki stanowią dużą część pracy testera, nie są to jedyne kompetencje, przed jakimi stawia się go w zespole. Innymi słowy jego praca nie ogranicza się do ciągłej pogoni za niedoskonałościami. Niezwykle istotnymi zadaniami jest dbanie o dokumentację testową, tworzenie raportów bazujących na przeprowadzonych testach, prezentacja wytworzonych produktów czy chociażby sugerowanie zmian w oparciu o posiadane doświadczenie. By praca testera była efektywna – w zależności od projektu – może on korzystać z dóbr, które niosą ze sobą odpowiednie metodyki projektowe.
Zwinny projekt, zwinny tester
W skład projektu SDNbox wchodzi kilka zespołów wytwórczych, działających wspólnie w oparciu o popularną dziś metodykę – Scrum. Pod tym enigmatycznym hasłem kryje się prosty fakt, że zespół posiada odpowiednie kompetencje (takie jak developerskie, architektoniczne, testerskie czy scrum mastera), które pozwalają na dostarczenie produktu lub jego części w określonym czasie, czyli tak zwanym sprincie. Nie jest to jednak równoznaczne z tym, że członek zespołu wykonuje zadania wyłącznie wynikające z pełnionej przez niego roli. Są sytuacje, gdy testerzy wyrabiający się dobrze ze swoimi zadaniami, w ramach rozwoju, obdarowywani są prostszymi zadaniami programistycznymi. I podobnie w druga stronę, niekiedy programiści poświęcają swój czas na przeprowadzanie testów.
Odpowiednio układająca się wewnątrz zespołu współpraca, a także wzajemne przekazywanie wiedzy i wspólny rozwój umiejętności, poszerzanie kompetencji – te czynniki pozwalają na zachowanie ciągłości prac zespołu. Nawet wtedy, gdy dochodzi do nieprzewidzianych nieobecności, czy nawet dłuższych urlopów.
Wiem, co robię czyli od czego zacząć testy?
Przed przystąpieniem do planowania testów, niezbędne jest odpowiednie zrozumienie realizowanej funkcjonalności. Liczba zależności zachodząca między poszczególnymi komponentami oraz tajniki ich działania mogą z początku wydawać się mało zrozumiałe dla zespołu wytwórczego. Tutaj z pomocą przychodzą analitycy systemowi.
Analitycy, opierając się o przygotowane wcześniej historyjki użytkownika (user stories), tworzą przypadki użycia (use cases). Te z kolei stanowią podwaliny do poprawnego zdefiniowania przypadków testowych (test cases). By lepiej zapoznać się z kontekstem realizowanej funkcjonalności, stosuje się diagramy HLD (High Level Design), które są opracowywane przez architektów.
W oparciu o zebraną wiedzę, testerzy mają już podstawy, by przystąpić do procesu opracowywania oraz implementacji przypadków testowych. W trakcie procesu projektowania przypadków, osoba testująca skupia się nie tylko na pokryciu zakresu przedstawionego w przypadkach użycia. Także dba o pokrycie testami sytuacji brzegowych i wszelkich innych możliwych zachowań, które – wedle posiadanej wiedzy – mogłoby spowodować nieprawidłowe działanie systemu.
Działając zgodnie z metodyką Scrum – przypadki testowe tworzy się równolegle z oprogramowaniem, nie zaś po jego ukończeniu. Takie podejście znacznie przyspiesza proces wytwarzania. Pozwala na wyłapanie potencjalnych defektów jeszcze w trakcie samego projektowania testów, jako że wymagania mogą nie być zgodne z przedstawionym przypadkiem.
Ciągły rozwój, czyli od testów manualnych do automatycznych
Kolejnym krokiem po zdefiniowaniu przypadków testowych jest ich odpowiednia implementacja. Ta z kolei jest ściśle powiązana z poziomem zaawansowania projektu. A jak wiadomo – im dalej w las, tym więcej drzew. O ile do pierwszych testów wystarczające było przesłanie prostego zapytania HTTP do serwisu Restowego i odczytanie kodu odpowiedzi, tak wraz z rozwojem projektu pojawia się konieczność testowania funkcjonalności realizowanych na niższych poziomach modelu OSI (zwany też modelem odniesienia).
Przy realizacji testów pomocne okazywały się narzędzia takie jak Scapy. Jednakże umiejętność ręcznej budowy, wysłania, czy też odebrania ramki ethernetowej nie pozwalała na zasymulowanie właściwego działania testowanych mechanizmów w docelowej sieci. Takiej, w której komunikacja pomiędzy poszczególnymi ramkami odbywa się w ułamku sekundy. Niezależnie od ilości nakładu pracy ręcznej, nigdy nie będziemy w stanie odtworzyć takiej sytuacji wysyłając kolejne ramki manualnie.
Konieczne stało się zautomatyzowanie całego procesu. U nas pierwsze podejście oparliśmy na Robot framework. O ile przejrzysty oraz intuicyjny interfejs graficzny pozwalał na szybkie zapoznanie się z narzędziem, tak po niedługim czasie na wierzch wyszły problemy związane z nie do końca poprawnym działaniem bibliotek odpowiedzialnych za możliwość komunikacji w warstwie drugiej.
Kolejne batalie z nie do końca poprawnie zaimplementowanymi bibliotekami w narzędziu Robot skłoniły nasz zespół do porzucenia tego rozwiązania. Zamiast tego skupiliśmy się na pisaniu testów w języku Python wspomagając się przy tym frameworkiem Pytest. Rozwiązanie takie pozwoliło nam na zdecydowanie większy udział deweloperów przy recenzowaniu powstającego kodu testów jak i na samo tworzenie testów. W efekcie można śmiało stwierdzić, że wsparcie zespołu w trakcie – jak mogłoby się zdawać – żmudnego procesu wdrażania się w testy z wykorzystaniem Pythona wpłynęło na poprawę współpracy. Było też niezwykle pomocne i zaprocentowało dla wszystkich.
Research and development
Pisanie testów w projekcie SDNbox wiąże się z umiejętnym doborem narzędzi i technologii. Takich, które będą w stanie zasymulować pożądane działanie. Proces doboru konkretnego narzędzia wiąże się z koniecznością weryfikacji jego możliwości – zarówno pod kątem przyjętych założeń, jak i zgodności z panującymi standardami. Z uwagi na innowacyjny charakter projektu, niejednokrotnie ciężko nam było znaleźć gotowe narzędzie, które spełniałoby nasze oczekiwania.
Od czego zaczęliśmy? Proces doboru takiego narzędzia zaczyna się od wstępnego rozpoznania jego możliwości. Po nim następuje wykonanie prostego zadania, potwierdzającego jego użyteczność (tak zwane PoC – proof of concept). W zależności od wyników PoC dane rozwiązanie może zostać przyjęte i wdrożone w projekcie lub odrzucone. Wtedy proces zaczyna się od nowa. Często bywa, iż narzędzie spełnia wymagania wyłącznie częściowo. To powoduje konieczność wykonania dodatkowej implementacji w celu zaspokojenia wszystkich potrzeb projektowych.
Rozwój testera w projekcie SDNbox
Praca w projekcie R&D nie pozwala na stagnację. Rosnący poziom zaawansowania technicznego projektu wymaga od testerów ciągłego rozwoju, koniecznego do poprawnego zrozumienia problematyki realizowanego rozwiązania. Bez tego nie uda się przygotować testów, które będą w stanie to rozwiązanie sprawdzić.
Stały rozwój nie tyczy się jedynie specjalizacji, w której tester obecnie się „obraca”. Doświadczeni specjaliści zajmujący się testowaniem czy programowaniem, mają możliwość poszerzania swoich kompetencji o wiedzę znajdującą się w zakresie specjalizacji innych działów. Jak? Poprzez branie udziału w chapterach oraz gildiach, co zgodnie z nomenklaturą modelu Spotify oznacza odpowiednio spotkania zrzeszające wszystkie osoby zajmujące się testowaniem oprogramowania w obrębie projektu, czy też całej firmy. To zaś stanowi korzyść zarówno dla nich samych, jak i całego projektu. Nic nie stoi więc na przeszkodzie, by tester posiadł wiedzę potrzebną, by efektywnie realizować zadania działu DevOps, czy zagłębić się w tajniki pracy Scrum Mastera.
