QA

Automatyzuj przewidywalną część pracy. Zaoszczędzony czas poświęć na dogłębną analizę kodu

kobieta pracująca przy biurku

Rozpoczynając swoją karierę w IT na studiach, kursach czy ucząc się samodzielnie, często skupiamy się na programowaniu. Zdarza się, że do debugowania i analizy siadamy, dopiero gdy coś nie działa zgodnie z naszym oczekiwaniem lub pokazują się błędy. Gdy tworzymy program na potrzeby naszej nauki, brak testów nie jest wielkim wykroczeniem. Niestety w przypadku programów czy aplikacji pisanych komercyjnie samo to, że program zadziałał, nie jest wystarczające. Taki produkt, z którego później korzysta wielu użytkowników, musi zostać dobrze przetestowany na każdym z etapów życia produktu. Jak zorganizować proces testowania programu?

[Joanna] Pracę w firmie Ericsson zaczęłam od praktyk programistycznych w 2017 roku. Rzeczą, na którą zwróciłam uwagę, gdy dostałam pierwsze zadania programistyczne, był ogrom projektu, nad którym pracował mój dział, a to naprawdę był tylko jeden mały fragment tego, nad czym pracuje cała firma. Z perspektywy studenta zaliczającego praktyki i którego największy do tej pory projekt programistyczny trwał semestr i brało w nim udział zaledwie kilka osób, było to naprawdę coś dużego i zupełnie innego niż miałam okazję widzieć do tej pory. 

Projekt taki jak ten, rozwijany latami przez zespół rozproszony na całym świecie jest ogromny i naprawdę robi wrażenie. Zrozumienie sposobu, w jaki funkcjonuje taki projekt, wymaga czasu i pracy. Dlatego do poprawnego realizowania zadań nowy pracownik musi opanować cały flow produktu oraz to, co tak naprawdę testujemy i dlaczego. Jest to wiele specjalistycznych zagadnień z zakresu nie tylko programowania, ale także w przypadku naszej firmy wiedzy z zakresu telekomunikacji. Było to na tyle skomplikowane, że zajmujemy się testowaniem całego produktu, który trafia do naszych klientów, czyli dostawców usług telefonii komórkowej. 

Wymagało to zrozumienia licznych zależności i sposobu działania sieci komórkowej w różnych konfiguracjach, ponieważ bez tej wiedzy prawidłowe napisanie testów wymaganych w naszym obszarze byłoby bardzo trudne. Dodatkowo zawsze zmiany dodawane w kodzie muszą być dobrze przetestowane i spełniać wiele wymagań, zanim zostaną ostatecznie zaakceptowane. 

Z praktykanta stałam się pracownikiem i przez długi czas rozwijałam umiejętności, wiedzę i kwalifikacje. Przez kilka ostatnich lat zajmowałam się nie tylko programowaniem, ale i testowaniem. Przez ten czas wyszkoliłam kolejnych pracowników. Obecnie pracuję na stanowisku Senior Software Developera jako specjalista i zauważam wiele korzyści płynących z wiedzy zarówno z zakresu programowania, jak i testowania. 

Tester, który wie, w jaki sposób jest coś napisane, ma znaczenie większą świadomość tego, co i w jaki sposób działa. Dzięki temu może szybciej wyłapać błędy, luki w oprogramowaniu lub w testach, które przeprowadza. Tak samo działa to w drugą stronę, wiedząc w jaki sposób pracuje tester, programista może lepiej przewidzieć, zabezpieczyć i przetestować swój kod, zanim trafi on do użycia.

Przejście takiej ścieżki kariery od testera do developera lub odwrotnie daje nam większą świadomość całości procesu oraz pracy, która musi zostać wykonana, otwiera umysł. Dodatkowo zrozumienie tej “drugiej strony” pozwala na stworzenie lepszej atmosfery pracy podczas rozwoju oprogramowania, bo przecież tester to nie osoba, która wytyka błędy programiście. Wspólnie pracujemy nad tym, aby produkt końcowy miał jak najlepszą jakość, aby klient, który kupuje od nas oprogramowanie był zadowolony. 

Testowanie nie może być spychane na drugi plan

