Przywództwo w testach: realizacja projektu testowego

Czy jesteś gotowy?

Gladiatorzy, nadszedł czas, aby wykonać zadanie. Celem tego artykułu jest przeprowadzenie Cię przez proces realizacji projektu testowego. Omówię:

• Klasyczne ograniczanie czasu na testowanie
• Raportowanie sukcesu i niepowodzenia
• Erozja pokrycia
• Zarządzanie incydentami
• Zarządzanie końcową fazą

A więc, czy jesteś gotowy? Istnieją cztery kluczowe aspekty:

• Ludzie — czy Twój zespół jest gotowy?
• Środowiska — czy dysponujesz technologiami, danymi, urządzeniami i interfejsami niezbędnymi do przeprowadzenia miarodajnych testów?
• Wiedza — czy przygotowałeś testy z odpowiednim poziomem szczegółowości, czy też Twój zespół jest gotowy i zdolny do badania oraz testowania systemu w sposób dynamiczny?
• System poddawany testom — czy oprogramowanie lub system, który masz testować, jest rzeczywiście dostępny?

Pierwsze trzy aspekty są albo pod Twoją kontrolą, albo masz możliwość monitorowania, zarządzania i koordynowania działań w celu zapewnienia ludzi, środowisk i wiedzy. System poddawany testom to inna kwestia. Jeśli system poddawany testom zostanie dostarczony z opóźnieniem, nie możesz w znaczący sposób rozpocząć testowania. To właśnie klasyczne ograniczanie czasu na testowanie.

Klasyczne ograniczanie czasu na testowanie

Każdy, kto testował systemy, doświadczył opóźnionego dostarczenia systemu przeznaczonego do testowania. Na niemal każdym poziomie — od komponentów po całe systemy — deweloperzy napotykają problemy, a dostarczenie jest opóźnione lub niekompletne. W większości przypadków, gdy na przeprowadzenie testów wyznaczono określony czas, termin nie ulega zmianie, a czas na testowanie zostaje skrócony. Zmusza to zespoły do wyboru między jakością a szybkością. Jeśli szukasz narzędzi zapewniających jedno i drugie, zapoznaj się z naszą listą najlepszych platform do testowania oprogramowania.

Częściowe i przyrostowe dostarczanie

Chociaż kompletny system nie może zostać dostarczony do testowania, można dostarczyć część funkcjonalności — częściowy system — z obietnicą, że późniejsze wydania będą zawierać pozostałe funkcje. W dowolnym momencie status funkcji w wydaniu będzie przedstawiał się następująco:

• Ukończone zgodnie z wymaganiami: te funkcje można testować — przynajmniej w izolacji.
• Nieukończone: funkcjom brakuje części funkcjonalności i/lub wiadomo, że zawierają błędy.
• Brakujące: ich dostarczenie odroczono do późniejszego wydania.

Jeśli chodzi o dostępne funkcje, możliwe może być testowanie ich w izolacji. Mogą one jednak zależeć od danych utworzonych przez inne, jeszcze niedostępne funkcje, co może utrudnić ich testowanie.

Funkcje mogą być dostępne, ale danych wyjściowych tych funkcji nie można zweryfikować za pomocą innych, jeszcze niedostępnych funkcji, dlatego konieczne jest zbadanie testowej bazy danych przed wykonaniem operacji i po jej wykonaniu. Niemal na pewno testy kompleksowe, wymagające możliwych do przetestowania ciągów funkcji, będą w większości zablokowane.

Pod niemal każdym względem testowanie częściowych systemów na poziomie systemu jest poważnie utrudnione.

Obrona testowania

Twój zespół musi robić postępy, niezależnie od trudności. Jeśli system nie jest dostępny lub jest dostępny dla zespołu tylko częściowo, musisz zarządzać oczekiwaniami i bronić swojego planu. 

Twój plan testowania, zarówno w małej, jak i dużej skali, zależy od dostępności systemu — jest to założenie — dlatego Twój plan musi się zmienić. Możesz nie dokumentować formalnych kryteriów wejścia, ale przekaz pozostaje taki sam:

