Jest piątek, godzina 14:00. Właśnie dzwonił dobry kumpel i ustawiliście się na grilla. Dziś wieczorem. Będzie piwko, będzie chill, który po tygodniu pracy się przecież należy.
Ale na razie trzeba zejść na ziemię. Do 16:00 jeszcze dwie godziny, więc trzeba coś dokodzić. Jest nowy temat na tapecie, więc póki co to bardziej rozeznanie tematu. W końcu dziś rano skończyłeś bug-ticket, który trzeba będzie wdrożyć. Kiedyś. Przecież nie dzisiaj, resort QA pewnie jeszcze nie zdążył przetestować wszystkich “edż kejsów”.
Najważniejsze, że poprawka szybko dodana, a dwa nowe unit testy napisane po implementacji przechodzą. Można zająć się czymś innym.
No i taka sielanka mogła trwać już do końca dnia. Mogło być fajnie, gdyby nie fakt, że właśnie wpadł lider, który jest naciskany ze strony biznesu. Twoja łatka musi wejść dzisiaj. Na weekend musi być to dostarczone, inaczej firma straci sporo kasy.
Wat?
No… Wieczorne piwerko i grill zaczynają się jakby oddalać.
Brak weryfikacji kodu jako przyspieszenie pracy
Historia ze wstępu być może jest fikcyjna, ale założe się, że przeżyłeś podobną sytuację albo zaobserwowałeś to zjawisko w Twoim zespole. Jako programiści często chcemy dostarczyć nowe zmiany tak szybko jak to możliwe. Z tego powodu pomijany jest element, który można łatwo usunąć z procesu, a jednocześnie pozornie przyspiesza pracę – weryfikacja własnych zmian w kodzie.
Nie mówię tutaj o braku unit testów, bo te będa musiały zostać dopisane jeśli w zespole macie taką zasadę i prowadzicie proces Code Review – ktoś na pewno się do tego przyczepi. Nie da się jednak zweryfikować np. podczas CR czy faktycznie przetestowałeś to co dodajesz.
Dlatego podczas codziennej pracy, w momencie kiedy mój kod ma lądować w repozytorium na głównym branchu stawiam sobie istotne pytanie…
Czy jesteś pewien swoich zmian?
Nasza praca jako programistów w dużej mierze polega na modyfikowaniu istniejącego już kodu – czy to dodawania nowych rzeczy, poprawiania błędów czy zmienianiu istniejącej logiki. Za każdym razem istnieje ryzyko, że poprawiając jedną rzecz wprowadzony zostanie jakiś błąd.
Można ufać istniejącym testom automatycznym (zarówno jednostkowym jak i integracyjnym czy e2e), ale czy nie wydaje Ci się, że weryfikacja manualna wszystkich kryteriów akceptacji dla nowej rzeczy powie znacznie więcej? Kiedy odpalisz aplikację i sprawdzisz namacalnie to co dodałeś, dzięki temu masz okazję “lepiej poczuć” działanie tego elementu i potwierdzić czy to faktycznie ma sens i działa jak należy.
Jakiego podejścia nie praktykować?
Zauważyłem, że często pojawiają się podobne wymówki i podejście do pracy aby uniknąć testowania swoich zmian. Tak jakby zapomniano, że jeśli nie testowałeś danego fragmentu aplikacji to zwalnia Cię to od ewentualnej odpowiedzialności.
Spójrzmy więc jak to zwyczajowo wygląda…
“Zrobiłem, a teraz QA musi to zweryfikować… To ich robota!”
Bardzo często spotykam się z przeświadczeniem, że jeśli w zespołach developerskich są takie osoby jak testerzy/QA to odpowiedzialność za weryfikowanie poprawności działania aplikacji spada na nich.
Dochodzi do sytuacji, że programiści “produkują kod”, dopiszą testy, sprawdzą czy się kompiluje i aplikacja uruchamia, a weryfikację czy spełnione są kryteria aplikacji i wykrycie błędów spada już w całości na testerów.
Szybszy development bo dwie osoby nie robią tego samego? Nic bardziej mylnego… Ostatecznie dochodzi do odbijania piłeczki od testera do developera.
Najpierw IN PROGRESS, później Code Review i w końcu Tests. Tam od razu tester trafia na jakiś błąd i odbija ticket na TO DO, programista wprowadza poprawki, następne Code Review i kolejne testy. Pierwotny błąd naprawiony, ale teraz wyszły 2 inne rzeczy. I cykl zaczyna się od nowa.
W międzyczasie developer zaczął pracę nad innym zadaniem i teraz musi ciągle zmieniać kontekst między nowym zadaniem, a tym, który wciąż wymaga poprawek.
No i kto jest wtedy winien? No oczywiście tester bo znalazł skrzętnie ukrytego babola i spowalnia cały proces 😉
“Jest OK, ale popraw jedną rzecz wspomnianą w komentarzu”
Nie wiem jak jest u Ciebie, ale zauważyłem już, że pozornie błahe sprawy, które często wychodzą podczas CR do poprawy “na kolanie”, jedne z tych co nie trzeba testować bo jest za pięć dwunasta do merdżowania i przecież ta kosmetyczna poprawka nie może spowodować żadnego błędu – akurat mają tendencję do rozwala działanie aplikacji w krytycznym momencie.
Dlatego zmuszam się, nawet przy najmniejszej zmianie w kodzie do odpalenia aplikacji i zweryfikowania czy nic się nie wysypuje. Tak, słowo “zmuszam się” jest tutaj adekwatne bo niejednokrotnie presja czasu i chęć pójścia na łatwiznę jest bardzo silna. Ale pewnie wiesz o co chodzi.
“Tej małej pierdoły na pewno nikt nie zauważy… Teraz nie ma czasu”
Widzisz błąd, który pojawia się czasami, ale nie wiesz dokładnie w jakim momencie. Na debugowanie i śledzenie nie ma teraz czasu. Puścisz to dalej – jeśli tester na to wpadnie to trzeba będzie poprawić. Jak nic nie znajdzie nie to znaczy, że wszystko działa.
Do momentu aż ten kod trafi na produkcję i się wysypie w najważniejszym momencie dla firmy.
Nigdy tego nie rób! Jeśli podczas developmentu trafiłeś na jakiegoś buga, ale nie masz czasu na jego poprawienie w danym momencie, lub nie potrafisz go szybko zreprodukować to nie ukrywaj go przed zespołem! Poproś kogoś o pomoc aby wspólnie go wytropić lub ocenić ryzyko pojawienia się problemów na produkcji. Zespół musi być świadomy ryzyka.
Minimalizuj ilość błędów!
Staraj się aby efekty Twojej pracy były pozbawione błędów. Nie chodzi mi o to, że masz być nieomylny bo idealni ludzie nie istnieją. Warto jednak robić wszystko żeby te błędy zminimalizować tak jak się da. A jednym z lepszych sposobów jest po prostu weryfikowanie swoich zmian zanim zaczną robić to inni.
Takie podejście pozwoli zaoszczędzić sporo czasu i pieniędzy. Pozornie może się wydawać, że odpuszczenie etapu weryfikacji jest ekonomiczniejszy, tym bardziej jeśli mamy “testerów” w zespole. Po czasie jednak zauważysz, że czas poświęcony na przełączanie się między kontekstem kiedy pracujesz nad innym już zadaniem, a w międzyczasie QA cyklicznie do Ciebie wraca z problemami w poprzednim zadaniu jest większy.
