Każdego tygodnia wykonujemy 250 tys. testów. Jak wygląda praca testera w Ericsson

Dołączając do firmy Ericsson, byłem zaskoczony, gdy pierwszy raz zobaczyłem, jak krok po kroku wygląda proces testowania oprogramowania. Tygodniowo wykonujemy 250 tysięcy testów. Każda funkcjonalność (ang. feature) zgłoszona przez zespół lub klienta, testowana jest najpierw w godzinowych, codziennych, a później w cotygodniowych pętlach (ang. loopach). W tym artykule pokażę Wam, jak w Ericsson podchodzimy do testowania oprogramowania.

Rola testera oprogramowania i powstawanie produktu

Pracując nad rozwiązaniem jakiegoś problemu, za każdym razem musimy mieć na uwadze jedną informację: wszystko, co robimy, musi spełniać wymagania nadajników ulokowanych od USA po Koreę. Domyślasz się zatem, że tworzymy jednolite rozwiązania działające dla wszystkich operatorów, bez znaczenia, z jakiego kraju nadają.

Poniższa grafika przedstawia proces powstawania (ang. development) produktu w firmie Ericsson. Codziennie zespół składający się z pracowników w kilkudziesięciu oddziałach na świecie, pracuje nad kilkuset test case’ami.

Każdy zespół pracujący nad wprowadzeniem swoich usprawnień podpisany jest jako cross-functional team (XFT). Są to zespoły złożone ze specjalistów o różnych umiejętnościach. Wszystkie zmiany, które opracują w software, wrzucane są do jednej ścieżki projektu (ang. development track). Co godzinę testy automatyczne sprawdzają wprowadzone zmiany, robiąc to jednocześnie na różnych poziomach.

Gdy testy nie wykażą błędów, rozwiązania trafiają na koniec łańcucha testowego. Co dwa tygodnie zebrany zostaje zbiór nowych funkcjonalności, który na podstawie starego rozwiązania wydawany jest jako jedno oprogramowanie. Nową wersję software’u klienci mogą pobrać i rozpocząć testowanie na swoich obszarach testowych.

Źródła pochodzenia feature’ów

W Ericsson feature’y powstają z trzech “powodów”:

1. Jako Ericsson wprowadzamy rozwiązania zgodnie ze standardami 3GPP (to pewnego rodzaju “ciało standaryzacyjne”, które normuje, by każdy operator, producent telefonu, dostawca sprzętu bazował na tych samych wytycznych, wartościach, skrótach, protokołach itp.). Jeżeli w 3GPP ustalono wytyczne dotyczące np. prędkości, czy funkcjonalności, każdy z operatorów musi dostosować do nich swój software.
2. Klient zgłasza zapotrzebowanie na konkretne rozwiązanie.
3. Zespół przygotowuje rozwiązanie danego problemu, czy usprawnienie, które chce dodać do produktu, rozszerzając możliwości sieci operatora. Tu warto zaznaczyć, że to pewnego rodzaju wyróżnik naszej organizacji. Zespół, który wymyśli dane innowacyjne rozwiązanie, może starać się o uzyskanie na nie patentu. Gdy to się stanie, klienci z całego świata będą mogli skorzystać z licencji na daną funkcjonalność.

Co dzieje się dalej?

Jeśli zespół przeniesie swój pomysł na rozwiązanie na przysłowiowy “papier”, zabieramy się do pracy nad testami. W każdym przypadku dane oprogramowanie testujemy zgodnie z przedstawionym wyżej schematem, pracując nad nimi wspólnie w XFT. W momencie, gdy powstaje dana funkcjonalność, równolegle do niej od samego początku powstają także scenariusze testowe. Odpowiedzialnymi za ich napisanie są osoby wyznaczone w konkretnych zespołach XFT. Dzięki temu jednocześnie powstaje feature oraz środowisko testowe, które sprawdzi jego działanie.

Gdy feature przejdzie niskopoziomowe testy, zapada decyzja o tym, by dorzucić rozwiązanie do ścieżki danego projektu. Tych ścieżek jest kilka, natomiast skupmy się na głównej SW Main track, do której wpada feature. W jaki sposób dodajemy nasze rozwiązania? Dokonujemy tego niezależnie od pozostałych XFT, które pracują nad produktem. Dzięki temu nikt nie czeka, aż zespół A skończy pracę nad rozwiązaniem, by kolejny zespół – np. B – mógł dodać swoją część software’u.

Automatyzacja dalszej części procesu testowania

Od momentu zakończenia prac nad kodem, właściwie dalszy proces testowania jest w pełni zautomatyzowany. Zaczyna się od testów, które uruchamiane są zaraz po dostarczeniu kodu, czyli samo dostarczenie “swojej” części kodu uruchamia pierwsze testy modułowe.

To są krótkie testy, sprawdzające podstawowe funkcjonalności oraz to czy kod jest spójny w tym miejscu, w którym został dostarczony. Dzięki temu zespół szybko dowiaduje się, czy nowy kod odpowiednio integruje się z modułem, czy nie wpływa na inne funkcjonalności, uprzednio zaimplementowane w tym samym module.