Kryteria wejścia są założeniami planistycznymi – jeśli te kryteria nie są spełnione, założenia planistyczne są błędne i plan należy dostosować.

Niezależnie od tego, czy czekasz na dostarczenie systemu, czy masz dostęp do jego części, dość szybko zabraknie Ci pożytecznych rzeczy do zrobienia. Wtedy odbędziesz trudną rozmowę z właścicielem produktu lub kierownikiem projektu. Jeśli termin ukończenia nie zostanie przesunięty, będziesz zmuszony przeprowadzić mniej testów. Niektóre funkcje mogą być testowane w mniejszym zakresie albo całkowicie wyłączone z testów.

Menedżer może uważać, że później nadrobisz stracony czas, ale w praktyce prawie nigdy nie jest to osiągalne.

Czas testowania utracony z powodu opóźnionych lub częściowych dostaw nie może zostać odzyskany poprzez „cięższą pracę”.

Dlaczego testowanie jest opóźnione? Możliwych przyczyn jest wiele, ale zwykle pasują one do jednego z następujących wzorców:

• Środowisk nie można skonfigurować na czas. Ludzie rozpoczęli pracę z opóźnieniem, byli zbyt zajęci albo nie mieli kwalifikacji do stworzenia użytecznego środowiska testowego. To, co jest dostępne, jest częściowe, błędnie skonfigurowane lub niekompletne.
• Dostarczenie jest opóźnione, ponieważ skala prac została niedoszacowana.
• Dostarczenie jest opóźnione, ponieważ oprogramowanie zawiera błędy, jest trudne do testowania i naprawy.
• Dostarczenie jest opóźnione, ponieważ zespołowi deweloperskiemu brakuje umiejętności, doświadczenia lub kompetencji w dziedzinie biznesowej albo w zakresie wykorzystywanych technologii.
• Dostarczenie jest opóźnione, ponieważ prace deweloperskie rozpoczęły się z opóźnieniem.
• Dostarczenie jest opóźnione, ponieważ wymagania ciągle się zmieniają.

Na powyższej liście nie uwzględniono klęsk żywiołowych i innych czynników zewnętrznych pozostających poza kontrolą zespołu projektowego. Jeśli kierownik projektu nalega, aby termin testowania się nie zmienił, a zakres testów również pozostał stały, stajesz przed poważnym wyzwaniem. W każdym z powyższych przypadków przyczyny opóźnienia dostawy przemawiają za przeprowadzeniem większej liczby testów, a nie mniejszej.

Jeśli prace deweloperskie zostały niedoszacowane, prawdopodobnie tak samo niedoszacowano testowania. Jeśli oprogramowanie zawiera błędy, testowanie potrwa dłużej. Jeśli deweloperom brakuje umiejętności, oprogramowanie najprawdopodobniej będzie słabej jakości i jego przetestowanie zajmie więcej czasu. Jeśli deweloperzy rozpoczęli pracę z opóźnieniem (dlaczego?), a zakres pozostał bez zmian, dlaczego testowanie miałoby zostać ograniczone? Jeśli wymagania się zmieniają, prawdopodobnie Twoje plany i tak są błędne – praca według złego planu nieuchronnie utrudnia życie.

Ile spośród typowych przyczyn opóźnionego dostarczenia sugeruje, że potrzebne jest mniej testów? Żadna. Broń swojego planu.

Raportowanie sukcesów i porażek

Większość testerów wie, że skuteczne testowanie wymaga ciekawości, wytrwałości i wyczucia problemu. Najważniejszą motywacją jest prowokowanie awarii i gromadzenie wystarczających dowodów, aby awarie można było powiązać z defektami, które następnie można naprawić. 

Chociaż znajdowanie (i naprawianie) defektów jest dobre dla jakości produktu, informowanie o defektach często daje poczucie, że przekazuje się komuś złe wiadomości. Może to być deweloper, który popełnił gdzieś błąd i musi go naprawić, albo interesariusze, którym zgłaszasz, że jakaś krytyczna funkcjonalność nie działa prawidłowo i dostarczenie systemu się opóźni.

