Przywództwo w testowaniu: planowanie testów

Czym właściwie jest plan?

Plan projektu łączy zadania projektowe, szacowany czas trwania, zależności i produkty końcowe w zaplanowany model rzeczywistości.

Jeśli uznasz plan za przewidywanie przyszłości, będziesz bardzo ostrożnie podchodzić do polegania na nim, ale właśnie to zwykle robimy.

Być może spotkałeś menedżerów projektów, którzy traktują swój plan jako swoją osobistą rzeczywistość — własny urojony świat. Nie powinniśmy jednak być tak surowi wobec menedżerów projektów — często motywuje ich, aby stworzyć plan i zrealizować go bez względu na wszystko.

Plan nie jest rzeczywistością; jest jej modelem wymagającym ciągłych zmian.

W tym artykule omówię każdy etap planowania testów, w tym:

• Produkty końcowe
• Sposób działania
• Zasoby
• Twoja sieć wsparcia
• Szacunki
• Zależności, ryzyka i założenia
• Komunikacja, zobowiązania i raportowanie postępów

Najpierw jednak wyjaśnijmy dokładnie, na czym polega użyteczność planu. 

Po co planować?

Celem planowania jest zazwyczaj stworzenie uzgodnionego podejścia, zestawu zobowiązań, zależności, kosztów i harmonogramu realizacji projektu. Plan stanowi porozumienie między interesariuszami projektu, dostawcami i uczestnikami, które zazwyczaj określa:

• Jakie zasoby są wymagane i kiedy
• Kiedy zadania muszą się rozpocząć i zakończyć oraz kto je wykona
• Jakie umiejętności są wymagane do ukończenia zadań
• Jakie narzędzia i technologie wspierają plan
• Jakie są produkty końcowe i kiedy zostaną dostarczone
• Koszty nakładu pracy i wymaganych zasobów
• Proces prowadzenia projektu/procesu przez kolejne etapy
• Ryzyka zagrażające realizacji.

Niektóre z tych aspektów mogą być określone w strategii lub już istnieć. Może być na przykład wiadomo, którzy dostawcy są zaangażowani i co zrobią na potrzeby projektu. Narzędzia i technologia, które zostaną wykorzystane, mogą być już znane i dostępne. Ludzie, środowiska testowe i dane mogą być gotowe. Może również istnieć strategia określająca proces, podejście lub techniki, które należy zastosować.

Jednak podczas gdy strategia przedstawia zasady lub teorię, plan opisuje praktyczne aspekty i logistykę realizacji projektu w rzeczywistości.

Strategia określa, jak projekt zostanie zrealizowany co do zasady, natomiast plan definiuje i potwierdza, jak projekt zostanie zrealizowany w praktyce.

W przypadku wielu menedżerów projektów plan jest przechowywany w oprogramowaniu takim jak Microsoft Project, ale wykonalny plan zależy od tego, czy wszyscy uczestnicy projektu wiedzą, co i jak mają robić. Aby to osiągnąć, plan oraz wiedza o tym, jak będą wykonywane poszczególne działania, muszą zostać przekazane wszystkim zaangażowanym osobom, a także zaakceptowane przez wszystkie te osoby.

Planowanie to podróż, a nie zadanie

Jak powiedział były prezydent Stanów Zjednoczonych Dwight D. Eisenhower: „planowanie jest wszystkim. Plan jest niczym”. To stwierdzenie jest tak ważne, że zasługuje na powtórzenie niemal w każdym kontekście pracy nad projektami systemowymi. Co jednak oznacza stwierdzenie, że plan jest niczym? Jaki jest sens planowania, jeśli jego rezultatem jest bezwartościowy plan? 

Plan, który ostatecznie powstaje, nigdy nie jest bezwartościowy, ale stwierdzenie Eisenhowera odnosi się do samego procesu planowania i jego wartości w porównaniu z planem. Przyjrzyjmy się krótko osobno temu, jak wygląda planowanie w długoterminowych projektach o ustrukturyzowanym przebiegu oraz w projektach zwinnych i ciągłych.

Planowanie strukturalne a zwinne

W przypadku projektu długoterminowego Twoja firma, dostawcy i wewnętrzni pracownicy działu IT muszą wiedzieć, jakie zobowiązania są od nich wymagane, aby móc zaplanować dostępność ludzi i zasobów fizycznych.

