TABLE OF CONTENTS:
Skutki wadliwego oprogramowania w różnych sytuacjach są powszechnie znane. Mogą to być choćby dysfunkcje sond marsjańskich, awarie systemów telekomunikacyjnych, wyciek danych wrażliwych czy nieprawidłowe działanie maszyn do chemioterapii, mogących podać śmiertelne dawki promieniowania. Sensownym wydaje się więc założenie, że tester będzie cenionym członkiem interdyscyplinarnego zespołu pracującego nad oprogramowaniem. Nie jest to jednak tak oczywiste, jak się wydaje. Dlaczego?
Być może tym pytaniem wsadzimy kij w mrowisko, ale mimo wszystko warto je zadać, bo moja odpowiedź będzie dość prosta. Spotkałam się z założeniem, że inżynierowie ds. zapewnienia jakości (QA) to ludzie, którzy mieli ambicje zostać programistami, ale zabrakło im zapału lub umiejętności. Oczywiście, pewnie znajdą się tacy dla których testowanie jest etapem na ścieżce do programowania, jednak większość znanych mi testerów to osoby, które pasjonują się swoją pracą ,i którym naprawdę zależy na jakości testowanego produktu.
Dlaczego zatem testerzy nie cieszą się właśnie taką reputacją? W wielu przypadkach decydują o tym niekoniecznie dobre nawyki, z którymi każdy z nas pewnie się spotkał. Przed wami subiektywna lista 5 punktów wartych przeanalizowania, jeśli masz podejrzenie, że twoja praca nie jest odpowiednio doceniana i oceniana.
Nie oszukujmy się wszyscy tam byliśmy.
Słabo opisana historyjka w Jirze, na podstawie której nikt nie jest do końca pewien, jak ma dana funkcjonalność działać. Deweloper, któremu powierzono dane zadanie naprawienia kodu, po którym nie został żaden ślad w dokumentacji.
Kryteria akceptacji? Jakie kryteria akceptacji! Po prostu uruchom aplikację! Jak zrobisz to i się nie wysypie, to znaczy, że zostało zrobione i działa.
Naprawdę? Skąd wiesz, że deweloper ma rację? Jeśli wystąpi awaria na produkcji, chcesz się zasłaniać tym, że programista tak ci powiedział, więc zamknąłeś story?
Zadawaj pytania. Poproś, by programista, analityk albo ktokolwiek odpowiedzialny wyjaśnił ci, jak działa ta funkcja, jakie zmiany zostały wprowadzone. Niech będzie po nich ślad w Jira. Dopiszcie kryteria akceptacji i konkretne uzgodnienia. Dociekaj, aż naprawdę zrozumiesz, co się dzieje. Dzięki temu możesz dojść do tego, o czym programista nie pomyślał i odesłać story do poprawy.
O ile w ogóle są w niej zawarte kryteria akceptacji (dokładnie określające, jak powinna się zachowywać nowa funkcja lub poprawka), to są one często pisane przez właściciela produktu lub programistę (sic!). Są pomocne i z pewnością lepsze niż ich brak, jednak często są tam tylko tzw. „happy paths”. Nie dlatego, że ktoś próbuje coś ukryć, tylko dlatego, że nikt o nich po prostu nie pomyślał.
Myśl nieszablonowo! Co może pójść nie tak? Czy mogę zrobić coś jeszcze, co mógłby zrobić użytkownik, a co mogłoby wygenerować jakieś błędy?
Często, kiedy testujemy coś nowego, natrafiamy na zachowanie, które nie ma sensu. Być może jest nim przycisk pojawiający się nie w tym miejscu, w którym się tego spodziewaliśmy, a może link na stronie kierujący nas nie tam, gdzie powinien. Kiedy mamy krótki termin oddania historyjki, skupiamy się tylko na „happy paths”, a zupełnie ignorujemy dziwne zachowania aplikacji lub schodzą one na dalszy plan. Bo przecież deweloper wie, co robi i najprawdopodobniej takie właśnie zachowanie jest poprawne.
Błąd! Słuchaj siebie i swojego instynktu. Jeśli jest coś dziwnego, to zapewne użytkownik też tak uzna. Może to nawet urosnąć do rangi powodu, przez który zrezygnuje z używania danej funkcjonalności, czy – co gorsza – produktu w ogóle. Zadaj sobie pytanie, co byś pomyślał o produkcie, będąc jego użytkownikiem, a nie testerem. Bądź strażnikiem, gwarantującym klientowi dobre doświadczenie z aplikacją. Jeśli instynkt ci podpowiada, że jest coś dziwnego – udokumentuj to. Jeśli zachowanie aplikacji cię frustruje, próbuj je zmienić. Opisz to, co udało się znaleźć i zaproponuj rozwiązanie!.
Czasami skupiamy się tak bardzo na znalezieniu błędu w produkcie, że wstrzymujemy postęp prac, zgłaszając nawet absurdalne „znaleziska”. Nie skupiamy się na rzeczywistych przypadkach użycia, tylko chełpimy się, znajdując zachowania, których użytkownik przenigdy by nie zrobił, np. kilkukrotne kliknięcie jakiegoś jednego przycisku, następnie poruszanie się po stronach kilkukrotnie wstecz i do przodu, a na koniec przewijamy stronę, ale tylko bardzo bardzo szybko. Bo jak trochę za wolno, to jest ok. A to wszystko tylko w Chromie, na jednej konkretnej wersji. Zapewne gonienie tego błędu było wyjątkowo fajne, ale zastanów się, ile rzeczywistych problemów mogłoby zostać znalezionych w tym czasie, kiedy następuje kolejna próba odtworzenia tego samego niejasnego i mało szkodliwego problemu. Żeby było jasne: nie chodzi tu o niezgłaszanie błędów, bo wydają się w naszej ocenie mało istotne. Mogą one prowadzić do katastrofy, z której nawet nie zdajemy sobie sprawy. Oczywiście, raportować powinniśmy wszystko. Jednak kiedy czas na testy jest ograniczony (a zazwyczaj jest) musimy się skoncentrować i zacząć od najważniejszych funkcjonalności.
Nie „goń króliczka” jedynie dla samej przyjemności znalezienia błędu. Skup się lepiej na zapewnieniu użytkownika, że oprogramowanie działa dobrze i jest chronione przed złośliwymi atakami. A kiedy się zapędzisz, zadaj sobie pytanie – czy warto? I znajdź balans. Czy nie lepiej spędzić czas na sprawdzaniu realnych przypadków użycia? A kiedy czas pozwoli, oczywiście – baw się. Znajdowanie błędów to przecież jest wspaniała zabawa!
Automatyzacja jest super fajna, modna i pożądana, jednak nie zawsze jest dobrym rozwiązaniem.
Jeśli testujesz nową funkcjonalność, poświęć jej trochę czasu. Poznaj ją tak jak ktoś, kto faktycznie będzie z niej korzystał. Wygospodaruj czas na ręczne testy eksploracyjne. Zadawaj pytania, jak można wykorzystać daną rzecz. Pomyśl, co może zrobić użytkownik korzystający z tej funkcjonalności. Znajdź błędy, raportuj je. Dopiero po wykonaniu tych kroków zacznij myśleć jak to zautomatyzować.
Przecież wiesz , że im więcej kroków ma test, tym wyższe prawdopodobieństwo , że któryś z nich zakończy się źle, co spowoduje niepowodzenie całego procesu. Co za tym idzie – całe testy będą niestabilne. Automaty powinny być proste, a każdy test powinien sprawdzać tylko jedną rzecz.
Tester jest drobiazgowy. Tester jest czepialski. Tester myśli niestandardowo, jednocześnie potrafi wcielić się w rolę zwykłego użytkownika. To dzięki temu właśnie jest dobry w znajdowaniu błędów. Efektem pracy testera musi być pewność, że użytkownik skorzysta z produktu bezpiecznie, łatwo i intuicyjnie. Tylko konsekwencja oraz koncentracja na jakości pozwolą nam budować reputację skutecznego testera, zdobywając przy tym zaufanie i szacunek właściciela produktu, menedżmentu oraz deweloperów.
