Blog

Wchodzę na pierwszy z brzegu portal z ogłoszeniami o pracę, radośnie wpisuję w wyszukiwarkę “Tester Oprogramowania”, przeglądam pierwsze 20 wyników – i co widzę? W co drugim ogłoszeniu o pracę na stanowisku testera oprogramowania automatyzacja testów jest jednym z wymagań, lub w najgorszym wypadku jako mile widziana umiejętność. (Pomijam fakt, że w drugiej połowie ogłoszeń od razu widać, że firma szuka taniej, klikającej siły roboczej, a stwierdzenia typu “doświadczenie w testowaniu mile widziane” nie są rzadkością).

Czy manualne testowanie odchodzi do lamusa?

Artykuły zatytułowane podobnie do tego znajdziecie w prasie branżowej na całym świecie. Wszyscy powoli dostrzegają, że informacja zwrotna z testowania manualnego dociera zbyt późno do programistów, przez co jest mało wartościowa – w przeciwieństwie do informacji jaką dają testy automatyczne. Automatyzacja testów w dobie zwinnych metod wytwarzania oprogramowanie jest niezaprzeczalnie podstawowym czynnikiem sukcesu wytwarzanych produktów.

Pozostaje jednak pytanie: czy to oznacza, że testowanie manualne zostanie wkrótce w całości zastąpione automatami?

Niewątpliwie testowanie jest kosztowne. Brak testowania może być jednak jeszcze bardziej kosztowny – to hasło, którym straszy się managerów i interesariuszy, gdy narzekają na koszty.

O ile dziesięć czy dwadzieścia lat temu nie było dobrych narzędzi do automatyzacji testów, a za te które były na rynku trzeba było słono zapłacić, o tyle dzisiaj koszty wytwarzania automatycznych skryptów testowych przy użyciu dostępnych (najczęściej darmowych i otwartych) bibliotek są niemalże niedostrzegalne w kontekście innych kosztów projektowych. Zautomatyzowanie powtarzalnych prac wykonywanych dotychczas przez testerów to tylko jedna z zalet automatyzacji. Dużo ważniejsze jest przyspieszenie informacji zwrotnej dostarczanej przez testy – to jest to, co teraz liczy się najbardziej. Zapomnijcie o terminach takich jak “faza stabilizacji”, “faza testów akceptacyjnych po fazie developmentu”, “faza analizy testów” – będziemy nimi straszyć nasze dzieci za parę lat…

Dzisiaj liczy się sprawne testowanie nowych funkcjonalności i ich dostarczanie jak najszybciej do klientów – najlepiej jedna po drugiej, od razu na produkcję. A regresja? Regresja jest powtarzalna i powinna być zautomatyzowana. Marnowanie czasu zdolnych, spostrzegawczych i niezwykle wartościowych pracowników jakimi są testerzy to marnotrawstwo, na które żaden rozsądny manager nie może sobie pozwolić!

Co? Nie wierzycie, że testerzy to “wartościowi pracownicy”? Spójrzcie na ilość ofert pracy na rynku i zapytajcie tych którzy rekrutują, jak trudno jest znaleźć naprawdę dobrego testera. To podnosi Waszą wartość na rynku oraz w ramach Waszej organizacji.

Ale wróćmy do pytania: czy w takim razie zbliża się koniec testowania manualnego? Z pewnością zbliża się koniec manualnego testowania jakie wszyscy znaliśmy. Może jeszcze nie dzisiaj, może nie jutro, może nie w przeciągu najbliższych pięciu lat, ale wkrótce o rzeczach takich jak manualne testy regresyjne będą opowiadać na uniwersytetach – lecz niekoniecznie na kierunkach technicznych, a raczej na archeologii.

Czy to oznacza, że zastąpią nas maszyny? Ależ oczywiście, że nie! Testerzy ze swoim specyficznym, czasem wręcz destruktywnym podejściem do wytwarzanego oprogramowania byli, są i będą potrzebni. Niemniej jednak manualne testowanie albo raczej testowanie eksploracyjne to tylko jeden z wymiarów testowania współczesnych systemów.

Hurra! Automatyzujmy testy na potęgę!

Pomimo tego, że testy automatyczne stają się coraz bardziej powszechne, wiele organizacji nadal popełnia podstawowe błędy przy ich implementacji. Błędy, które wynikają najczęściej z braku wiedzy nie tylko o samych technikach i narzędziach automatyzacji testów, ale także o możliwych do osiągnięcia korzyściach biznesowych wynikających z testów automatycznych.

Jednym z najczęściej popełnianych błędów jaki miałem okazję obserwować w wielu organizacjach, była próba podejścia do Automatyzacji Testów jedynie w ramach działu testowego. Abstrahując od tego, że działy testowe to kolejna rzecz, która wraz z testowaniem manualnym odchodzi powoli do lamusa, takie podejście sprawia, że koszty automatyzacji zbyt często znacznie przewyższają korzyści z niej płynące. Jak już wspomniałem powyżej jedną z największych korzyści płynących z automatyzacji testów jest dostarczanie bardzo szybkiej i wartościowej informacji zwrotnej. Dostarczanie jej nie managerom testów, do których się raportuje, tylko bezpośrednio programistom! Automatyzacja testów i testowanie to odpowiedzialność całej organizacj, a nie wyłącznie działu testowego. Nie po to powstała piramida testów, by testować tylko na poziomie testów akceptacyjnych. Automatyzacja testów ma co najmniej trzy poziomy:

