Skoro programiści piszą testy, to po co nam testerzy?

Jest taka teza, która wraca w branżowych rozmowach regularnie, odkąd pamiętam: gdyby programiści porządnie pisali testy do własnego kodu, testerzy nie byliby potrzebni. Czasem pada wprost, czasem w wersji miękkiej – „u nas nie ma QA, bo mamy dobre pokrycie” – ale rdzeń jest ten sam: tester to koszt, który istnieje tylko dlatego, że programiści nie odrabiają swojej pracy domowej.

Patrzę na tę tezę z pozycji, która nie jest częsta: jestem programistą, testy piszę przed kodem, a testowania oprogramowania uczyłem się też formalnie – na studiach podyplomowych. Siedziałem po obu stronach tego sporu. I właśnie dlatego uważam, że ta teza jest błędna – nie trochę, tylko u samych podstaw. Ale po kolei, bo ona wcale nie brzmi głupio.

Dlaczego ta teza brzmi rozsądnie

Trzeba jej oddać sprawiedliwość: wyrosła z prawdziwej obserwacji. Przez lata spora część pracy testerów wyglądała tak, jak moje własne ręczne testowanie, tylko na etacie: przeklikać aplikację po każdym wydaniu, według listy kroków, i sprawdzić, czy nic się nie rozsypało. Regresja, wykonanie ręczne, powtarzalność.

I tę część automatyzacja naprawdę zjadła. Suita testów robi dziś w minuty to, na co zespół klikaczy potrzebował dni – powtarzalnie, bez znudzenia i bez przeoczeń wynikających ze zmęczenia. Kto widział, jak bramka w CI zatrzymuje zepsute wdrożenie, ten wie, że to nie jest teoria. Stąd już tylko krok do wniosku: skoro maszyna przejęła sprawdzanie, człowiek od sprawdzania jest zbędny.

Tyle że ten krok to błąd logiczny. Automatyzacja przejęła wykonywanie testów. A wykonywanie nigdy nie było istotą tego zawodu.

Argument pierwszy: moje testy testują moją wyobraźnię

W pierwszej części serii o testowaniu napisałem zdanie, które kładzie tę tezę na łopatki właściwie samodzielnie: test-first nie testuje wyobraźni. Jeśli o jakiejś ścieżce nie pomyślę, nie powstanie ani jej obsługa, ani jej test. Kod i test wychodzą z tej samej głowy – więc mają te same ślepe plamki. Ślepa plamka nie zniknie od tego, że spojrzę drugi raz; na tym polega bycie ślepą plamką.

To nie jest teoretyzowanie. Policzyłem swoje testy co do sztuki – jest ich w sumie prawie siedem tysięcy – i mimo to wiem, że nie wszystkie ścieżki i scenariusze mam obłożone. Nie dlatego, że mi się nie chciało. Dlatego, że nie przyszły mi do głowy. Autor testów może podnieść ich liczbę; nie może wyjść poza własną wyobraźnię. Do tego potrzebna jest druga wyobraźnia – niezależna, z innymi ślepymi plamkami. I to jest pierwsza rzecz, którą do zespołu wnosi tester.

Argument drugi: tester patrzy na aplikację inaczej niż programista

Druga rzecz jest subtelniejsza i ważniejsza. Programista patrzy na aplikację jak budowniczy: zna plan, wie, jak miało działać, i sprawdza, czy działa tak, jak zbudował. Nawet uczciwie testując, zadaje pytanie „czy to, co zrobiłem, robi to, co zamierzyłem?”. Do tego dochodzi zwykła ludzka skłonność: ja chcę, żeby mój kod działał. Podświadomie klikam tam, gdzie zadziała.

Tester zadaje inne pytanie: „co się stanie, jeśli…?”. Co, jeśli cofnę w połowie? Jeśli wkleję pół megabajta tekstu w pole imienia? Jeśli otworzę ten sam formularz w dwóch kartach i wyślę oba? Jeśli zerwie mi połączenie między krokiem trzecim a czwartym? Tester nie sprawdza planu budowniczego – sprawdza budynek, i to nie spacerując po nim, tylko próbując się dostać tam, gdzie nie prowadzi żaden korytarz. To nie jest gorsze albo lepsze spojrzenie od spojrzenia programisty. To jest inne spojrzenie, i właśnie w tej inności jest jego wartość: znajduje błędy w miejscach, w których budowniczy z definicji ich nie szuka.

Argument trzeci: to jest zawód z warsztatem, nie klikanie

