Radek Smilgin
Od czasów eksploracji nie było niczego świeżego i odkrywczego w testowaniu. Przez wiele lat trwaliśmy (i ciągle trwamy) w dogmatach, że programista nie może testować ze względu na brak umiejętności i właściwego podejścia, a tester nie może programować, bo traci swój unikalny punkt widzenia. Skutecznie zbudowaliśmy sobie silosy i w konsekwencji stworzyliśmy hybrydę testera i programisty - testera automatyzującego, który (zbyt często) ani nie potrafi testować, ani programować. Jakim cudem największy zachwyt naszego świata wzbudzają ludzie automatyzujący testy na interfejsie GUI? skoro jest to najdroższa, najtrudniejsza w utrzymaniu, najmniej efektywna czasowo metoda kontroli jakości, to dlaczego to promujemy? Wszyscy oszukują tu wszystkich. Mami się zamawiających software klientów mówiąc, że to coś zastępuje testerów. Testerów, którym mówi się, że to forma rozwoju i możliwość podbicia swojego statusu zawodowego. Programistów, że automatyzacja się opłaca i dzięki niej dostawy są lepsze.
Testowanie oprogramowania od 20-stu lat tkwi w tym samym miejscu.
Wszystkie poważne innowacje, nowe koncepcje redefiniowania kontroli jakości przychodzą do nas z zewnątrz. Siłą napędową zmiany nie jest tu środowisko testerskie, a wytwórcze. Monitorowanie, skuteczna analiza statyczna, testy A/B, testy kontraktowe - to wszystko rzeczy, które pojawiły się kiedy ktoś zaczął uświadamiać sobie, że tradycyjne testowanie jest zbyt kosztowne i nieefektywne. Przez te nowinki nasza dziedzina kurczy się niemiłosiernie na rzecz coraz lepszego ogólnego kontrolowania jakości. Ważniejsza od roli testera stała się sama czynność testowania, którą paradoksalnie łatwiej dziś przekazać innym rolom. Odpowiedzialność za weryfikację jakości coraz częściej i do tego coraz skuteczniej deleguje się programistom, specjalistom devops i użytkownikom. czy my naprawdę nie mamy nic do zaproponowania światu IT? czy musimy być jedynie obserwatorami tego jak Agile czy DevOps próbuje wyeliminować naszą rolę? Co bardziej rozgarnięci testerzy już rozpoczęli eksodus do programowania albo innych ról projektowych. Dostrzegają, że trwanie w obecnym stanie rzeczy jest skazaniem się na monotonię tradycyjnego testowania. a testy nie muszą już wymagać dużej uwagi, skrajnej dokładności i niespotykanej cierpliwości. Nie muszą być nudne i powtarzalne. Mogą być wymagające, ale w ciekawy sposób. Przypadki testowe można zamienić na monitory, skrypty z Selenium zmienić w test interfejsów programowalnych, a testy regresji zastąpić świadomością zmian budowaną przez przemyślaną analizą statyczną.
Testowanie oprogramowania od 20-stu lat tkwi w tym samym miejscu. Przez artykułowanie, że „testowanie takie łatwe i każdy może testować” sami deprecjonujemy naszą pracę. Często jedyne co możemy zaproponować projektom to umiejętność pisania i uruchamiania przypadków i skryptów testowych. to może działało w ubiegłym wieku. Dziś to już zdecydowanie za mało.
Obecny stan testowania to głęboka defensywa i bierna obserwacja zmieniającego się na naszych oczach świata IT.
Zamiast stać się siłą napędową zmian w kontroli jakości lub choć współuczestniczyć w zmianach, pozwalamy redukować testowanie, sprowadzając je do kategorii niepotrzebnej konieczności. zamiast sprzeciwiać się "testerom automatycznym" krótkowzrocznie staramy się nimi zostać.
Obecny stan testowania to głęboka defensywa i bierna obserwacja zmieniającego się na naszych oczach świata IT.
Motywacją do napisania tego wpisu są przemyślenia po rozmowie z Kamilą i Wojtkiem (państwem Gawrońskich), która została nagrana jako podcast późnym i zimnym wieczorem 23 listopada 2019.