Zebranie informacji potrzebnych do stworzenia planu zajmuje cenny czas. Przy wszystkich zależnościach dotyczących zasobów i ludzi, a także zaangażowania i wydajności dostawców oraz pracowników wewnętrznych, wiele rzeczy może pójść nie tak. Niektóre rzeczy na pewno pójdą nie tak. Z tego powodu plan, jako prognoza przyszłości, jest niezwykle trudny do przygotowania.

Dzień po opublikowaniu planu, a następnie każdego kolejnego dnia, pojawiają się nowe informacje i konieczne są pewne korekty. Wymagania zostają odrzucone; dostawcy dostarczają produkty z opóźnieniem; środowiska, dane testowe lub narzędzia nie są gotowe na czas. Lista jest długa. Planowanie nigdy nie jest jednorazowym zadaniem, lecz ciągłą — niemal codzienną —aktywnością.

Często nieplanowane zdarzenia traktuje się jako zakłócenia i nie poświęca im zbyt wiele uwagi. Jednak później niektóre z tych drobnych usterek przeradzają się w poważne problemy. Jednym z wyzwań projektów kaskadowych jest to, że ta ciągła korekta może być uciążliwa, ponieważ wszelkie zmiany postrzega się jako niepotrzebne majstrowanie. Projekty często toczą się dalej niezależnie od wszystkiego, w nadziei, że „jakoś to będzie”. Rzadko jednak tak się dzieje, dlatego wielokrotnie powtarzano:

Jak projekt może spóźnić się o rok? Dzień po dniu.

Podejście zwinne jest częściowo reakcją na frustrację związaną ze stałymi lub nieelastycznymi planami. Zwinność to sprawdzona alternatywa dla bezwładności uciążliwych, etapowych metod. Czy oznacza to jednak, że w projektach zwinnych nie planuje się? Nie. 

Nawet w podejściu zwinnym konieczne jest pewne wstępne planowanie, aby uporządkować pracę, zmobilizować zasoby i zaplanować — przynajmniej na wysokim poziomie — proces wydań na najbliższe miesiące. Jednak z każdą iteracją, a często z każdym dniem, ogólny plan jest nieustannie dostosowywany, aby uwzględniać zdarzenia i nowe informacje, które wychodzą na jaw.

Planowanie to ciągła droga uczenia się, a nie zadanie z rezultatem.

Planowanie testów

Do tej pory przyglądaliśmy się ogólnie planowaniu projektów i stwierdziliśmy, że jest ono przede wszystkim działaniem ciągłym. Teraz skupimy się konkretnie na planowaniu testów w projektach. 

Planowanie testów jest bardzo podobne do planowania projektu — to po prostu plan na mniejszą skalę. Oczywiście plan testów musi również integrować się z większym planem projektu, ponieważ zależy od innych działań i rezultatów projektu (a inne zadania zależą od testowania). Plany testów są często zakłócane, ponieważ te zależności nie zostają spełnione.

Plany testów są stosunkowo proste w ujęciu ogólnym. Może istnieć kilka działań zależnych od projektu nadrzędnego. To one często pojawiają się jako zadania w większym planie projektu. Działania te są jednak rozdzielone pomiędzy członków zespołu, który może mieć do zaplanowania i wykonania testów duży zbiór elementów testowych. 

Ten poziom szczegółowości nie jest tak istotny dla harmonogramu kierownika projektu i zwykle jest definiowany oraz zarządzany lokalnie w obrębie zespołu testowego.

Przyjrzyjmy się niektórym kluczowym elementom planu testów.

Rezultaty

Jakie są rezultaty testowania?

Cóż za pytanie! Z pewnością są to specyfikacje testów, testy, wyniki i raporty? Rezultaty są zasadniczo zawarte w dokumentacji, więc wystarczy martwić się o przygotowanie dokumentów i odhaczenie kilku pól. 

Takie podejście, choć powszechne, częściowo odpowiada za to, że testowanie (i testerzy) zyskało opinię kosztownej, nieelastycznej biurokracji o niewielkiej wartości. W końcu kto czyta te obszerne dokumenty?

Załóżmy, że w projekcie zwinnym nie ma zamiaru tworzenia dokumentacji testów. Jest to bardzo prawdopodobne, więc co właściwie dostarcza testowanie w takich sytuacjach? Jaką wartość w ogóle ma testowanie? Trochę późno na zadawanie tych pytań, prawda?

