Opis testów w procesie wytwarzania systemu był jeszcze kilkanaście lat temu zamieszczany gdzieś na końcu listy. Dziś wygląda to inaczej, co korzystnie wpływa na jakość produktów, z których na co dzień korzystamy. Testy wykonuje się na wczesnym etapie wytwarzania oprogramowania, by jak najszybciej sprawdzić prawidłowe działanie poszczególnych funkcji.
Tak jest także w przypadku Ericsson, który pracuje w metodyce zespołów interdyscyplinarnych. – Dzięki niej każdy zespół, bez względu na to, nad jakim produktem pracuje, potrafi samodzielnie przygotować rozwiązanie od przysłowiowego A do Z – powiedział w rozmowie z nami Maciej Mroczek, Line Manager PDU Packet Core w Ericsson. Właśnie rozpoczął rekrutację do swojego zespołu, odpowiedzialnego m.in. za rozwój środowiska Automated Acceptance Test.
Czym jest środowisko Automated Acceptance Test?
AAT pozwala na przeprowadzanie testów akceptacyjnych, a te są ostatnimi testami wykonywanymi na produkcie. Ich celem jest sprawdzenie zgodności z wymaganiami klienta. Z narzędzia korzystają nasze zespoły, udostępniamy go także klientom, by mogli zweryfikować naszą pracę.
Środowisko AAT weryfikuje poprawność wykonania poprzednich etapów testowych?
Ująłbym to inaczej. Testy akceptacyjne to testy najwyższego poziomu i ich celem jest weryfikacja finalnych funkcjonalności. Wszystkie wcześniejsze testy są bardziej drobiazgowe. Nie zawsze zawierają jednak pełne scenariusze przypadków użycia. Dlatego wcześniejsze testy sprawdzają poszczególne klasy. Z kolei testy akceptacyjne mogą weryfikować całą sieć i sprawdzać, jak współpracują wszystkie jej elementy.
Prawdziwe będzie zatem stwierdzenie, iż scenariusze dla AAT powstają w trakcie realizacji produktu?
Środowisko to może mieć ograniczenia techniczne związane z wdrożeniem np. nowych protokołów. AAT, bez scenariuszy testowych, nie przeprowadzi samodzielnie testów. Z tego względu, środowisko to wymaga naszej ingerencji, modyfikacji i aktualizacji scenariuszy, które powstają równolegle do pracy nad danym projektem.
Jak wyglądała historia powstania tego środowiska?
Testy akceptacyjne – z perspektywy Klientów – dowodzą poprawności działania produktu. Wcześniej były wykonywane “ręcznie” przez odpowiednio wykwalifikowanych testerów. Zajmowały jednak dużo – były więc sporym kosztem. Zespół zwrócił wówczas uwagę na to, iż za każdym razem wykonywane scenariusze były podobne. Czy można sobie wyobrazić lepsze pole do wprowadzenia automatyzacji? Tak powstał pomysł na AAT.
Co ważne, Ci sami wysoko wykwalifikowani testerzy zajmują się dziś implementacją scenariuszy, które są później wielokrotnie używane zarówno przez nas, jak i naszych klientów. Zaoszczędzony w ten sposób czas możemy przeznaczyć na czynności, które nie są powtarzalne, np. na rozwój produktów czy na znajdowanie rozwiązań dla problemów Klientów.
Przejdźmy do samego procesu testowania, do Waszego podejścia to tego ważnego aspektu tworzenia oprogramowania. Jak w Ericsson wygląda praca zespołu testerów?
Każdy produkt, który przygotowujemy dla klienta, jest testowany na kilku poziomach. Sprawdzamy je m.in. pod kątem stabilności czy odporności (z ang. robustness). jeżeli chodzi z kolei o etapy testowania, to pierwsze są testy podstawowe (z ang. basic test), później funkcjonalne (z ang. function test). Następnie, w zależności od rodzaju produktu, możemy przypisać mu dedykowany zespół, który będzie wykonywał testy systemowe i akceptacyjne.
Nic nie stoi też na przeszkodzie, by zespół tworzący dane rozwiązanie był jednocześnie odpowiedzialny za przeprowadzenie finalnych testów. Poszczególne testy wymienione wcześniej dotyczą kolejno klas, funkcji, węzłów sieci i w końcu całej sieci. Z drugiej strony, zdarza się, iż niektóre z tych testów nie mogą być wykonane na tym poziomie. Potrzebujemy wówczas innego środowiska i innych kompetencji, dlatego zwykle wykonuje je inny zespół.
Interesuje mnie ta bliskość między testowaniem a procesem wytwarzania oprogramowania. Wydaje mi się, iż kilka lat temu nie było standardem to, iż zespoły testerów pracują wraz z programistami.
To zasługa koncepcji zespołów interdyscyplinarnych (z ang. cross-functional teams). Dzięki niej każdy zespół, bez względu na to, nad jakim produktem pracuje, potrafi samodzielnie przygotować rozwiązanie od przysłowiowego A do Z. Do zadań takiego zespołu należy przygotowanie analizy wymagań, zaprogramowanie, przetestowanie i zintegrowanie zmiany z finalnym środowiskiem.
Jak rozumiem zmierzacie zatem do tego, by zespoły odpowiedzialne za wytwarzanie systemu były także odpowiedzialne za przetestowanie go?
Tak, dzięki temu każdy, kto pracował nad wybranym fragmentu kodu, zobaczy, jaki miał wpływ na ostateczny kształt produktu.
Co jest cechą kluczową członka zespołu pracującego w zespołach interdyscyplinarnych?
Staramy się, by wszyscy członkowie zespołu mieli zestaw umiejętności w kształcie litery T. Każdy z nich powinien potrafić pracować nad dowolnym etapem, nad budowaniem bądź też testowaniem danej funkcjonalności. To jest ta pozioma kreska w literze T. Z kolei pionowa to specjalizacja danego członka zespołu. Ludzie tworzą zespoły, dlatego zachęcamy do wspierania się umiejętnościami pozostałych członków.
W idealnym modelu każdy członek zespołu jest wszechstronny. W podstawowym stopniu dobrze funkcjonujący w tej metodyce zespół składa się z przynajmniej jednego technicznego lidera znającego doskonale produkt od strony architektury i implementacji. Kolejny powinien specjalizować się w testowaniu, znać funkcjonalności realizowane przez produkt. Oprócz tego taki zespół powinien także składać się z inżynierów zajmujących się tworzeniem danego rozwiązania.
Co trzeba zrobić, żeby to się zadziało? Żeby zespół rozwijał kompetencje, ale i potrafił korzystać z kompetencji współpracowników?
Spośród kandydatów trzeba przede wszystkim wyłonić odpowiednie osoby. Po ich zatrudnieniu, musimy pokazać korzyści płynące z tego podejścia. Jedną z nich jest to, iż każdy ze współpracowników może znaleźć obszar, w którym będzie chciał być ekspertem. Dla mnie jako lidera dbającego zarówno o produkt, jak i o zespoły nad nim pracujące, kluczowym zadaniem jest pokazanie innym, iż w ten sposób mogą się rozwijać zawodowo. Moja rola polega na wsparciu ich w realizacji ścieżek karier.
Co z odpowiedzialnością? To także istotny aspekt rozwoju?
Zdecydowanie. W naszej pracy ważne jest zrozumienie, iż usprawnienie, nad którym pracujemy, będzie wykorzystywane przez klienta do poszczególnej części jego biznesu. Zespół powinien czuć odpowiedzialność za produkt, za dostarczenie działającego rozwiązania. Istotne jest także to, iż rozwiązania dostarczamy klientom, z którymi współpracujemy wiele lat. Przekłada się to na zrozumienie ich potrzeb. Zespoły, które zrealizowały dla klienta projekt, znają szerszy kontekst jego działalności, dzięki temu łatwiej realizują kolejne zadania.
Rozmawialiśmy o ścieżce kariery, warto na koniec poruszyć wątek zachowania work-life balance. W jaki sposób Ericsson wspiera to podejście?
Myślę, iż samo środowisko pracy w Ericsson sprzyja zachowaniu balansu między pracą a życiem prywatnym. Wsłuchujemy się w potrzeby współpracowników, dbamy o to, by uczestniczyli w procesie decyzyjnym i mieli wpływ na to, jakie zadania wykonują. Stronimy od poleceń, od zakładania, iż jest do wykonania zadanie i narzucamy, w jaki sposób ma zostać ono zrealizowane. U nas zespół dostaje cel w postaci zaimplementowania nowej funkcjonalności, ale nie sugerujemy, w jaki sposób ma on zostać zrealizowany. Wsłuchujemy się w potrzeby ludzi, bo to dzięki nim tworzymy tak interesujące rozwiązania.
Maciej Mroczek. Line Manager PDU Packet Core w Ericsson. Kierownik liniowy z ponad 30-letnim doświadczeniem w projektowaniu systemu dla telekomunikacji. Pełnił większość ról technicznych, jakie występują w procesie produkcji oprogramowania, począwszy od programisty i testera, skończywszy na kierowniku projektu. Od 20 lat skupia się na budowaniu i prowadzeniu zespołów pracujących nad produktami Ericsson.
