Blog

Presja na częste wydawanie nowych wersji produktów powoduje, że wykładniczo rośnie ilość testów niezbędnych do stwierdzenia, czy zmiany w najnowszym wydaniu nie psują wcześniej wytworzonych funkcjonalności. Testowanie nie oznacza bowiem jedynie sprawdzenia, że nowe rzeczy działają jak powinny, ale też zweryfikowania, czy produkt jako całość wciąż nadaje się do użytku.

W miarę rozwoju produktu przybywa w nim funkcjonalności lub cech, które mogą od siebie w różny sposób zależeć. To powoduje wykładniczy wzrost ilości niezbędnych testów, które trzeba wykonywać często i w sposób powtarzalny. Dla żadnego produktu, który ma więcej niż kilka funkcji, nie da się tego osiągnąć testując manualnie – konieczne jest zbudowanie mechanizmów ciągłej integracji (ang. Continuous Integration), a te wymagają automatyzacji testów.

Wiele organizacji chce wydawać produkty często, a jednocześnie od lat zmaga się z szybką integracją i testowaniem produktów. Continuous Integration, o ile w ogóle ma tam miejsce, sprowadza się do automatycznego kompilowania kodu, wdrożenia na wskazane środowisko i – jak dobrze pójdzie – podstawowych testów na poziomie kodu (np. testów jednostkowych). Dlaczego nie udaje się zrobić więcej?

1. Musimy używać standardowego / jednego narzędzia

W dużych organizacjach najczęściej rozwijanych jest jednocześnie wiele produktów, odpowiadających na różne potrzeby. Różnią się one funkcjonalnościami, oczekiwanym poziomem jakości lub wydajności, technologią, sposobem wykorzystania. Całkiem często są one testowane ręcznie wyłącznie dlatego, że trwają poszukiwania jednego narzędzia, które pozwoli efektywnie zautomatyzować wszystkie testy. Jest to jeden z objawów utopijnego dążenia do unifikacji w dużych firmach: jeden proces, jedno narzędzie, jeden model funkcjonowania… Najczęściej wychodzi z tego tylko jedna katastrofa, bo trwa nieustanna „ewaluacja” wielu rozwiązań, a testy wciąż wykonuje się ręcznie.

Poszukiwanie na siłę jednego rozwiązania jest poszukiwaniem kwiatu paproci i warto rozważyć, czy produkty technologicznie lub funkcjonalnie różne nie powinny być testowane przy użyciu narzędzi pasujących do ich specyfiki.

2. Musimy mieć kompletny „framework testowy”

Niektórzy zaszli nieco dalej i zrozumieli, że unifikacja nie ma sensu. Już wiadomo, że można poszukać dobrego narzędzia i go użyć, niekoniecznie oglądając się na to, czego użyją inni. Niestety, wcale nie oznacza to, że automatyzacja testów rusza z kopyta.

Testerzy oraz architekci prawie na pewno stwierdzą, że najpierw trzeba zbudować kompletny zestaw narzędzi (wspomniany w tytule sekcji „framework”), a to wymaga czasu. Jeśli owego „frameworku” nie zrobi się na początku (chciałoby się powiedzieć: raz-a-dobrze), to potem nie będzie na to czasu, bo biznes czeka na nowe funkcjonalności w produkcie… W efekcie nie dość, że nie ma automatyzacji, to jeszcze testerzy poświęcają sporo czasu na bezużyteczny – póki co – „framework”.

W istocie żaden „framework” stworzony w takim trybie nie przetrwa zderzenia z przyszłymi potrzebami. Zamiast tworzyć ciężkie i trudne w utrzymaniu rozwiązania, które „wszystko potrafią”, lepiej zapewnić zdolność szybkiego dostosowania narzędzi do zmieniających się potrzeb. Nie ma bowiem żadnego powodu, by „framework” nie mógł być rozwijany w takim samym modelu, jak produkt, który się nim testuje.

3. Musimy mieć narzędzie „dla testerów”

Wcześniej czy później organizacja zrozumie, że „framework” nie ma sensu i przejdzie do ewolucyjnego rozwoju niezbędnych narzędzi. Wydawać by się mogło, że dalej będzie już z górki… ale najczęściej nie jest.

Ponieważ panuje przekonanie, że testowaniem (w tym i automatyzacją) powinni zajmować się przede wszystkim testerzy, dobiorą oni narzędzia wedle swych preferencji i umiejętności. A potem bywa, że aplikacja tworzona w Javie testowana jest skryptami pisanymi w Pyhtonie lub wdrażane jest skomplikowane narzędzie, którego nikt (poza testerami) nie będzie w stanie użyć.

