Subiektywnie o przyszłości testowania

Subiektywnie o przyszłości testowania

Czym, że byłby zespół bez odrobiny sceptycznej istoty testera? Przez niektórych deweloperów postrzegany jako zło i zbędny, kosztowny dodatek zespołu – a przecież brakuje nam rąk do tworzenia nowego lepszego jutra… znaczy kodu. Zadajmy więc sobie takie oto filozoficzne pytanie: czy wiedzielibyśmy, że dobro to dobro, gdyby zła nie było? Bo nie któż inny jak Lucyfer tester, sprzeciwił się Deweloperowi świata… Ale może skończę moje filozofie testerskie i przejdę do testowania waszej wyobraźni, mówiąc subiektywnie o przyszłości testowania.

Na początku było manualnie

Od czasów pierwszego znalezionego „robaka” w roku 1947 aż do roku 1958 niewiele w testowaniu się działo. To właśnie w 1958 roku Gerald M. Weinberg założył pierwszy zespół testerski w amerykańskim projekcie Mercury, którego celem były loty załogowe w kosmos. I co możemy na ten temat powiedzieć z perspektywy ponad połowy wieku testowania? Że testy manualne są nieodłączną częścią procesu wytwarzania oprogramowania. I jak byśmy nie tupali, jak byśmy się spierali, że przecież można się bez niego obejść, to i tak wam się to nie uda.

Osobiście wielokrotnie złapałem się na tym, że bez testów penetracyjnych, przysłowiowego pobawienia się sprzętem, przepuściłbym super ciekawe błędy. Ciekawe – oczywiście z perspektywy testera i człowieka szukającego dziury w całym. Dla biznesu mógłby być druzgoczące… Ach te nieprzespane noce, pierwszych miesięcy bycia testerem z kłębiącymi się pytaniami: Czy na pewno sprawdziłem wszystkie możliwe scenariusze? Czy wykonana regresja była wystarczająco dogłębna? Czy stworzone TestSuit’y zapewniają sprawdzenie funkcjonalności na odpowiednim poziomie?

A potem przychodzi powolna znieczulica, na powtarzalność, na monotonie retest’ów i regresji. Kolejne funkcjonalności, projekty, urządzenia już tak nie cieszą. Sprawiają, iż jedni rzucają pracę, wyjeżdżając w podróże dookoła świata, otwierają food-tracki a drudzy zaczynają automatyzować testy.

Jestem robotem i robię w sobotę

A co gdyby tak ktoś/coś za nas wykonał to, co powtarzalne? A co gdyby praca wykonywała się nocami i weekendami? Ach, nie będę was trzymał w niepewności. Tak jest to możliwe ;). W roku 1985 pojawia się pierwsze narzędzie automatyzacji. Czy wiedziałem o tym fakcie przed pisaniem tego artykułu? Nie zdradzę. Narzędzie nazywało się Autotester i było napisane na system MS-DOS. Kto pamięta ten system, niech podniesie rękę :). Teraz nich podniosą ręce tylko osoby, które w swojej karierze zawodowej pracowały na tym systemie? Nikt? Branża testerska w Polsce jest tak niesamowicie młoda… 

Ale nie odbiegajmy od tematu głównego. Czyli testów automatycznych. Od roku 1985, powstało jeszcze kilka narzędzi wspomagające automatyzacje testów. Gdy już wybierzesz, jakiego używać (lub ktoś wybierze za Ciebie) i napiszesz kilka tysięcy pierwszych linii kodu, ochłoniesz z bliskości bycia deweloperem – przypomnij sobie te pierwsze nieprzespane noce jako tester manualny. Dlaczego? By nie zapomnieć, że nie jesteśmy deweloperami! Nasz wkład to nie nowy, kolejna funkcjonalność, a zapewnienie, że jakość produktu jest na wystarczającym poziomie dla naszego szefa/klienta. Co jednak będzie następnym krokiem w testowaniu? Gdzie doprowadzi nas ‚ewolucja’ automatyzacji?

Sztuczny tester automatyczny

Nie obawiajcie się drodzy testerzy. Wizje moje, choć nie tak szalone, jak mogłyby się wydawać, nie spowodują zniknięcia zawodu testera. Może przejdziemy swego rodzaju aktualizację. Ale będzie to krok taki sam jak między testami manualnymi, a automatycznymi. Także ten krok będzie zależny od samej specyfiki projektu i oczywiście pieniędzy.

Subiektywnie stawiam na uczenie maszynowe (eng. machine learning). Po pierwsze, przychodzi na niego coraz to większa moda. Choć brzmi to hipstersko, to moda może mieć w tym aspekcie swoje konsekwencje. Załóżmy, że posiadłeś magiczną wiedzę jak napisać automat do rozpoznawania obrazków (co z pomocą narzędzi do uczenia maszynowego jest bardzo proste), czy nie mógłbyś generować automatu do rozpoznawania błędów?

Uczenie maszynowe (bardzo upraszczając) polega na nakarmieniu naszego automatu dużą dawką danych, tak by wytworzył między nimi odpowiednie zależności do osiągnięcia założonego celu. Na przykład tworzymy bazę 500 zdjęć jabłek, przechodzimy do fazy uczenia automatu, „co to jest jabłko”, za pomocą tej bazy (proces uczenia jest najdłuższy z perspektywy wykonywanego kodu). Ostatnim krokiem jest pokazanie zdjęć, których automat nie zna (czy ja uczłowieczam takimi stwierdzeniami kawałek kodu?) i sprawdzenie, czy poprawnie rozpozna na nich jabłka lub ich brak.

Od jabłka do błędu

Czy od jabłek do błędów jest aż tak daleko? W sumie tak. Błędy dużo bardziej od siebie się różnią, ale przecież mamy jeszcze specyfikację i napisane wcześniej automaty (jeśli projekt jest na tyle dojrzały). Możemy zebrać testy, jakie dotąd napisaliśmy, skorelować je z istniejącą specyfikacją i z miejscami w kodzie gdzie występują największe ryzyka wystąpienia błędów i voilà, gdy dostajemy nową funkcjonalność lub nawet produkt, testy pisze za nas sztuczny tester automatyczny. Prawda, że proste?

Nawet jeśli moje proroctwa sprawdziłyby się, choć w części, to trzeba czymś ‚karmić’ automaty. Więc pracy nam jeszcze przez jakiś czas nie zabraknie, a wręcz może przybywać, by tworzyć takowe rozwiązania na potrzeby testowanych przez nas produktów.

Ten post ma jeden komentarz

  1. Mr T

    Z tym jabłkiem to liczyłem na analogię do Apple… 🙂

Dodaj komentarz