Odpowiednie przetestowanie oprogramowania i wczesne wykrycie jak największej ilości błędów jest kluczowe podczas pracy w duży projekcie. Tutaj istotną rolę pełni agilowe podejście do rozwoju oprogramowania, czyli programowanie w sposób iteracyjny, gdzie po powstaniu kolejnych funkcjonalności wykonywane są testy każdego z modułów oraz całego programu w celu wychwycenia błędów. Brak odpowiedniego przetestowania produktu na każdym z etapów powstawania oprogramowania może skutkować poważnymi konsekwencjami. 

Często staramy się przewidzieć każdy przypadek testowy, który powinniśmy przeanalizować i zaplanować dla niego odpowiednie testy. Mimo to nie powinniśmy powiedzieć, że kod nie zawiera żadnych błędów. Może się przecież okazać, że jakiegoś przypadku nie przewidzieliśmy, co skutkuje nieoczekiwanym zachowaniem u klienta, które musimy rozwiązać od strony programistycznej, poprawnie go przetestować i upewnić się, że taka sytuacja się nie powtórzy. Dzięki temu nie można powiedzieć, że praca testera jest nudna. Każdego dnia stajemy przed nowymi wyzwaniami i zazwyczaj każdy błąd czy problem, który napotkamy jest inny, wymaga dokładnej analizy przez wiele osób, które często pracują w różnych krajach na całym świecie. 

[Sebastian] Rangę testów w naszej pracy podnosi świadomość znaczenia i wpływu kodu, jaki tworzymy na nasze codzienne życie. Wielu z nas pracuje w firmach tworzących oprogramowanie mające wpływ na zdrowie i ludzkie życie. Nie zawsze jednak zdajemy sobie z tego sprawę. Nie mówimy tutaj jedynie o charakterystycznych systemach mających krytyczny wpływ na nasze życie, takich jak systemy infrastruktury lotniczej, kolejowej, oprogramowanie sprzętu medycznego czy chociażby wind przewożących miliardy pasażerów dziennie. Testy w oprogramowaniu, które na pierwszy rzut oka nie ma wpływu na powyższe czynniki, mogą jednak przy większej analizie zyskać na znaczeniu. 

Błędy w oprogramowaniu to błędy człowieka z przeszłości

Nieprawidłowo zaprogramowana nawigacja, czy aplikacja na telefon, która rozproszy nas w czasie jazdy, nie zawsze, lecz w konsekwencji może doprowadzić do wypadku. Błędne oprogramowanie laptopa, które zwiększa ryzyko zapłonu baterii, powoduje, że linie lotnicze nie pozwalają na ich przewóz w luku bagażowym. Zwróćcie uwagę, jak dużą dyskusję społeczną budzą samochody autonomiczne. Jak bardzo śledzimy każdy przypadek awarii i analizujemy czy był to błąd człowieka, czy oprogramowania. 

Tak naprawdę błąd oprogramowania jest błędem człowieka z przeszłości. Gdy zdamy sobie z tego sprawę, nasza praca nabiera poważnego znaczenia. 

Mogę z pełną stanowczością powiedzieć, że świadomość tego, jak bardzo ważna jest infrastruktura telekomunikacyjna i jej prawidłowe działanie, bardzo podnosi jakość testowania w moim zespole. Systemy komunikacji krytycznej, numer alarmowy 112 czy nasz pierwszy telefon do najbliższych w razie zagrożenia, zawsze opiera się o sieć telekomunikacyjną. Dlatego musi ona działać bez zarzutu. Tworząc ją skupiamy się na maksymalnych prędkościach, minimalnym opóźnieniu transmisji czy funkcjonalnościach. Jako użytkownicy chcemy z niej czerpać maksimum przyjemności. Jednak w sytuacjach kryzysowych zawsze będzie naszym filarem bezpieczeństwa, który “zawsze tam jest”. 

Gdy pracowałem przy projekcie w ericssonowym oddziale R&D w Kanadzie, któregoś dnia przy lunchu wywiązała się rozmowa na temat znaczenia naszej pracy. Po paru minutach, przy dużej argumentacji obu stron, jeden z moich kanadyjskich kolegów pokazał wszystkim żelazny pierścień, który miał na małym palcu swojej ręki. Taki pierścień dostaje każdy absolwent uczelni technicznej w Kanadzie. Ma on przypominać o znaczeniu i odpowiedzialności pracy inżyniera. Są one rozdawane od momentu tragicznego zawalenia się mostu w 1907. Wtedy przez zaniedbanie inżynierów runęła konstrukcja, powodując śmierć kilkudziesięciu robotników. 