Oferty pracy z

Jeśli testy nie przejdą, kod wraca do developera. Zespół pracuje nad poprawą, analizuje, dlaczego test nie przeszedł i naprawia błędy. Procedura testowa jest powtarzana – jeśli przechodzi dalej, moduł trafia na kolejny poziom, czyli do głębszej analizy, która odbywa się każdego dnia. Z testowania jednego modułu przechodzimy do sprawdzenia wpływu zmiany na kilka modułów. Nie ma tu jeszcze ostatecznego oprogramowania składającego się z wielu modułów, ale mamy znacznie większy wpływ takiej funkcjonalności i sprawdzamy ją po prostu w szerszym ujęciu.

Po testach na etapie modułów budowana jest jedna paczka oprogramowania. Zawiera ona kod wraz ze zmianami, które dotychczas pozytywnie przeszły proces testowania. Paczka oprogramowania z danego dnia przechodzi kolejne testy w obszarach jakościowych (ang. quality areas), odbywające się w ciągu tygodnia. Zaproponowane rozwiązania sprawdzane są w różnych quality areas, a dokładniej:

• capacity – sprawdza zdolność systemu do obsługi funkcji pojemności/obciążenia,
• functionality – testuje oprogramowanie (system) pod kątem poprawności działania zaimplementowanych funkcjonalności,
• overload – sprawdza zachowanie systemu na przeładowanie ilością ruchu sieciowego,
• performance – określa wydajność systemu pod względem osiągów funkcji i interakcji między nimi,
• robustness – sprawdza funkcjonalności pod kątem niezawodności i odporności na zakłócenia na nadajnikach, czyli restarty, przerywania symulowane, wprowadzanie zakłóceń sygnału itd.,
• security – sprawdza oprogramowanie pod kątem bezpieczeństwa,
• stability – zdolność systemu do działania w określonych tolerancjach podczas normalnej pracy przez długi czas,
• upgrade – sprawdza, jak system reaguje na wgranie nowej wersji software.

Droga od produkcji po wdrożenie

Po quality areas przychodzi czas na ocenę i zatwierdzenie zmienionego produktu. Co tydzień dedykowany zespół analizuje wszystkie informacje, które pojawiły się w czasie testów. Sprawdzane są wykryte błędy oraz to, czy mają one wpływ na całość oprogramowania. W zależności, od czego podejmowana jest decyzja dotycząca dołączenia funkcjonalności do końcowej paczki lub powrotu i naprawy na poziomie XFT.

Dla bardziej klarownego zobrazowania, jak ważny jest to etap, podam przykład. Załóżmy, że nasz feature przeszedł pozytywnie test na poziomie functionality, ale wypadł negatywnie na testach robustness. W tej sytuacji powyższy zespół odrzuca funkcjonalność i nie dodaje jej do najbliższej paczki z aktualizacjami dla klienta. Zdarzenie o negatywnym wyniku testu przynosi kolejną informację dla zespołu odpowiedzialnego za dany feature, który rozpoczyna pracę nad niezbędnymi poprawkami.

Pozostałe feature’y wchodzą do najbliższej paczki, którą zespół zbiera podczas serii spotkań. Co dwa tygodnie gromadzi on poprawne propozycje zmian w całość i przesyła klientom, którzy chcą przetestować software w swoim obszarze testowym. Informujemy ich, że co prawda nasza paczka przeszła poprawnie testy, ale nadal jest to świeże oprogramowanie, które może zawierać błędy. Dlatego nie zalecamy dodawać jej do całości systemów, ale przetestować na żywej sieci o niewielkim obszarze.

Miejsca te są pod naszą stałą opieką, wiemy dokładnie, który obszar może być narażony na oprogramowanie z błędami. Jeśli w ten sposób znajdziemy błąd, zabieramy się za ponowne testy, które przeprowadzamy na naszych nadajnikach.

Warto tu zaznaczyć, że pewnych zachowań użytkowników sieci, bez względu na liczbę urządzeń, niestety nie da się zasymulować w laboratorium. Dlatego bardzo pomaga nam współpraca z klientami, którzy na żywo testują nasze rozwiązania. Oczywiście w tym samym czasie sami dalej testujemy rozwiązania i analizujemy, co warto poprawić. Informacje z tych dwóch źródeł trafiają do zespołu XFT odpowiedzialnego za dany feature.

Podsumowanie

Dopiero po przedstawionym, wieloetapowym cyklu testowania produktu, raz na kwartał udostępniamy paczkę software’u gotową do wdrożenia w większej części sieci klienta.

Pomimo wielu testów, analiz i poprawek, finalny software nie jest wgrywany od razu w całej sieci. Proces ten następuje etapami i stopniowo trafia do coraz większego obszaru sieci klienckiej. W ten sposób uzyskujemy większą kontrolę nad ewentualnymi problemami, co pozwala szybciej reagować na wychwycone nieprawidłowości.

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