I trzecia rzecz, o której wiem właśnie dzięki podyplomówce: testowanie oprogramowania ma własny, rozbudowany warsztat. Podział dziedziny wejść na klasy równoważności, żeby z nieskończonej liczby możliwych danych wybrać skończoną liczbę reprezentatywnych przypadków. Wartości brzegowe, bo błędy mieszkają na granicach – o czym pisałem przy pytest, nie wiedząc jeszcze wtedy, że powtarzam lekcję z zajęć. Tablice decyzyjne dla logiki biznesowej z wieloma warunkami. Testowanie eksploracyjne jako dyscyplina z kartami i celami sesji, nie chaotyczne klikanie.

Powiem szczerze: zanim się tego uczyłem, też myślałem, że testowanie to „klikanie plus sumienność”. Po studiach wiem dwie rzeczy. Po pierwsze – to jest inżynieria, z technikami projektowania przypadków, których większość programistów nigdy nie poznaje. Po drugie, i to jest bardziej bolesne: znam ten warsztat i mimo to na co dzień, jako programista, stosuję z niego ułamek. Bo mój zawód to budowanie, a projektowanie testów robię przy okazji. Tester robi to zawodowo, w pełnym wymiarze – i tak jak ja przez lata nie doceniałem różnicy między znajomością techniki a jej codziennym stosowaniem, tak ta teza nie docenia różnicy między pisaniem testów a testowaniem.

Co automatyzacja naprawdę zrobiła z tym zawodem

Wróćmy do obserwacji, z której teza wyrosła, bo ona zasługuje na uczciwe domknięcie. Automatyzacja nie zlikwidowała testowania – rozdzieliła wymyślanie sprawdzeń od ich wykonywania. Wykonywanie zabrała maszyna i bardzo dobrze: ręczny test jest zły tam, gdzie potrzebna jest powtarzalność. Ale ktoś nadal musi wymyślić, co sprawdzać – które scenariusze, które granice, które kombinacje. I ktoś powinien robić to, czego zautomatyzować się nie da: eksplorować, kwestionować wymagania, patrzeć na aplikację oczami użytkownika, który nie zna planu budowniczego.

Rola „testera-wykonawcy”, który dostaje skrypt kroków i klika go ósmy raz w tym tygodniu – ta rzeczywiście znika, i nie ma czego żałować, bo to była praca poniżej kwalifikacji ludzi, którzy ją wykonywali. Rola testera-projektanta i testera-eksploratora ma się dobrze. Zmienił się rozkład: mniej wykonywania, więcej myślenia.

Sekcja uczciwości: co się w tej tezie broni

Żeby nie było, że kładę tezę na łopatki i uciekam:

Programista ma pisać testy. Kropka. Nic z tego wpisu nie zwalnia mnie z własnej suity – tester nie jest siatką bezpieczeństwa pod niechlujstwo. Zespół, w którym programiści nie testują, „bo od tego jest QA”, ma problem głębszy niż brak etatu.
Nie każdy projekt potrzebuje testera. Ten blog nie ma QA i mieć nie będzie – ma testy pilnujące treści i kodu i to wystarcza, bo stawka jest niska, a użytkownik jeden. Rachunek zmienia się z rosnącą złożonością i ceną błędu.
Teza dobrze zabija jedną rzecz: ręczną regresję jako zawód. Jeśli ktoś rozumie ją wąsko – „nie potrzebujemy ludzi do ręcznego przeklikiwania listy kroków po każdym wydaniu” – to się z nią zgadzam. Tyle że to nie jest teza o testerach. To teza o powtarzalności, którą należało oddać maszynom.

Puenta

Cała pomyłka tej tezy mieści się w jednym słowie: traktuje „testy” i „testowanie” jak synonimy. Testy – te, które piszę ja, programista – strzegą tego, co przewidziałem. Testowanie – to, co wnosi tester – szuka tego, czego nie przewidziałem. Pierwsze bez drugiego zostawia ślepe plamki, drugie bez pierwszego tonie w regresji, którą powinna łapać maszyna.

Więc nie: nawet gdyby wszyscy programiści świata pisali testy tak sumiennie, jak każe teoria, testerzy nie staliby się zbędni. Straciliby najnudniejszą część swojej pracy – i dokładnie to się właśnie dzieje. Została ta część, której żadna suita nie zastąpi: druga wyobraźnia, patrząca na aplikację z miejsca, w którym budowniczy nie stoi nigdy.