Powstaje w ten sposób silos otoczony fosą. Jak bowiem liczyć na pomoc ze strony całego zespołu, jeśli wymagać to będzie nauczenia się szybko nowej technologii lub obsługi „kombajnu” do testowania? „Narzędzia dla testerów” używać będą zatem tylko testerzy. Zdrowy rozsądek podpowiada, że wybór narzędzi do testowania powinien być wspólną decyzją zespołu, ponieważ to zespół jako całość buduje produkt.

4. „Nie wymagajmy od testerów umiejętności programowania”

Testerzy do tej pory wykonujący swą pracę manualnie, często nigdy nie kodowali ani nie pisali skryptów. A nawet jeśli robili to sporadycznie, ich umiejętności programistyczne są z reguły mocno ograniczone. Rzuca to automatyzacji kolejną kłodę pod nogi: potrzebne jest narzędzie do automatyzacji niewymagające kodowania.

W sukurs przychodzi przeogromny zbiór wszelkiego rodzaju okienkowych narzędzi, które pozwalają wyklikać poszczególne scenariusze testowe i manipulować danymi używanymi do ich wykonania. Z początku jest to fajne, wszyscy dobrze się bawią i automatyzacja rośnie jak na drożdżach… aż zatrzymuje się z hukiem, gdy nagle trzeba dokonać większych zmian w produkcie. Wtedy okazuje się, że wyklikanie tych zmian w narzędziu zajmie miesiące. Nie ma na to czasu, więc znów testujemy ręcznie, bo biznes naciska na szybkie wydanie.

Dużo lepszym rozwiązaniem jest wykorzystanie kompetencji, jakie już w zespole są. Potrzeba programować? Niech to robią ci, co potrafią, z pomocą tych, co wiedzą jak testować. W takiej wspólnej pracy zajdzie osmoza umiejętności: programiści będą lepiej rozumieć jak się testuje, nieprogramujący testerzy zaczną w końcu coś kodować…

5. Potrzeba ekspertów!

A czy aby nie lepiej zatrudnić ekspertów, którzy już potrafią automatyzować? Takie pytanie wiele organizacji zadaje sobie na tym etapie. Po co czekać, aż manualni testerzy nauczą się pisać skrypty? Po co zabierać programistom czas, który mógłby pójść na pisanie aplikacji, a jest „marnotrawiony” na implementowanie testów automatycznych?

W organizacji pojawiają się więc eksperci, którym manualni testerzy przekazują swe scenariusze do „oskryptowania”. Wydaje się, że przy okazji rozwiąże się wiele wcześniejszych problemów: taki „zespół automatyzacji” na pewno będzie chciał jednego narzędzia zamiast wielu, na pewno sobie ustandaryzuje sposób pracy… Same korzyści, nieprawdaż?

Niestety, zespoły tego typu są klasycznym silosem i to podwójnie szkodliwym, bo najczęściej „automatyzerzy” kiepsko znają produkt, jaki testują. Dostają gotowe scenariusze, więc głębsza wiedza jest im zbędna, a jakby coś było niejasne, zapytają o detale testera manualnego. W ten sposób ten, co nie umie automatyzować instruuje tego, który nie rozumie produktu, jak powinno się zaimplementować test.

Podejście to z definicji uniemożliwia zapewnienie jakości – automatyzujemy tylko testy regresyjne, czyli te, które już wykonaliśmy ręcznie i teraz chcemy je ciągle powtarzać. Dlaczego tak? Bo tester manualny, aby zdefiniować scenariusz w sposób pozwalający na jego „oskryptowanie”, musi wcześniej go wykonać ręcznie. A to oznacza, że test nie zostanie zautomatyzowany zanim to, co będzie weryfikował, nie zostanie napisane i ręcznie przetestowane, czyli już nie da się zapewnić jakości, a jedynie ją sprawdzić. Jeśliby podjąć się automatyzacji tego testu na etapie, gdy testowana funkcjonalność jest wciąż jeszcze tworzona, „automatyzer” musiałby być członkiem zespołu developerskiego – a przecież w modelu teamu ekspertów od automatyzacji tak nie jest.

Zatrudnianie ekspertów jest dobrym pomysłem, ale ich celem nie powinno być zrobienie automatyzacji na zlecenie testerów manualnych. Powinni pomagać zespołom w tym, aby efektywnie automatyzowały: ucząc je, doradzając im, coachując.

Ciąg dalszy nastąpi…

Z kolejnej części, która opublikowana zostanie już wkrótce, dowiecie się, dlaczego automatyzacja testów wciąż może się nie udać, mimo że – w końcu! – odpowiedzialność za nią weźmie cały zespół developerski.

Przeczytaj część drugą