Nikt nie lubi przekazywać złych wiadomości i naturalne jest, że niechętnie sprawiamy innym przykrość, szczególnie bliskim współpracownikom. Jednak poczucie, że przekazywana wiadomość jest dobra lub zła, nie powinno być kwestią, którą posłaniec się zajmuje. 

Defekty zawsze są dla kogoś złymi wiadomościami, ale rolą testowania nie jest ocenianie w ten sposób. Pod pewnymi względami tester przypomina dziennikarza poszukującego prawdy. Opowieść Kiplinga „Słoniątko” zawiera następujące wersy:

Trzymam sześciu uczciwych sług:
    (Nauczyli mnie wszystkiego, co wiem)
Nazywają się Co i Gdzie, i Kiedy
    Oraz Jak, Dlaczego i Kto.

Tak jak dziennikarz opowiada historię wiadomości, Ty opowiadasz historię tego, co odkryłeś podczas testowania systemu.

Prawda – wiadomość – może być dobra lub zła, ale Twoim obowiązkiem jest po prostu jak najlepiej poszukiwać zarówno problemów, jak i sukcesów. Próbujesz odkryć, co robi system i w jaki sposób to robi. 

Na samym końcu projektu celem jest wdrożenie do środowiska produkcyjnego z możliwie najmniejszą liczbą nierozwiązanych problemów. Chcesz, aby wszystkie testy zakończyły się pomyślnie, ale droga do sukcesu jest utrudniona przez nieudane testy, które trzeba zbadać i rozwiązać. Twoim celem taktycznym jest szybkie znajdowanie problemów, ale ostatecznym celem jest brak problemów do zgłoszenia. 

Aby dokładnie raportować sukces lub porażkę projektu testowego, rozważ wdrożenie zaawansowanych narzędzi do zarządzania testami, które oferują kompleksową analitykę

Musisz zachowywać się podobnie jak dziennikarz śledczy – szukać historii z krytycznym i niezależnym nastawieniem. Jak napisał Kipling:

Jeśli potrafisz spotkać się z Triumfem i Katastrofą i traktować tych dwóch oszustów dokładnie tak samo …

Wtedy zachowasz zimną krew i dobrze wykonasz swoją pracę na rzecz projektu i interesariuszy.

Erozja pokrycia testami

Niezależnie od tego, jakie cele pokrycia testami istnieją na początku testowania, kilka czynników przyczynia się do zmniejszenia faktycznie osiągniętego pokrycia. Termin „erozja” jest odpowiedni, ponieważ rzeczywiście odzwierciedla stopniowe zmniejszanie zakresu zaplanowanych testów oraz nieuniknione uświadomienie sobie, że nie wszystkie zaplanowane testy można wykonać w dostępnym czasie.

Erozja pokrycia testami ma kilka przyczyn występujących przed wykonaniem testów:

• Po pierwsze, plany testów określają ryzyka, którymi należy się zająć, oraz podejście, które należy zastosować, aby je ograniczyć. Plany zwykle zakładają budżet na testowanie – co zawsze jest kompromisem.
• Niskiej jakości, niestabilne lub nieukończone wymagania systemowe, projekty i specyfikacje utrudniają przygotowanie specyfikacji testów. Pokrycie systemu jest ograniczone przez brak szczegółowych specyfikacji.
• Późna dostępność lub niewystarczająca jakość środowisk testowych sprawiają, że niektóre zaplanowane testy są niepraktyczne lub pozbawione znaczenia. Testowanie integracyjne na większą skalę może być niemożliwe do wykonania zgodnie z planem, ponieważ nie wszystkie interfejsy lub systemy współpracujące mogą być udostępnione.
• Testowanie wydajności może być ograniczone, ponieważ środowiska nie mają odpowiedniej skali lub nie odzwierciedlają środowiska produkcyjnego.
• Późne dostarczenie testowanego oprogramowania oznacza, że jeśli terminy pozostają niezmienione, zakres testów musi zostać zmniejszony.