Gdy testowany jest komponent, podsystem lub cały system, rezultatem jest dowód tego, jak system zachowuje się w określonej sytuacji lub kontekście. Dowody zachowania systemu są gromadzone i zestawiane, a następnie przedstawiane interesariuszom (programistom, użytkownikom, kierownikom itp.), aby mogli podjąć decyzję: naprawić błędy, zintegrować komponent, zaakceptować lub odrzucić funkcjonalność, wydać lub wdrożyć podsystem albo cały system.

Rezultatem testowania jest dowód zachowania systemu wykorzystywany przez interesariuszy do podjęcia decyzji.

Obecnie w niektórych projektach niezbędne jest dostarczenie dokumentacji testów, aby rejestrować sposób określenia zakresu, zaprojektowania, wdrożenia i wykonania testu. Jednak to dowody zachowania systemu są ostatecznym rezultatem mającym wartość dla interesariuszy.

Wartość testowania to poziom zaufania, jakim interesariusze darzą podejmowanie decyzji na podstawie dowodów z testów.

Dowody te mogą być systematycznie gromadzone, zestawiane w tabelach i analizowane w zaawansowanych rozwiązaniach do zarządzania testami, a następnie prezentowane interesariuszom w eleganckiej formie graficznej. Tester może też wykorzystać odręczne notatki, aby ustnie przedstawić właścicielowi produktu przebieg testowania podczas spotkania statusowego.

Niezależnie od sposobu zebrania i przedstawienia dowodów, ostatecznym zadaniem testowania jest ich przekazanie.

Jak

Niezależnie od skali projektu i zastosowanej metodyki testowanie opiera się na określonej serii działań. Przyjrzymy się ogólnemu procesowi oczami testera (lub zespołu), a następnie omówimy niektóre występujące różnice. 

Można wyróżnić tak zwane „działania testowe” oraz działania „wspierające testy” lub „logistyczne”. Aby mieć pewność, że uwzględnisz w planie wszystkie działania, poniższe tabele mogą posłużyć jako przydatne listy kontrolne.

Jednym z działań w powyższej tabeli, którego możesz nie rozpoznawać tak dobrze, jest działanie związane z informacją zwrotną. Z pewnością zdarzyło Ci się już pracować z wymaganiami niskiej jakości. 

Działanie związane z przekazywaniem informacji zwrotnej, przeglądem i kwestionowaniem polega na tym, że testerzy, po przeanalizowaniu i zamodelowaniu wymagania, odkrywają problemy oraz mogą wykorzystać przykłady do pokazania, gdzie wymagania są niekompletne, niejednoznaczne lub sprzeczne.

Jeśli uważasz, że wymagania są słabej jakości, zdecydowanie warto uwzględnić to działanie w planie.

Logistyka testów

Logistyka testów wspiera opisane powyżej działania testowe. O ile przedstawiona przeze mnie lista działań testowych jest dość obszerna, o tyle logistyka testów różni się w każdym projekcie i każdej organizacji. Poniższa lista nie jest więc wyczerpująca. W swoim projekcie poświęć czas na przeanalizowanie każdego działania lub każdej zależności wymaganej do przeprowadzenia testów.

Zasoby (ludzkie, fizyczne)

Często używamy słowa „zasoby” w odniesieniu do osób pracujących przy naszych projektach, co dla niektórych nie jest komfortowe. Ludzie nie są rzeczami, lecz oczywiście istotami ludzkimi. W mniejszych projektach można używać imion i nazwisk, ale w większych organizacjach, gdy zaangażowane są zespoły projektowe, które nie muszą być jeszcze skompletowane, określenie liczby zasobów jest po prostu skrótem oznaczającym liczbę osób.

Co ważniejsze, niekoniecznie liczy się liczba osób – naprawdę istotne są ich kompetencje. Oczywiście ludzie pracują na różne sposoby i zwykle w różnym tempie, dlatego podczas planowania trzeba to uwzględnić.

Oprócz ludzi na różnych etapach będą potrzebne różne zasoby fizyczne, aby testowanie mogło przebiegać. Obejmują one zarówno rzeczy codziennego użytku, jak i wysoce specjalistyczne elementy, a brak któregokolwiek z nich może zagrozić realizacji celu testowania.

Być może masz już szczęście i masz dostęp do w pełni wyposażonego, zarządzanego, dedykowanego laboratorium testowego. Jeśli nie, może być konieczne określenie wszystkiego – od fizycznej przestrzeni i mebli po karteczki samoprzylepne i gumki do mazania – aby zdefiniować środowisko pracy.