Zaczynając codziennie swoją pracę, z kawą w ręku, wiem czego mogę spodziewać się po nadchodzącym dniu. Usiądę do sprawdzenia wyników testów, które uruchomione były w nocy. Sprawdzę środowisko testowe. Będę uczestniczył w spotkaniach o stałych godzinach. Jednak tak naprawdę w tej rutynie można znaleźć dużo miejsca na rzeczy, które będą pobudzały nasze zainteresowanie i oddalają nas od monotonii. 

Automatyzując przewidywalną i regularną część naszej pracy, która się do tego najbardziej nadaje, zyskujemy czas na poprawianie i ulepszanie naszego środowiska testowego. Właśnie w tym miejscu kończy się nudna praca testera. Mając okazję do głębokiej analizy błędów i przypadków nieprawidłowości oprogramowania nie tylko znajdujemy bezpośrednią przyczynę błędu, ale także zapobiegamy jego wystąpieniu w przyszłości. Tutaj każdy błąd jest inny, nowy i potrzebuje świeżego spojrzenia. 

Aby dokonać wnikliwej analizy niezbędne jest szerokie zrozumienie naszego środowiska. Czy wystąpienie błędu jest spowodowane ograniczeniami naszego środowiska, czy bugiem w oprogramowaniu? Gdy nie mamy pewności warto współpracować i kontaktować się zarówno z kolegami po fachu, jak i stroną, która pomoże nam poprawić ten błąd. Przecież wszystkim finalnie zależy na dobrym produkcie. 

Wielokrotnie w moim zespole analiza najbardziej złożonych przypadków wymagała zaangażowania testerów, developerów i klienta. Niejednokrotnie kończyła się wizytą na obszarze, który był dotknięty problemem. W takim wypadku nie ma mowy o nudzie! Należy jednak pamiętać, że błąd, choć wykryty, naprawiony i przetestowany jest dla nas lekcją. 

Wyciągamy z niej wnioski i rozszerzamy nasz zakres testów o ten konkretny przypadek. Dlatego przy dobrej organizacji współpracy wewnątrz jednej firmy testerzy mają pełne ręce roboty, programiści miejsce do wdrożenia swoich unowocześnień a klienci świadomość, że wybrali dobrego dostawcę oprogramowania.


Joanna Lubiatowska. Senior Software Developer w Ericsson. Absolwentka Informatyki na Politechnice Łódzkiej. Swoją karierę zaczęła od praktyk zawodowych na ostatnim roku studiów inżynierskich w firmie Ericsson w 2017 roku. Studia magisterskie ukończyła zaocznie, łącząc je z pracę zawodową. Obecnie członek zespołu testerskiego. Zajmuje się testowaniem oraz rozwojem oprogramowania przypadków testowych na potrzeby sieci 4G i 5G. Prywatnie pasjonatka gier planszowych oraz turystyki górskiej.”

Sebastian Szczesik. Testuje najnowsze rozwiązania telekomunikacyjne wprowadzane na całym świecie, w sieciach 4G i 5G. Praca stawia przed nim oraz jego zespołami testerskimi wiele wyzwań, uważa jednak, że to właśnie dzięki nim poznajemy nowe możliwości i kierunki działań. Po pracy nie ucieka od wyzwań, stawiają sobie nowe ambitne plany i cele. Przejawia wiele zainteresowań, od amerykańskiej motoryzacji, przez motocykle, historię działań wojennych regionu czy zgłębianie tajemnic kosmosu.

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

Redaktor naczelny w Just Geek IT

Od pięciu lat rozwija jeden z największych polskich portali contentowych dot. branży IT. Jest autorem formatu devdebat, w którym zderza opinie kilku ekspertów na temat wybranego zagadnienia. Od 10 lat pracuje zdalnie.

Podobne artykuły

[wpdevart_facebook_comment curent_url="https://geek.justjoin.it/automatyzuj-przewidywalna-czesc-pracy/" order_type="social" width="100%" count_of_comments="8" ]