#2: Drogi QA, dlaczego nie znalazłeś/aś tego błędu!?
Mija dzień po wydaniu, a ważny klient zgłasza błąd w aplikacji, na środowisku produkcyjnym. Alarmy, maile, pingi, komunikatory, smsy. Zespół rzuca wszystko i zaczyna pracować nad poprawką, po czym szybko wrzuca ją na produkcję. Operacja się udała, klient zadowolony, cały zespół odetchnął z ulgą. Później menadżerowie spotykają się z zarządem oraz osobami z zespołu, aby porozmawiać o takich rzeczach, jak "dlaczego" oraz "jak zminimalizować to w przyszłości".
Następnego dnia ktoś zwraca się do Ciebie i pyta... Dlaczego nie znalazłeś błędu? Postaram się rozebrać dziś to pytanie na czynniki pierwsze.
1. Quality Assurance odgrywają ważną, kluczową rolę w znajdywaniu błędów. Poprawnym jest stwierdzenie, że QA to nie testerzy, ale niepoprawnym jest stwierdzenie, że testowanie nie należy do obowiązków QA. Bo należy i odgrywa kluczową rolę w zapewnianiu jakości. Zatem takie pytanie nie powinno dziwić. Co więcej - sami powinniśmy sobie je zadać, gdy już uda się uratować produkcję. Taka analiza jest kluczowa, aby w przyszłości zminimalizować ryzyko występowania takich defektów. Być może uda się wdrożyć nowe, nieomówione dotąd rozwiązanie, może uda się coś zautomatyzować. Takimi rozważaniami oraz wyciąganiem wniosków (zakończonymi odpowiednimi działaniami) podnosimy jakość aplikacji.
2. Pytanie zadane bezpośrednio QA może być toksyczne. Wynika to z tego, że odbierzemy je jako obwinianie, atak w naszą stronę - tak działa nasza psychika i nie ma w tym nic złego. Dobry leader zespołu czy projektu nie zada tego pytania "kjuejowi". Zada je zespołowi. I brzmieć ono powinno "dlaczego ten błąd się pojawił". Wówczas wywracamy sytuację o 180 stopni - wspólna analiza sytuacji z całym zespołem pozwoli na lepsze rozeznanie w terenie i wyciągnięcie kolejnych, kluczowych wniosków - już nie tylko od strony samego testowania, ale również implementacji czy zarządzania infrastrukturą.
3. Dlaczego to pytanie jest "złe"? Bo może wynikać z niezrozumienia roli QA lub starodawnych procesów w organizacji, które należałoby wówczas przeanalizować i zmienić. Przyjrzyjmy się temu. Świadomość potrzeby QA w procesie developmentu rośnie. Na rynku pojawia się sporo ofert pracy. Ale nierzadko towarzyszy temu błędna interpretacja zarządzania jakością. QA mają największą wiedzę domenową, zawsze krytycznie spoglądają na projekt, są w stanie zadać bardzo niewygodne pytania, które nie padną z ust programistów, pmów czy designer'ów (z różnych powodów). Są ekspertami w znajdowaniu najbardziej wyrafinowanych, subtelnych defektów, które pojawiają się zawsze, nawet pomimo najszczerszych chęci programistów. Analizując ten opis, można pomyśleć, że QA to taki rybak, który łapie defekty w swoją sieć. Lub łowca bugów. Błędy są tworzone przez programistów i wyłapywane później przez QA. Taka wizja jest wciąż bardzo powszechna. I nie do końca zgodna z prawdą. Dlaczego? Upraszcza ona wytwarzanie oprogramowania do dwóch etapów - implementacji oraz testowania. Programista implementuje rozwiązania, a QA dba o jakość. Nie. Jakość nie jest czymś, co można określić jednym słowem, jedną czynnością czy jedną osobą. Nie istnieje też coś takiego jak "100% pokrycie testami". Zawsze znajdą się defekty, dziury, luki i nikt nigdy nie da gwarancji, że aplikacja jest przetestowana w 100%.
Tworzenie oprogramowania powinno być definiowane jako seria wielu (naprawdę wielu) kroków. Na każdym z tych kroków powinny pojawić się pewne działania związane z jakością. Jeżeli QA zacznie zapewniać jakość wyłącznie testując oprogramowanie (nawet będąc od początku w projekcie, ale nie podejmując się innych działań), wówczas ta jakość będzie w optymistycznym wariancie na jako-takim poziomie. Jak widać, nie możemy mówić o rybaku, który w swoją sieć łapie błędy czy o łowcy bugów.
Skoro już wiemy, że zapewnianie jakości to cały proces, a nie tylko testowanie i wiemy, że to cały zespół musi dbać o jakość - na każdym z tych wielu kroków, podczas których należy podjąć odpowiednie działania związane z jakością, pytanie "QA, czemu nie znalazłeś tego błędu!?" jest toksyczne i pokazuje, że w danej organizacji jakość to tylko jeden krok, jeden etap. Tak jak wspomniałem - to pytanie powinno być zadane do całego zespołu.
Niestety, zdarza się również że podczas spotkania zespołowego, programiści będą mówić "no, był błąd, ale to QA powinien go znaleźć" czy "to nie moja wina, to wina testera". Kolejna toksyczna sytuacja i niezrozumienie czym jest jakość i że jakość to cały proces, a nie "rola/osoba/czynność".
I żeby dodać jeszcze do ognia - również QA mogą tę toksyczną wizję zaostrzać. Jak? Definiując siebie jako "obrońca produkcji". Tutaj zapewne wielu z Was się uśmiechnęło, niezależnie czy macie już doświadczenie czy też nie 🙂 I jasne, taka (i podobne) definicja często się pojawia - sam czasami z niej korzystam, raczej żartobliwie, ale jednak. Biorę też odpowiedzialność za projekt i nierzadko mówię o tej odpowiedzialności, rozmawiając z innymi osobami. Jednak to nie zawsze jest dobre. Biorąc odpowiedzialność i ogłaszając to, sami możemy nieświadomie stworzyć toksyczną atmosferę w organizacji czy zespole - pokazując, że to nasza wina. Skoro to nasza wina, że defekt znalazł się na produkcji, to następnym razem PM zada nam bezpośrednio pytanie "czemu tego nie znaleźliśmy". I kółko się zamyka...
Kolejna sytuacja z życia wzięta - bardzo często przed wydaniem aplikacji na środowisko produkcyjne (czy to premiera czy też kolejna wersja), to QA jako ostatni poświadcza, że wszystko jest gotowe i daje zielone światło. I jest to dobre, bo to my mamy największą wiedzę, wiemy czy standardy zostały spełnione (Definition of Done, testy funkcjonalne, testy automatyczne oraz inne aspekty). Musimy jednak pamiętać, że to zielone światło nie oznacza "daję Wam gwarancję, że nie ma błędów". Jeżeli zespół myśli w ten sposób - trzeba to szybko zrewidować i nauczyć, że tu nie chodzi o gwarancję, a o "zielone światło" w kontekście chociażby spełnienia wszystkich przyjętych procedur czy standardów.
Zbieranie wymagań, testowanie jednostkowe, profilowanie, implementacja, integracja poszczególnych modułów, konfiguracja infrastruktury, zabezpieczenie sieci oraz aplikacji webowej, ochrona danych osobowych, testy funkcjonalne oraz niefunkcjonalne, definition of ready, definition of done, code review, kryteria akceptacji, pokrycie testów, testy API, interfejs użytkownika zgodny z dobrymi praktykami UX, standardy i procedury - to tylko część elementów, które wpływają na zwiększenie jakości. Nadal myślisz, że jedna osoba temu podoła? 🙂
|