InPost in Test, czyli jak testujemy oprogramowanie

Odkąd tylko zacząłem pracować w InPost obserwuję pewien stereotyp. Poznając kogoś często słyszę pytanie, gdzie pracuję, a gdy odpowiadam, że w InPost to mój rozmówca zakłada, że jestem kurierem. Wydaje mi się, że wynika to z tego, że InPost nie jest postrzegany jako firma wytwarzająca oprogramowanie. Prawda jest taka, że zbudowaliśmy swoją przewagę rynkową właśnie na budowie unikalnych rozwiązań informatycznych.

Żeby działał cały proces biznesowy to wszystko: od włożenia paczki do skrytki, po otwarcie tej skrytki za pomocą aplikacji to właśnie my inżynierowie wcześniej musimy wszystko wymyślić i opracować, więc mamy naprawdę sporo na głowie. W tym artykule postaram się przybliżyć, jak wygląda nasze podejście do testowania w InPost oraz ogólne podejście do wytwarzania oprogramowania.

InPost, a Oprogramowanie

Zapewne większość z Was na hasło „oprogramowanie InPost” od razu przywołuje na myśl produkty takie jak Manager Przesyłek, Szybkie Nadania czy też aplikację mobilną. Nic w tym dziwnego, ponieważ są to nasze flagowe produkty, ale tak naprawdę reprezentują tylko front infrastruktury, w której mieści się wiele bardzo ciekawych systemów oraz zależności pomiędzy nimi.

W InPost rozwijamy architekturę mikroserwisów, a to znaczy, że każda z głównych aplikacji ma szereg powiązań z innymi, które odpowiadają za konkretne funkcjonalności. Jest to plątanina zależności, którą można śmiało porównać do latającego potwora spaghetti, z którym testerzy mierzą się na co dzień. InPost jest stosunkowo młodą firmą, która bardzo szybko urosła, a co za tym idzie nasz development musiał od początku być elastyczny i szybki w „dowożeniu” projektów. Nie zdziwi Was pewnie to, że na samym początku był chaos, z którego urodziło się to, co mamy teraz.

Zapewne wielu z Was pracowało kiedyś z klientami, którzy przychodzili wyłącznie z niejasnymi pomysłami dotyczącymi rozważań biznesowych i z wymaganiem dowiezienia swojego pomysłu na teraz. W dużym skrócie tak wyglądały początki w InPost. Uważam, że nie było w tym nic złego, ponieważ w miarę upływu czasu uczyliśmy się podejścia do wytwarzania oprogramowania, próbowaliśmy wielu rzeczy, aż w końcu wypracowaliśmy nasze własne, które na tę chwilę nam odpowiada, a co najważniejsze – sprawdza się. Lecz kto wie, co będzie za miesiąc, rok lub parę lat, jak sami wiecie nasza branża z minuty na minutę bardzo dynamicznie się zmienia i bardzo podobnie jest z samym InPost. A więc jak w tej chwili działa firma i jak podchodzimy do wytwarzania oprogramowania?

Wytwarzanie i testowanie oprogramowania

W projektowaniu i implementacji nowych rozwiązań korzystamy z hybrydy dwóch podejść jakimi są Domain-Driven Design (DDD) oraz Behavior Driven Development (BDD). BDD wywodzi się mocno z podejścia do samego testowania, jest to definiowanie scenariuszy testowych, które mają sprawdzać potrzebę biznesową na podstawie rozmów z klientem oraz ich wymagań. Stosuje się w nim konwencję pisania scenariuszy testowych w oparciu o trzy kroki: given, when, then. Reprezentują one cykl życia scenariusza testowego i tak given mówi nam o warunkach początkowych, które muszą zaistnieć, aby scenariusz można było wykonać, when o akcji, która wywołuje konkretne zdarzenie, natomiast then definiuje oczekiwany rezultat.

Np:

Given: Jestem na stronie do logowania

When: Wpisuję poprawną nazwę użytkownika i hasło w wymaganych polach

Then: Strona startowa jest widoczna

