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, jego instalacji na wskazanym środowisku 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 równolegle 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 niekończąca się „ewaluacja” wielu rozwiązań, a testy wciąż wykonuje się ręcznie.

Dążenie do znalezienia 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.

Liczni testerzy oraz architekci prawie na pewno stwierdzą, że najpierw trzeba zbudować kompletny zestaw narzędzi (wspomniany powyżej framework), a to wymaga czasu. Jeśli owego frameworku nie zrobi się na początku (chciałoby się powiedzieć: raz-a-dobrze), potem nie będzie na to czasu, bo interesariusze czekają 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 – na razie – 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 dostosowywania narzędzi do zmieniających się potrzeb. Nie ma bowiem żadnego powodu, by framework nie mógł być rozwijany w taki sam sposób, jak produkt, który się nim testuje (iteracyjnie i przyrostowo).

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

Wcześniej czy później organizacja zrozumie, że wszechmogący 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 interesariusze naciskają na szybkie wydanie.

Dużo lepszym rozwiązaniem jest wykorzystanie kompetencji, jakie już w Zespole są. Trzeba 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 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ę kodować i 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ół do spraw automatyzacji” na pewno będzie chciał używać jednego uniwersalnego 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 „automatyzatorzy” kiepsko znają produkt, jaki testują. Dostają gotowe scenariusze, więc głębsza wiedza o działaniu rozwiązania 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ę testować. Sukces murowany, czyż nie?

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ć w ten sposób jakości, a jedynie ją sprawdzić. Jeśliby podjąć się automatyzacji tego testu na etapie, gdy testowana funkcjonalność jest wciąż jeszcze tworzona, „automatyzator” musiałby być jednocześnie Developerem produktu – a przecież właśnie po to powstaje dedykowany Zespół ekspertów od automatyzacji, by tego uniknąć.

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 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ół.