Erozja pokrycia testami podczas wykonywania testów również ma kilka przyczyn:

• Jeśli jakość testowanego oprogramowania jest niska na początku etapu testów, wykonywanie testów może być szczególnie frustrujące. Najbardziej podstawowe testy mogą kończyć się niepowodzeniem, a znalezione usterki mogą być tak fundamentalne, że programiści będą potrzebować więcej czasu na ich naprawę, niż ktokolwiek przewidywał. Jeśli testowanie zostanie zawieszone, ponieważ jakość oprogramowania jest zbyt niska, powstaną opóźnienia. Jeśli termin nie zostanie przesunięty, niektóre testy zostaną wyłączone z zakresu.
• Jeśli wystąpi więcej usterek, niż przewidywano, sam cykl naprawy i ponownego testowania zajmie więcej czasu i zabraknie go na ukończenie wszystkich testów.
• Kiedy czas się skończy i zostanie podjęta decyzja o wydaniu produktu, nie wszystkie testy będą ukończone. Niektóre testy mogły nie zostać nigdy wykonane zgodnie z planem albo pozostałe usterki mogą blokować ukończenie nieudanych testów. Jeśli data uruchomienia produkcyjnego nie zostanie przesunięta, będzie to klasyczna presja związana z testowaniem, o której wspomniano wcześniej.

Radzenie sobie z erozją pokrycia testami jest jednym z wyzwań, przed którymi stają testerzy we wszystkich projektach. Rzadko wszystko przebiega bezproblemowo, a skrócenie czasu na testowanie (i pokrycia) jest zwykle jedyną możliwością utrzymania projektu na właściwym torze.

Zmniejszenie zakresu testowania nie jest błędem; błędem jest jedynie jego arbitralne ograniczanie. W związku z tym, podejmując decyzje o tym, które testy pominąć, należy przeanalizować wpływ na cele testów oraz ryzyka, którymi trzeba się zająć. Aby to przeprowadzić, być może czekają Cię trudne rozmowy z interesariuszami.

Jeśli wpływ jest znaczący, może być konieczne zorganizowanie spotkania osób, które proszą o ograniczenia (zwykle kierownictwa projektu), oraz tych, których interesy mogą zostać przez te ograniczenia dotknięte (interesariuszy). Twoją rolą jest przedstawienie sytuacji w odniesieniu do ukończonych testów, aktualnego znanego stanu testowanego systemu, testów, które kończą się niepowodzeniem lub blokują postęp, oraz zakresu testów pozostałych do wykonania.

Twoje plany i modele opisują pierwotny zakres testowania i mają kluczowe znaczenie dla pomocy interesariuszom i kierownictwu w zrozumieniu luk oraz pozostałych ryzyk i podjęciu decyzji o kontynuowaniu testowania lub jego zakończeniu.

Zarządzanie incydentami

Gdy projekt przechodzi do etapów testowania systemowego i testów akceptacyjnych, jego przebieg jest w dużej mierze kształtowany przez incydenty występujące podczas wykonywania testów. Incydenty uruchamiają działania w pozostałej części projektu, a statystyki incydentów mogą czasami dostarczyć dobrego obrazu stanu projektu. Kategoryzując incydenty, musimy myśleć z wyprzedzeniem o tym, jak te informacje będą później wykorzystywane.

Incydent to nieplanowane zdarzenie, które występuje podczas testowania i może mieć wpływ na pomyślne ukończenie testów, decyzję akceptacyjną lub potrzebę podjęcia innego działania.

Używamy neutralnego terminu dla tych nieplanowanych zdarzeń – incydent. Zdarzenia te są jednak często określane innymi terminami; niektóre z nich są bardziej neutralne od innych. 

Testy, które kończą się niepowodzeniem, mogą być określane jako obserwacje, anomalie lub problemy – są to neutralne terminy, które nie zakładają przyczyny. Czasami używa się jednak określeń: problemy, błędy, defekty lub usterki – co zakłada, że system jest wadliwy. Może to być jednak przedwczesny wniosek, a takie etykiety mogą wprowadzać w błąd.