• Najważniejszy to oczywiście testy jednostkowe. To one są podstawą szybkiej informacji zwrotnej na temat tego czy oprogramowanie (nadal) działa.
• Kolejny poziom to testy funkcjonalne, integracyjne, itp. Te testy pokazują czy poszczególne komponenty/moduły oprogramowania działają w połączeniu ze sobą.
• Na samym końcu testy systemowe czy też akceptacyjne. Takie testy to sprawdzenie czy oprogramowanie nie tylko działa ale czy jest w stanie dostarczyć konkretną funkcjonalność biznesową.

Proporcje pomiędzy testami obrazuje piramida testów (patrz rys. 1).

Rys. 1: Piramida testów

Jakiś czas temu przeczytałem w jednym z postów na szanującym się portalu dla testerów (litościwie przemilczę nazwę), że automatyzacji testów nie powinno się zaczynać od rzeczy które są zmienne… Większej bzdury dawno nie widziałem! Przecież testowanie ma największą wartość właśnie wtedy, gdy możemy szybko i tanio dostarczyć informację o tym, czy wprowadzone przed chwilą zmiany niczego nie popsuły i czy są akceptowalne. Tak samo automatyzację testów powinniśmy zaczynać od tego, nad czym właśnie pracujemy i/lub tego na co wpływ mogą mieć wprowadzane właśnie zmiany. Wielokrotnie widziałem osobne projekty zatytułowane “Automatyzacja Testów” których celem było zautomatyzowanie dosłownie wszystkiego, bez zastanawiania się czy to w ogóle ma sens.

Jedną z poprawnych odpowiedzi na pytanie: “Kiedy należy zakończyć testowanie?” brzmi: wtedy, gdy skończy się nam czas przeznaczony na testy. Stąd właśnie wynika potrzeba sterowania testowania ryzykiem. Nie ma sensu testować rzeczy, które się nie zmieniają, gdyż prawdopodobieństwo, że pojawią się tam błędy jest raczej znikome (poza kilkoma wyjątkami w których architektura testowane systemu jest tak bardzo monolityczna i złożona, że nie jesteśmy w stanie wyodrębnić poszczególnych, względnie niezależnych modułów czy komponentów).

Oprócz testów automatycznych konieczne jest testowanie manualne, ale nie tak, jak to było robione dawniej – testowanie wszystkiego – tylko raczej testowanie eksploracyjne, które ma na celu odkrycie kolejnych obszarów, które warto by było zautomatyzować, lub wykrycie niedociągnięć których automaty nie są w stanie wykryć. Piramidę testów uzupełnioną o Testy Eksploracyjne pokazuje druga ilustracja (patrz rys. 2).

Rys. 2: Piramida testów uzupełniona o testy eksploracyjne

Automatyzujemy i co dalej?

Testy automatyczne w wielu organizacjach stają się celem samym w sobie, co z góry skazane jest na porażkę. Odpowiednie testy, wytworzone zgodnie z dobrymi praktykami oraz w odpowiednim czasie (w najgorszym wypadku równolegle z nową funkcjonalnością, a najlepiej przed implementacją funkcjonalności), dostarczają niesamowitej wartości całej organizacji.

Jeśli będziemy przestrzegać proporcji z piramidy testów, a do testów akceptacyjnych zaprzęgniemy dodatkowo którąś z powszechnych bibliotek, pozwalającą na zapisywanie testów w postaci normalnego tekstu (np. JBehave albo Cucumber), to nasze testy będą stanowić w zupełności wystarczającą dokumentację funkcjonalną i techniczną naszego produktu.

Taka dokumentacja ma tę potężną przewagę nad zwykłymi tonami dokumentów, że jest ciągle testowana poprzez wykonywanie testów, które się za nią kryją. Jeśli w testowanej aplikacji zostaną wprowadzone jakieś zmiany, nasze testy automatyczne szybko pokażą nam, że trzeba również zmienić dokumentację.

Aby wartość z testów automatycznych była jeszcze wyższa, testy powinny być uruchamiane jak najczęściej. Najlepiej przy każdej zmianie – stąd potrzeba stosowania praktyk Continuous Delivery. Wdrożenie takiego procesu otwiera drogę do dalszych, znacznie szerszych i jeszcze bardziej korzystnych z perspektywy biznesowej możliwości, ale to już temat na kolejne artykuły.

Wszystkich zainteresowanych tematyką testów automatycznych zapraszam na nasze najbliższe szkolenia z Automatyzacji Testów w Krakowie – więcej szczegółów na naszej stronie.