Czy programista powinien testować swój kod?
Czy programista powinien testować swój kod? Pytanie wydaje się być tendencyjne i takie też jest. Gdyby to nie miało różnicy kto testuje kod – prawdopodobnie zawód „tester” nigdy by nie powstał. Często słyszałem inną wersję tego pytania „czy programista może testować swój kod?” – odpowiedź jest prosta, jasne, że może. Tak dzieje się w wielu firmach. Trudniej odpowiedzieć na pytanie „czy powinien…”? Dziś rozłożę ten temat na czynniki pierwsze.
Kolejnym bardzo ważnym pytaniem jest również kiedy kod powinien być testowany? Opisałem to lakonicznie w wpisie o R&D – jak przeprowadzić zmiany w projekcie. Programista piszący daną funkcjonalność ma jej wytyczne – opis jak ma działać. Z tego opisu układa się w głowie pewien „obraz” jak to ma wyglądać w praktyce – do tego obrazu osoba realizująca funkcjonalność dąży. Bardzo ważną rzeczą jest to, że bardzo rzadko zdarza się w opisie funkcjonalności opis przypadków błędów jakie trzeba obsłużyć. Naturalną rzeczą jest więc, że tych przypadków nie ma w obrazie, który programista uzna za ukończony.
Programista realizując dane zadanie, jako myśl przewodnią ma tzw. „happy path„. Jest to sytuacja, która wyświetla poprawny rezultat zrealizowanego kodu. Samo osiągnięcie happy path nie gwarantuje tego, że kod działa poprawnie – mogą istnieć inne argumenty, które nie zostaną poprawnie obsłużone. Ze względu na skomplikowanie obecnych aplikacji – można powiedzieć, że liczba argumentów jest nieskończona. Argumentem nie nazywam wyłącznie wartości, jakie przyjmuje funkcja – mam tutaj na myśli wszelkiego rodzaju zmienne serwerowe / systemowe, wartości globalne lub te dostarczone od zewnętrznych web services. Mnogość tych elementów powoduje, że nie jesteśmy w stanie w rozsądnym czasie przetestować 100% przypadków, które mogą wystąpić. Programista zazwyczaj bierze pod uwagę tylko argumenty, które dotyczą bezpośrednio jego zadania – jest ich mniej, ale zazwyczaj wciąż zbyt dużo by przetestować wszystkie przypadki. Tak jak pisałem w innym wpisie o tym, że kreatywność „boli” – programista prawdopodobnie nie weźmie wszystkich przypadków, a jedynie kilka oczywistych, które mu przyjdą na myśl. Na tych przypadkach będzie bazował przez cały czas realizacji zadania.
Kiedy programista uzna, że skończył zadanie? Najwcześniej po znalezieniu pierwszego happy path. W praktyce testuje się więcej przypadków by uzyskać poprawny wynik oraz kilka przypadków by sprawdzić czy kod prawidłowo obsługuje niepoprawne dane. Generalnie rzecz biorąc programista uznaje, że skończył wykonywać zadanie w momencie gdy ma więcej niż jeden happy path i brak pomysłów na dalszą weryfikację poprawności – „chyba działa”.
Tak jak wcześniej wspomniałem – programista weryfikuje czy kod został ukończony po tym, gdy skończą mu się pomysły na możliwe przypadku wykorzystania kodu – a te, które zna działają poprawnie. Patrząc więc obiektywnie programista nie wie ile błędów ma jego kod. Gdyby wiedział o tym, jakie konkretnie błędy ma jego kod – nie uznał by go za skończony. Pomijam tutaj przypadek gdy ktoś intencjonalnie oddaje pracę z błędami.
Co wnosi tester?
Jaka jest różnica w procesie myślowym testera i programisty? Żadna. Procesy te są takie same u każdego człowieka – osoba bardziej kreatywna będzie miała jedynie więcej pomysłów na przetestowanie scenariuszy, ale podobnie jak programista uzna, że skończył testy w momencie, kiedy będzie brak pomysłu na dalsze przypadki. Główną wartością jaką wnosi tester są kolejne przypadki do testów (te, których nie przetestował programista). Czym większa kreatywność i wyobraźnia tym lepiej dla naszej aplikacji.
Często zdarza się, że do projekty są tworzone scenariusze testowe. Są to ścieżki „click flow” z odpowiednimi warunkami, które mają opisane wyniki. Rola testera w tym przypadku polega na porównaniu rezultatów – czy są zgodne z oczekiwanymi. W takim przypadku „jakość” testów jest zrzucana na osobę, która przygotowywała scenariusze testowe (nie zawsze są to testerzy – czasami np analitycy lub kierownicy projektów). Dlatego ja osobiście jestem zwolennikiem dostarczania scenariuszy testowych testerom dopiero po ich „freestylowych testach”. „Freestylowe testy” – rozumiem to, że tester sam wymyśla scenariusze, które chce przetestować. Dzięki temu (że scenariusze dostarczymy później) ich kreatywność nie jest ograniczona i nie narzuca się sposobów myślenia. Główną zaletą takiego rozwiązania jest to, że może zdarzyć się, że programista wpadnie na dodatkowy przypadek, który obsłuży, być może tester na niego wpadnie i zgłosi błąd. Rozszerzamy swoje testy o dodatkowe przypadki testowe. Scenariusze testowe przygotowane np przez analityka w momencie analizy przedwykonawczej można potraktować jako zapewnienie „minimalnej jakości” – możemy założyć, że nasze oprogramowanie będzie działało tylko w tych przypadkach, a testerzy nie wykażą się kreatywnością – będą chcieli jedynie „odhaczyć” swoje zadanie.
Warto zaznaczyć, że osoba testująca nie musi być zatrudniona jako tester. Może to być inny programista, kierownik projektu lub ktokolwiek inny. Chodzi o to, by przetestować jak najwięcej procesów myślowych. Jeśli twoi testerzy nie są kreatywni – nie testują więcej scenariuszy niż te dostarczone z wymagań, jedyne co zyskujesz to optymalizację finansową projektu. Testerzy wtedy wykonują pracę wtórną, nie wnoszą nic „od siebie”. W większości przypadków testerzy zarabiają mniej niż programiści czy kierownicy projektów – taniej jest więc poświęcić ich czas na testowania aplikacji.
Kompetentni testerzy oprócz kreatywności wnoszą jeszcze jedną wartość – znajomość narzędzi automatyzujących testy. Dzięki temu mogą „przetestować” dużo więcej rzeczy, w krótszym czasie. Zyskujesz podwójnie.
Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯
Podsumowanie
Procesy myślowe u każdego są bardzo podobne. Czym więcej przetestowanych przypadków – tym testy mają wyższą jakość, a aplikacja finalnie mniej błędów. Nie jesteś w stanie przetestować wszystkich przypadków, a jedynie te najbardziej oczywiste. Kreatywność w tym przypadku jest słowem klucz. Możesz podwyższyć jakość testowania dostarczając scenariusze testowe do testerów po ich autorskich testach. Często wartością dodaną od testera jest znajomość narzędzi, które automatyzują testy oszczędzając czas – wtedy zyskujesz podwójnie.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