W poniższej tabeli przedstawiono niektóre typowe wymagane zasoby. Bez wątpienia Twoja lista będzie się znacznie różnić. 

Po zidentyfikowaniu wszystkich zasobów wymaganych do realizacji planu rozważ, czy w planie trzeba uwzględnić dodatkowe działania związane z ich pozyskaniem.

Twoja sieć wsparcia

Gdyby ludzie i umiejętności potrzebne do przeprowadzenia testów były pod Twoją kontrolą, projekty mogłyby być znacznie prostsze! Jednak niewiele zespołów ma wszystkie potrzebne umiejętności, uprawnienia lub dostęp do niezbędnych zasobów fizycznych. Wiele projektów jest obsadzanych i prowadzonych w stylu zarządzania macierzowego. Kluczowi członkowie zespołu podlegają bezpośrednio kierownikom innych wyspecjalizowanych działów, a ich zaangażowanie będzie ograniczone.

Może być konieczne określenie ustalonej liczby godzin dziennie lub zaplanowanie terminów dostępu do opisanych wyżej specjalistycznych umiejętności. Czasami zostaniesz zapytany, jaki poziom usług jest akceptowalny, np. „na żądania o wysokim priorytecie odpowiemy w ciągu trzydziestu minut” i tak dalej.

Szacunki

Szacowanie w projektach programistycznych to trudne zadanie. Wiele napisano o tym, że szacowanie jest trudne, a nawet niemożliwe. Jednak szacunki są wymagane we wszystkich projektach, a im większy jest projekt, tym bardziej na nich polegamy.

Potrzebujemy szacunków, aby stworzyć harmonogram, ale problem polega na tym, że szacowanie nie zapewnia dokładności. Najlepsze, co możemy zrobić, to obliczyć nakład pracy lub czas trwania z określonym poziomem pewności lub prawdopodobieństwa.

Niektórzy uważają szacowanie za czarną magię, a nawet powstał ruch #NoEstimates, który ma wielu zwolenników. Istnieje wiele sporów dotyczących tego, czy szacowanie może kiedykolwiek być wystarczająco dokładne lub czy jest w ogóle dobrą praktyką w projektach programistycznych.

Szacowanie nigdy nie będzie nauką ścisłą. Jednak na podstawie moich doświadczeń czuję się komfortowo, dzieląc się niektórymi z następujących zasad:

• Wymagania są omylne i nieprecyzyjne.
• Kompetencje, sumienność i pracowitość ludzi są różne.
• Im mniejszy element pracy, tym łatwiej go oszacować; wszędzie, gdzie to możliwe, dziel duże zadania na mniejsze jednostki i agreguj szacunki do większego zadania.
• Szacowanie opiera się na doświadczeniu. Jeśli go nie masz, znajdź sytuacje, w których doświadczenie innych jest istotne i można je dostosować.
• Twój element pracy jest unikatowy, więc szukaj wzorców pracy w innych znanych sytuacjach, w których masz doświadczenie.
• Poproś innych o oszacowanie i porównaj wyniki. Omówienie rozbieżności ujawnia różnice w oczekiwaniach, pewności i dokładności.
• Oszacuj sytuację w najlepszym przypadku, a następnie w najgorszym przypadku. Dobre oszacowanie znajduje się gdzieś pomiędzy nimi.

Oszacuj dzisiaj i rozpocznij pracę; jutro oraz każdego kolejnego dnia, dzięki zdobytej wiedzy, Twoje oszacowanie czasu potrzebnego na ukończenie pracy będzie coraz lepsze.

Zależności, ryzyka i założenia

W poprzednim artykule omówiliśmy ryzyko i rolę testowania w zarządzaniu ryzykiem. Ryzyka związane z produktem dotyczą tego, czy produkt spełnia potrzeby użytkowników w odniesieniu do wymagań funkcjonalnych lub technicznych. W tym miejscu koncentrujemy się na ryzykach dotyczących rzeczywistego planu realizacji.

W projektach zdarzają się problemy. W ramach planowania należy jasno określić, które ryzyka niepowodzenia zostały uwzględnione i na które przygotowano odpowiednie rozwiązania. Obejmuje to trzy aspekty: zależności, ryzyka i reakcje.

Zależności

Zależności obejmują listę wymaganych zasobów ludzkich i fizycznych oraz działań poprzedzających, które muszą zostać ukończone, aby zaplanowane działania zakończyły się powodzeniem i przyniosły oczekiwane rezultaty. 