Sugerujemy, aby terminów błąd, defekt lub usterka używać wyłącznie w odniesieniu do wyników diagnozy niepowodzeń w procesie tworzenia testowanego systemu, które zwykle powodują konieczność wykonania dodatkowych prac przez zespół programistyczny.

Incydenty przejawiają się na dwa sposoby:

1. Awaria systemu: system nie działa zgodnie z oczekiwaniami podczas testu, tzn. w pewien sposób zawodzi lub wydaje się nie spełniać określonego wymagania.
2. Przerwanie testowania lub testów bądź ich podważenie: zdarzenie, które wpływa na zdolność testerów do wykonania ich zadań, takie jak utrata lub awaria środowiska testowego, danych, interfejsów, systemów lub usług wspierających i zintegrowanych albo inny wpływ zewnętrzny.

Awaria systemu

Zdarzenia te często budzą największe bezpośrednie obawy, ponieważ podważają zaufanie do jakości systemu. 

Przerwane i podważone testy

Niektóre organizacje w ogóle nie traktują tych zdarzeń jako incydentów – przerwy są częścią trudnej codzienności projektów zmierzających do zakończenia. Za podważone testy, czyli takie, w których środowisko lub konfiguracja testów są nieprawidłowe, może zostać obarczony winą zespół testowy (za konfigurację lub przynajmniej za niesprawdzenie jej przed rozpoczęciem testów).

W obu przypadkach postęp testowania zostaje zakłócony, a jeśli zarządzasz tym procesem, odpowiadasz za wyjaśnienie opóźnień. Z tego powodu powinieneś rejestrować te zdarzenia jako incydenty albo poprosić zespół o prowadzenie dziennika testów i odnotowywanie awarii środowiska, problemów z konfiguracją lub braku odpowiednich wersji oprogramowania do testowania. Jeśli tego nie zrobisz, trudno będzie uzasadnić opóźnienia w postępach prac, a sytuacja może źle wpłynąć na ocenę ciebie i zespołu.

Rejestrować incydenty czy nie?

Wraz z pojawieniem się podejść zwinnych i ciągłego dostarczania tradycyjny pogląd na zarządzanie incydentami został zakwestionowany. W projektach etapowych incydenty traktuje się jako potencjalne pakiety prac dla programistów, zatwierdzane zgodnie z ważnością i/lub pilnością. 

Istnieje formalny, często biurokratyczny proces, zgodnie z którym incydenty są przeglądane, ustalany jest ich priorytet, a następnie są obsługiwane przez zespół programistyczny (lub inny zespół). Mogą być w tym wykorzystywane zaawansowane narzędzia do zarządzania incydentami.

W mniejszych, zwinnych zespołach relacja między testerem a programistą jest bliska. Cały zespół może codziennie spotykać się, aby omawiać większe incydenty, ale najczęściej błędy są wykrywane, diagnozowane, naprawiane i ponownie testowane nieformalnie, bez potrzeby rejestrowania incydentu ani angażowania innych osób z zespołu lub pracowników biznesowych bądź IT spoza zespołu. Poważniejsze błędy mogą być omawiane i włączane do prac nad historyjką użytkownika albo grupowane w ramach dedykowanych iteracji lub sprintów naprawy błędów.

W jednym z wcześniejszych artykułów omówiliśmy cel i potrzebę dokumentacji. To omówienie dotyczy również incydentów. Zespół musi rozważyć, czy potrzebne jest narzędzie i proces obsługi incydentów oraz czy są one pomocne dla zespołu i/lub wymagane przez osoby spoza zespołu.

Większe zespoły mają tendencję do polegania na procesach i narzędziach w zarządzaniu incydentami z trzech powodów: 

1. Aby zagwarantować, że incydenty nie zostaną zapomniane
2. Aby poważne problemy były analizowane przez interesariuszy i kierownictwo projektu 
3. Aby gromadzić dane, które mogą być wartościowe w trakcie projektu i po jego zakończeniu.

Oddzielanie pilności od ważności

