Wyobraźmy sobie firmę, w której programiści spokojnie pracują nad projektem, mając dostęp do pełnej dokumentacji.
Po zakończeniu pracy oddają do testów całkowicie gotową aplikację. Testerzy weryfikują i walidują jej działanie, zgodnie z wcześniej ustalonym planem testów. I … uwaga, uwaga – wykonują wszystkie zaplanowane testy, bo mają na to wystarczającą ilość czasu!
Ha, dobre sobie, no ale spróbujmy zobaczyć to oczami wyobraźni… w naszej wyimaginowanej firmie o dumnej nazwie „Tu chcę pracować”.
„W tej dokumentacji niczego nie brakuje”
Dobrze przygotowana dokumentacja to nieocenione źródło wiedzy, zarówno dla programistów, jak i testerów. Kiedy już ją dostaniemy to warto się z nią wnikliwie zapoznać, żeby zrozumieć jaką funkcjonalność będziemy tworzyć, do czego ma ona służyć, w jaki sposób działać, jakie możliwości ma dać użytkownikowi.
Jeżeli funkcjonalność jest skomplikowana (a więc dokumentacja jest długa i szczegółowa), to lepiej będzie najpierw zapoznać się z nią bardziej ogólnikowo, aby zrozumieć dlaczego i do czego użytkownik potrzebuje danej funkcjonalności. Dopiero później można zapoznać się ze szczegółami.
Czytanie dokumentacji to tak naprawdę pierwszy etap testowania.
Już na tym poziomie można wyłapać błędy, braki i nieścisłości. Wystarczająco wcześnie zgłoszone pozwolą na dopracowanie dokumentacji jeszcze przed rozpoczęciem prac programistycznych, co jest ogromną oszczędnością czasu i pieniędzy! To dobry moment na rozmowę z przedstawicielem biznesu. Dogłębna analiza dokumentacji, trochę refleksji nad nią (przyda się kilka dni), następnie dyskusja z product ownerem lub inną osobą, która odpowiada za projekt ….. iiii mamy pełną dokumentację, dokładnie taką, do jakiej mamy dostęp w „Tu chcę pracować”!
„Jak to przetestować?”
Kiedy już wiemy co będziemy testować trzeba zastanowić się nad tym, jak to zrobić.
W tym celu należy przygotować przypadki testowe, co jest równoznaczne z rozpisaniem ścieżek, którymi może poruszać się użytkownik (w „Tu chcę pracować” rozpisujemy wszystkie!). Tworzenie test case’ów najlepiej rozpocząć od głównej funkcjonalności, a dopiero później wchodzić w szczegóły (w normalnym świecie z pewnością zabraknie czasu na wypisanie wszystkiego, a później na przetestowanie, dlatego poza naszą idealną firmą koniecznie trzeba zacząć od elementów krytycznych dla funkcjonowania systemu, w „Tu chce pracować” i tak zdążymy ze wszystkim).
Scenariusze tworzy się na podstawie dokumentacji. W trakcie pracy nad nimi można zauważyć ewentualne braki w dokumentacji – to moment kiedy należy ją uzupełnić (konsultując właściwe działanie z osobą decyzyjną).
Dobry przypadek testowy to oczywiście taki, który testuje funkcjonalność, ale jest też w pełni zrozumiały dla osoby trzeciej. W „Tu chcę pracować” przypadki testowe są zrozumiałe dla osób, które nie znają systemu, ani też nie mają pojęcia o testowaniu. Są też uniwersalne, więc możemy je wykorzystać ponownie, zwłaszcza podczas testów regresyjnych.
Jeżeli istnieje taka możliwość warto skonsultować z kimś przygotowane przypadki testowe – z innym testerem znającym daną funkcjonalność czy też z programistą, który zapoznał się już z dokumentacją. Nietrudno coś przeoczyć, a świeże spojrzenie kogoś, kto nie spędził kilku dni nad pisaniem test case’ów, bywa bardzo przydatne. W naszej idealnej firmie test case’y „sprawdza” drugi tester, programista oraz osoba, która była odpowiedzialna za przygotowanie dokumentacji biznesowej.
"Porozmawiaj ze mną devie"
Tester i programista, nierozłączna para, pracująca ramię w ramię.
Tester podziwia piękny kod, programista ceni wnikliwość poszukiwacza błędów (w jego idealnym kodzie)… Tak płyną dni w „Tu chcę pracować”, gdzie doskonale wiemy, że nawet najlepsza dokumentacja nie zastąpi bezpośredniej komunikacji. W słowie pisanym często pojawiają się nieścisłości, które powinny być na bieżąco wyjaśniane.
Bywa niestety tak, że dokumentacja nie jest wówczas uzupełniona/zmieniona, a najświeższe informacje trafiają bezpośrednio do kodującego, omijając przy tym testera. Dlatego warto odbyć pogawędkę z programistą. Co prawda takie problemy nie pojawiają się w „Tu chcę pracować”, ale chcemy mieć pewność, że oboje, zarówno programista, jak i tester, rozumieją dokumentację w ten sam sposób. Dbamy w ten sposób też o to, aby pielęgnowali swoją wyjątkową przyjaźń.
„Środowisko testowe zawsze działa doskonale!”
Zawsze działające środowisko testowe, banalna konfiguracja, wszystko gotowe do testów w kilka minut… Brzmi nieźle, prawda? Witajcie w „Tu chcę pracować”!
Niestety nie zawsze jest to zgodne z rzeczywistością w przypadku innych firm.
Przygotowanie środowiska do testów najlepiej zacząć zanim funkcjonalność zostanie przekazana do testów, aby niepotrzebnie nie opóźniać momentu ich rozpoczęcia.
Na jakie pytania warto sobie odpowiedzieć w tym kontekście? Zacznijmy od najważniejszego:
Czy środowisko testowe działa? Jeśli tak, to czy trzeba wprowadzić jakieś zmiany konfiguracyjne, aby odzwierciedlić działanie środowiska produkcyjnego? Czy potrzebujemy jakichś danych wejściowych? Może trzeba załadować jakieś pliki do bazy, utworzyć konta użytkowników, itp.? Czy dysponujemy odpowiednimi wersjami przeglądarek? Czy mamy odpowiednie urządzenia?
Dobrze, że w „Tu chcę pracować” środowisko testowe zawsze działa i wszystko jest gotowe do testów w ciągu kilku minut! A urządzenia, na których wykonywane są testy, zawsze leżą grzecznie w tym samym miejscu z w pełni naładowaną baterią!
„Nie musimy dużo klikać, bo mamy automaty”
Dobre przetestowanie funkcjonalności wymaga zazwyczaj zarówno testów automatycznych, jak i manualnych. Programiści są odpowiedzialni za przygotowanie testów jednostkowych (testujących poszczególne metody czy obiekty w kodzie), testerzy mogą zająć się testami funkcjonalnymi. W zależności od aplikacji mogą to być testy API lub testy interfejsu użytkownika.
W „Tu chcę pracować” doskonale zdajemy sobie sprawę, że posiadanie testów automatycznych nie oznacza, że testy manualne nie są potrzebne! Nie wszystko da się przetestować automatycznie, więc część testów trzeba przeprowadzić ręcznie. Istotne jest to, aby decyzja o tym, co zostanie przetestowane manualnie, a co automatycznie, została przemyślana, a nie było to dzieło przypadku.
W pierwszej kolejności na liście testów automatycznych powinny pojawić się funkcjonalności, które trzeba testować podczas regresji, a więc te, które automatyzują testy powtarzalne i najbardziej żmudne.
„Ile czasu potrzebujecie na testy?”
Estymowanie testów jest bardziej wiarygodne jeśli następuje po dokładnym zapoznaniu się z dokumentacją, a jeszcze lepiej, kiedy przypadki testowe są już gotowe i estymata dotyczy wyłącznie egzekucji testów, a nie przygotowania też ich planu. Wówczas bardzo łatwo ocenić ile czasu zajmą testy, bo wiadomo dokładnie co i jak trzeba przetestować. Nawet w naszej idealnej firmie nie zawsze jest to możliwe, dlatego podczas estymowania bierzemy pod uwagę:
- przygotowanie przypadków testowych;
- przygotowanie środowiska testowego;
- testowanie funkcjonalności, z uwzględnieniem retestów;
- przygotowanie testów automatycznych;
- ilość dostępnych testerów;
- testy regresyjne.
W firmach nie do końca idealnych trzeba jeszcze zastanowić się czy wszystkie potrzebne do testów narzędzia i urządzenia są dostępne, czy środowisko testowe jest stale dostępne, a nie na przykład współdzielone z innym zespołem. Podczas estymowania bierze się pod uwagę również wszelkie nieprzewidziane sytuacje, które mogą spowodować opóźnienia, w tym celu należy po prostu zawyżyć estymatę.
Poza testowaniem samej funkcjonalności warto rozpatrzyć czy nie ma konieczności przeprowadzenia innych testów, np. bezpieczeństwa lub obciążenia.
„Let’s test!”
Kiedy testerzy zapoznali się z dokumentacja wzdłuż i wszerz, przypadki testowe są gotowe, środowisko do testów przygotowane, a deweloperzy przestali nerwowo stukać w klawiatury (w „Tu chcę pracować” panuje błogi spokój od początku do końca), bo funkcjonalność jest gotowa – można przystąpić do testów.
Kiedy wszystkie poprzednie punkty zostały wykonane właściwie, to samo testowanie nie jest niczym skomplikowanym. Wystarczy sensownie podzielić pracę pomiędzy testerów i przejść przez wszystkie przypadki testowe.
"Oj, to chyba nie działa…"
Tak, wiem. Tego punktu być nie powinno, skoro miało być idealnie, ale przecież testerzy uwielbiają wytykać błędy, więc ich brak wcale nie byłby taki idealny… przynajmniej dla tej grupy, a na to w „Tu chcę pracować” nie możemy sobie pozwolić!
Jeżeli podczas testowania jakiś przypadek testowy nie przejdzie testów - oznaczamy go jako nieudany, a następnie zgłaszamy buga. To, gdzie takie zgłoszenie powinno się pojawić, zależy od firmy, jednak z reguły jest to jakiś system zarządzania projektem typu Jira.
Do takiego zgłoszenia warto podpiąć dany przypadek testowy oraz dokładnie opisać co nie działa. W skrócie w takim zgłoszeniu powinny się znaleźć:
- kroki, które pozwalają na odtworzenie błędu (w „Tu chcę pracować” nie usłyszymy „u mnie działa”);
- dane testowe, które zostały wykorzystane (warunki wstępne);
- informacje o widocznym i oczekiwanym rezultacie;
- informacje na temat środowiska, gdzie dany bug występuje (przeglądarka, system, urządzenie itp.);
- screeny, jeśli to możliwe.
„Już działa!”
Wciąż jesteśmy w świecie idealnym, więc okazało się, że nasz szanowny programista wcale nie popełnił błędu w kodzie tylko zapomniał czegoś dograć, a to może się zdarzyć nawet w „Tu chcę pracować”.
Po wgraniu zaktualizowanej wersji można (a raczej trzeba) przystąpić do retestów. Po wcześniejszych testach dysponujemy teraz listą test case’ów, które ich nie przeszły. Trzeba więc je powtórzyć, korzystając z tych samych danych testowych - czyli wykonujemy dokładnie takie same kroki, które wykonaliśmy wcześniej. Retesty są konieczne jeśli podczas poprzednich testów jakieś przypadki testowe nie przeszły testów z powodzeniem!
Kiedy retesty przejdą pozytywnie i nie zaplanowaliśmy innych rodzajów testów – funkcjonalność może ujrzeć światło dzienne. Oczywiście nie zapominamy o regresji!
No to co? No to deploy!
