Sytuacja kobiet w IT w 2024 roku
24.08.20204 min
Wojciech Laskowski
T-Mobile Polska S.A.

Wojciech LaskowskiChapter LeadT-Mobile Polska S.A.

Automatycznie czy klasycznie? O testach i agile słów kilka

Sprawdź, jak wyglądało wprowadzenie testów automatycznych i metodyki agile w firmie T-Mobile oraz jakie były tego następstwa.

Automatycznie czy klasycznie? O testach i agile słów kilka

Praca w Agile daje dużą swobodę w zakresie wprowadzania rozwiązań i narzędzi. Pomysł może zgłosić każdy, a developerzy często sami wprowadzają rozwiązania ułatwiające im życie – bez potrzeby wieloetapowej akceptacji, bez konieczności planowania budżetu na 3 lata wprzód. Dzięki Agile na żywo możemy weryfikować, co się sprawdza, a co trzeba odłożyć. Zazwyczaj taką swobodą cieszą się mniejsze firmy, startupy, organizacje działające w branży disruptive economy. Dziś, na prostym przykładzie uzupełnienia testów manualnych automatycznymi, opowiem Wam, jak Agile wprowadzone w T-Mobile pomaga nam odczuć to, że pracujemy w nowoczesnej firmie technologicznej. 

W tej historii istotne są dwa Tribe’y, utworzone w T-Mobile w ramach nowego, zwinnego rozdania – Tribe Prepaid, zajmujący się mówiąc ogólnie ofertami przedpłaconymi, oraz Tribe Innovation – pracujący nad – jak sama nazwa wskazuje – innowacjami. To po prostu takie nasze R&D. Istotne jest też to, że od pewnego czasu T-Mobile Polska odeszło od pracy w klasycznym dla wielkich telekomów, korporacyjnym stylu. Staliśmy się firmą technologiczną w prawdziwym tego słowa znaczeniu - a to jedna z historii o tym, jak nam się to udało. 

W drugiej połowie zeszłego roku, Agile Coach w Tribe Prepaid wyszedł z inicjatywą testów automatycznych, które miałaby zastąpić stosowane do tej pory testy manualne. Ich oczywistą wadą były trudności w środowiskach testowym – przerwy w ich działaniu, a także przedłużanie całego procesu budowania produktu, w naszym wypadku: nowych taryf czyli, jak by nie było, jednej z podstaw biznesu naszej firmy. W konsekwencji, testy wyłącznie manualne wydłużały wprowadzenie to nowego produktu na rynek i zwiększały ryzyko błędów

Z propozycją zwrócił się do mnie z racji mojego stanowiska – Chapter Leadera zajmującego się testami. Pierwszy skrypt napisaliśmy dosyć szybko, ale wciąż szukaliśmy technologii, która będzie miała największy sens – a dodatkowo, pozwoli nam szybko i łatwo wprowadzać automatyczne testy w innych projektach. Ostatecznie wybór padł na python + behave raportowane w allure ze względu na łatwość w nauce, prostą składnie, szybkość a także praktycznie nieograniczone możliwości. Początkowo robiłem to zresztą trochę hobbystycznie, często nawet uruchamiałem testy z własnego komputera, ale szybko okazało się, że potrzebuję dedykowanego miejsca tak, żeby testy automatyczne dostępne były dla większej liczby osób.  

Tak naprawdę cała sytuacja trwała kilka tygodni. W końcu – przy wspólnej pracy nad zupełnie innym projektem – zwróciłem uwagę na potrzebę takiego miejsca koledze z Tribe’u Innovation i w lutym 2020 roku, tuż przed wybuchem pandemii, udało się. Znalazł nam serwer i błyskawicznie uruchomiliśmy testy w chmurze. Dość powiedzieć, że przy zarządzaniu „wodospadowym”, czy też „kaskadowym”, typowym dla wielkich Korpo, na samo wyznaczenie miejsca pod takie - „niezamówione” przecież przez dział sprzedaży – usługi, w ogóle nie mielibyśmy czasu. Co ciekawe, tematem zaczęli interesować się sami inni testerzy, wkrótce mieliśmy już w firmie sporą grupę ewangelistów, którzy samodzielnie edukowali innych i promowali testy automatyczne w T-Mobile. 

Obecnie wdrażamy już testy BDD (Behavior Driven Development) i uczymy “Biznes” przygotowywania wymagań od razu w postaci skryptów. O tym, jak przyspiesza to wprowadzenie gotowego produktu na rynek, nie muszę chyba nikomu opowiadać. Zwiększyła się też współpraca developerów i testerów, pracujemy razem i na bieżąco widzimy, gdzie pojawiają się błędy, na nowo uczymy się działać razem. Czujemy jakbyśmy pracował w młodej, prężnej firmie – mając jednocześnie za sobą zasoby wielkiej korporacji. 

Oczywiście, to dopiero początek drogi. Docelowo chcielibyśmy, by stosunek testów automatycznych do manualnych wynosił 80:20, ale już teraz wszyscy, także działy biznesowe, widzą sens tego rozwiązania. 

Co dalej?

Dalsze kroki nasuwają się same. Już udało nam się zmienić całe podejście w firmie i zamierzamy wprowadzić automatyzację we wcześniejszych, a wymagających zmian produktach oraz we wszystkich nowopowstających. Będziemy dalej budować testy BDD, a dodatkowo centralizować automatyzację. Już teraz udało się wielokrotnie usprawnić proces wykrywania i szybkiej naprawy błędów w środowisku developerskim (DEV), zamiast – jak dotychczas budować całą paczkę na SIT. Nikomu, kto pracuje jako tester oprogramowania, nie muszę mówić, jak usprawnia to cały proces. 

Ryzyka

Czy testy automatyczne mają same zalety? Oczywiście, nie. Dlatego właśnie musimy zachować zdrowy dystans i nie rezygnujemy w T-Mobile całkowicie z testów manualnych. Przede wszystkim, ich wprowadzenie wymaga dużego zaangażowania i chęci do samorozwoju – skrypty testowe trzeba cały czas monitorować i usprawniać. Systemy, z których korzysta firma się zmieniają, zmieniają się też platformy. Dodatkowo, automatyzacja nie może nam zastąpić czynnika ludzkiego: idei, pomysłu. Narzędzie, takie jak np. automatyczne testy, nie jest magicznym remedium na błędy. Za każdym automatem stoją ludzie i to oni muszą tak „sprzedać” narzędzie w organizacji, żeby także osoby nietechniczne odczuły zalety z jego wprowadzenia. 

<p>Loading...</p>