Domain Driven Design (DDD) to podejście do samego projektowania i implementacji rozwiązania. Jest to stricte programistyczny koncept. Polega on na zamodelowaniu domeny biznesowej, a następnie samego produktu tak, aby był on odzwierciedleniem tejże domeny. Głównym celem DDD jest zdefiniowanie wspólnego języka pomiędzy biznesem, a nami, inżynierami. Chodzi o to abyśmy wszyscy poprzez to samo nazewnictwo konkretnych procesów oraz składowych naszego systemu rozumieli dokładnie to samo. W dużym uproszczeniu, DDD dąży do spójności w projektowaniu rozwiązań z interpretacją potrzeby biznesowej naszego klienta.

Przy założeniu, że mamy jakiś konkretny model biznesowy np. sklep internetowy, nasza architektura ma go odwzorowywać. O Domain-Driven Design oraz Behavior Driven Development można by na spokojnie napisać dwa osobne artykuły, bo to bardzo obszerne tematy, dlatego też przejdę może do miejsca, gdzie te dwa podejścia się u nas zazębiają i funkcjonują w praktyce.

W InPost rozmowy z biznesem, na których definiujemy nasz wspólny język i budujemy wzajemne zrozumienie odbywają się na sesjach Event Stormingowych. Czym są sesje Event Stormingowe? Są to spotkania, w których uczestniczą osoby techniczne, czyli programiści testerzy, architekci, ale także, a raczej zwłaszcza, osoby z biznesu, czyli nasz klient, który zamawia konkretne oprogramowanie oraz przyszli użytkownicy omawianego rozwiązania. Definiujemy na nich procesy biznesowe, które mają być obsługiwane przez nasz, w tym momencie jeszcze hipotetyczny, system. Wynikową takich właśnie spotkań jest też definiowanie domen, wokół których projektujemy oraz implementujemy nasze rozwiązanie.

Nie będę tutaj wchodził w szczegóły tego, jak wygląda samo spotkanie, bo to też temat na co najmniej jeden artykuł, ale co jest dla nas w tej chwili ważne to to, że Event Storming rodzi nam kilka ważnych składowych w kontekście testowania naszego systemu. Są to aktorzy, komendy, zdarzenia oraz reguły.

Aktorzy są to dla nas typy użytkowników, komendy to akcje wykonywane przez aktorów, zdarzenia to wynikowe tychże akcji, a reguły to ogólnie przyjęte zasady, których wszyscy musimy się trzymać. Znając te cztery składowe jesteśmy w stanie bardzo łatwo konstruować scenariusze w konwencji given, when, then, czyli konwencji narzucanej nam właśnie przez podejście BDD, które mówi o zachowaniach systemu w kontekście wymagań biznesowych.

Scenario: Creating locker pass thru shipment with minimal data
 Given Insert minimal data for locker pass thru shipment
 When Create shipment with inserted data, default organization id and authorization token
 And Wait for payment of the shipment
 Then Check if standard shipment data are correct
 And Service is correct for inpost_locker_pass_thru shipment
 And Response status is 200

Dzięki takiemu podejściu już na tym etapie, przed choćby napisaniem linijki kodu na zasadzie testowania koncepcyjnego jesteśmy w stanie pokryć główne założenia biznesowe dotyczące naszego produktu. A gdy już przechodzimy do samej implementacji rozwiązania, to równocześnie z pracami wykonywanymi przez programistów w ramach zaprogramowania tych wymagań, automatyzujmy te scenariusze żeby później tylko kliknąć START i sprawdzić czy wszystko działa.

Oczywiście to nigdy nie jest tak, że te wymagania się nie zmieniają, ale dobrze przeprowadzone sesje Event Stormingowe gwarantują wzajemne zrozumienie pomiędzy nami, a biznesem. Dzięki temu główne wymagania zwykle się nie zmieniają, a my jako testerzy mamy większy komfort przy definiowaniu scenariuszy testowych. I tak właśnie wygląda nasz typowy workflow w przypadku wdrażania nowych produktów oraz testowania funkcjonalności naszych aplikacji. Ale czym jeszcze, jako testerzy, zajmujemy się w InPost?

Testy wydajnościowe