Niezależnie od przyjętego procesu zarządzania incydentami zalecamy przypisywanie wszystkim incydentom zarówno kodu priorytetu, jak i kodu ważności.

• Priorytet jest przypisywany z punktu widzenia testowania i wpływa na to, kiedy incydent zostanie rozwiązany. Tester powinien zdecydować, czy incydent ma wysoki czy niski priorytet (lub jeden z dozwolonych stopni pośrednich). Priorytet wskazuje pilność tej usterki dla samych testerów i opiera się na wpływie, jaki niepowodzenie testu wywiera na pozostałą część testowania.
• Ważność jest przypisywana z punktu widzenia użytkownika i wskazuje na akceptowalność lub jej brak w przypadku (zwykle) defektu. Użytkownicy końcowi lub ich kierownictwo powinni określać ważność albo (co jest bardziej efektywne) w razie potrzeby korygować wstępną ocenę testerów. Ważność odzwierciedla wpływ tego defektu na działalność biznesową, gdyby nie został on naprawiony przed wdrożeniem. Zazwyczaj poważny defekt sprawia, że system jest nieakceptowalny. Jeśli defekt ma niską ważność, można uznać go za zbyt błahy, aby wymagał naprawy przed uruchomieniem produkcyjnym, ale można go naprawić w późniejszym wydaniu.

Jeśli incydent zatrzymuje testowanie, a testowanie znajduje się na ścieżce krytycznej, zatrzymuje się cały projekt.

Incydent o wysokim priorytecie zatrzymuje całe testowanie, a zazwyczaj również projekt.

W przypadku schematów klasyfikacji incydentów należy pamiętać, że nie każdy pilny incydent jest poważny i że nie każdy poważny incydent jest pilny.

Zarządzanie końcowym etapem

Końcowe etapy naszego procesu testowego nazywamy „końcowym etapem”, ponieważ zarządzanie działaniami testowymi w tych ostatnich, potencjalnie gorączkowych i stresujących dniach wymaga innej dyscypliny niż wcześniejszy, pozornie znacznie spokojniejszy okres planowania testów.

Pamiętaj, że celem testowania jest dostarczenie interesariuszom informacji umożliwiających im podjęcie decyzji – zaakceptowanie, naprawienie, odrzucenie, przedłużenie projektu lub całkowite jego porzucenie. 

Jeśli macie wspólne zrozumienie modeli, które mają być wykorzystywane podczas testów, znacznie łatwiej jest wyjaśnić, co „działa” (w odniesieniu do modelu), a także gdzie występują problemy i jakie ryzyko wiąże się z tymi niepowodzeniami. To interesariusze powinni wykorzystywać te informacje do podejmowania decyzji — pod waszym kierunkiem.

Jedną z korzyści wynikających z przyjęcia podejścia do testowania opartego na ryzyku jest to, że gdy zakres testów zostaje ograniczony pod koniec projektu, wykorzystujemy ryzyko rezydualne, aby uzasadnić kontynuowanie testów lub nawet dodanie kolejnych testów. 

Gdy kierownictwo nalega na ograniczenie testów, testerzy powinni po prostu przedstawić ryzyka, które są w ten sposób „zamieniane”. Jest to znacznie łatwiejsze, gdy na wczesnym etapie przeprowadzono ocenę ryzyka, wykorzystano ją do ukierunkowania działań testowych i monitorowano ją przez cały projekt. Gdy kierownictwo jest stale świadome ryzyka rezydualnego, jest mniej prawdopodobne, że w ogóle będzie ograniczać testy.

I to już wszystko, powodzenia w testowaniu!

Zapisz się do newslettera The QA Lead, aby otrzymywać powiadomienia o publikacji kolejnych części serii. Te wpisy są fragmentami kursu Leadership In Test Paula, który gorąco polecamy wszystkim, którzy chcą dokładniej zgłębić ten i inne tematy. Jeśli się zdecydujesz, użyj naszego ekskluzywnego kodu rabatowego QALEADOFFER, aby uzyskać 60 USD zniżki od pełnej ceny kursu!