Każda czynność testowa zawsze wiąże się z zależnościami, niezależnie od tego, czy jest to test systemowy na dużą skalę, czy sesja testów eksploracyjnych funkcji. Zależności obejmują trzy główne aspekty.

Ryzyka

Ryzyko to prawdopodobieństwo, że Twój plan nie powiedzie się podczas realizacji. Ryzyko dotyczy między innymi:

• Twoich szacunków: co może spowodować ich błędność? Większa złożoność, wadliwość, niekompletność lub ciągłe zmiany systemu mogą wpłynąć na Twoje szacunki.
• Niedostępności osób, braku ich doświadczenia lub umiejętności albo braku pełnego zaangażowania w Twoją fazę projektu. Mogą to być członkowie zespołu lub osoby z Twojej sieci wsparcia.
• Niedostępności infrastruktury, takiej jak środowiska testowe, narzędzia (lub szkolenia z ich obsługi) czy przestrzeń biurowa, jej niewłaściwego przygotowania lub wadliwości.
• Nieukończenia działań poprzedzających w terminie (albo ich porzucenia, dostarczenia produktów częściowych lub wadliwych bądź niedostarczenia ich w ogóle).

Reakcje

W przypadku każdego z tych ryzyk należy ocenić prawdopodobieństwo jego wystąpienia, wpływ oraz, jeśli jest on istotny, odpowiednią reakcję lub przewidywaną konsekwencję. Reakcje te zwykle przyjmują jedną z następujących form:

• Założenie: ryzyko uznaje się za wystarczająco małe, aby je zignorować lub uznać za nieistotne. Pozostaje ono jednak monitorowane i zapisane jako założenie (dotyczące dostępności, kompletności itd.).
• Dostosowanie: ryzyko jest istotne, ale istnieje działanie, które może zmniejszyć jego wpływ na plan. Na przykład jeśli testowany system został dostarczony częściowo i brakuje w nim niektórych funkcji, plan można dostosować tak, aby testować tylko dostępne funkcje.
• Konsekwencja: niektórych ryzyk nie można przyswoić ani pominąć. Jeśli system zostanie dostarczony z opóźnieniem, testowanie nie może rozpocząć się przed jego dostarczeniem.

Komunikacja, zaangażowanie i raportowanie postępów

Na koniec przechodzimy do kluczowego, ale często pomijanego aspektu planowania. Możesz przygotować plan projektu zawierający wszystkie zadania, uczestników, zasoby, obowiązki, zależności, terminy, nakład pracy i koszty. Może to być również ustne porozumienie między członkami zwinnego zespołu. 

Tak czy inaczej, plan musi być skutecznie komunikowany wszystkim, aby każdy wiedział, co jest wymagane i kiedy.

Uzgodniony plan jest umową między uczestnikami. Jeśli kierownik zespołu zatwierdza plan, jest to dorozumiane lub wyraźne zobowiązanie do wypełnienia przez jego zespół swojej części umowy.

Plan jest umową między uczestnikami.

W przypadku mniej formalnych projektów może w ogóle nie być pisemnego planu ani zobowiązań. W takich okolicznościach plan jest ciągłą rozmową między członkami zespołu. Zespół spotyka się codziennie, a bieżące zadania ujęte w planie są omawiane w czasie rzeczywistym. Nad czym pracują poszczególne osoby? Czy postęp przebiega zgodnie z oczekiwaniami? Jakich problemów doświadczają poszczególne osoby? Jakie problemy blokują postęp?

We wszystkich projektach cel raportowania postępów jest dwojaki. Oczywiście istnieje potrzeba komunikowania, na jakim etapie bieżących działań projektowych znajduje się każda osoba. Raport o postępach jest jednak również regularnym, cyklicznym sprawdzeniem, czy można utrzymać tempo prac, oraz weryfikacją, czy można polegać na zobowiązaniach uczestników.

Dziękujemy za lekturę, do zobaczenia następnym razem przy… zgadliście — realizacji!

Zapisz się do newslettera The QA Lead, aby otrzymywać powiadomienia o publikacji nowych części serii. Te wpisy są fragmentami kursu Paula „Przywództwo w testowaniu”, który gorąco polecamy, aby lepiej zgłębić ten i inne tematy. Jeśli się na to zdecydujesz, użyj naszego wyjątkowego kodu rabatowego QALEADOFFER, aby uzyskać $60 zniżki od pełnej ceny kursu!