Do przeprowadzania testów wydajnościowych mamy dedykowany zespół, który sprawdza jak działa nasza infrastruktura oraz definiuje, które komponenty wymagają optymalizacji. Robimy to na osobnym, wydzielonym do tego środowisku, na którym symulujemy ruch produkcyjny, obciążamy konkretne komponenty, a następnie analizujemy wyniki. Wykorzystujemy do tego narzędzia zbudowane w oparciu o sztuczną inteligencję.

Z roku na rok przesyłek w naszej sieci jest coraz więcej, przez co jako dział budowy i rozwoju oprogramowania jesteśmy stawiani przed coraz większymi wyzwaniami związanymi z optymalizacją naszych rozwiązań. W 2018 roku w szczytowym momencie musieliśmy obsługiwać ruch zwiększony o 30% w stosunku do roku poprzedniego, w 2019 podobnie, natomiast już w 2020 ten wzrost wyniósł 36%. Nasza infrastruktura musi działać bez zarzutu i w każdej chwili być gotowa na obsłużenie coraz to większego natężenia. Na szczęście na straży wydajności stoimy my, testerzy oprogramowania.

Tester – człowiek orkiestra

Na koniec chciałbym napisać o tym jaka jest nasza rola w strukturach firmy. Nie skupiamy się tylko i wyłącznie na samym testowaniu. Gdybym miał określić rolę testerów w naszej organizacji to nazwałbym ich takimi Strażnikami Jakości. Poza podstawowymi obowiązkami, z którymi zapewne mierzymy się na co dzień, każdy z nas bierze czynny udział w etapach wytwarzania oprogramowania w firmie – od analizy po utrzymanie. Testerzy są angażowani w różnego rodzaju konsultacje dotyczące projektowania aplikacji, implementowania zmian czy też samych prezentacji dla biznesu. Wiąże się to z tym, że mamy bardzo kompleksową wiedzę, z której śmiało czerpią inne działy w firmie. Dobrze to widać w przypadkach, gdy musimy przeprowadzić przekrojowe testy naszej infrastruktury.

Dzieje się tak, gdy trafi nam się projekt, w którym klient wprost wymaga przeprowadzenia testów integracyjnych przy użyciu Paczkomatów. Zwykle sytuacje tego typu występują gdy projekt, który dowozimy dotyka wielu miejsc w infrastrukturze lub dotyczy jakiegoś kluczowego partnera. W takich sytuacjach zdarza się na koniec sprintu wylądować pod Paczkomatem, co sprawia, że doświadczamy szerszego spojrzenia na dostarczane przez nas funkcjonalności. W momencie gdy chcemy sprawdzić czy zmiana działa tak jak powinna, nie tylko przechodzimy scenariusze, w których symulujemy pracę kuriera. Na chwilę sami się nimi stajemy, aby sprawdzić czy konkretna przesyłka na pewno trafiła do konkretnej maszyny.

Pamiętam, kiedy pierwszy raz skorzystałem z Paczkomatu na potrzeby testów. Jako niedoświadczony tester rozpisałem cztery scenariusze przekrojowe, wygenerowałem paczki i gdy już przeszedłem cały proces logistyczny, wraz z dwoma kolegami z pracy zeszliśmy na „poligon” (tak nazywamy miejsce gdzie znajdują się Paczkomaty wykorzystywane do testów) po to, żeby odebrać wirtualną przesyłkę. Do tej pory pamiętam jak się na mnie patrzyli, gdy cieszyłem się jak dziecko klikając po panelu sterującym i otwierając skrytkę. Było to dla mnie coś niesamowitego, bo zdawałem sobie sprawę z tego jak długą drogę w całym rozwiązaniu ta przesyłka musiała przebyć, żeby na końcu dostał ją odbiorca.

Satysfakcja po wielu tygodniach pracy była wielka. Za każdym razem, gdy spotyka mnie jakaś chwila zwątpienia w moją pracę, przypominam sobie właśnie ten moment i dlaczego właściwie pracuję przy wytwarzaniu oprogramowania. Po to, by mieć wpływ na otaczający mnie świat. I tego właśnie na koniec Wam wszystkim życzę, wielu momentów satysfakcji oraz radości z Waszej pracy. Do zobaczenia pod Paczkomatem®.

Zdjęcie główne artykułu pochodzi z unsplash.com.