Uwaga redakcji: Witamy w serii „Przywództwo w testowaniu”, której autorem jest guru testowania oprogramowania i konsultant Paul Gerrard. Seria ma pomóc testerom z kilkuletnim doświadczeniem — zwłaszcza pracującym w zespołach zwinnych — doskonalić się w rolach liderów testów i menedżerów.
W poprzednim artykule przedstawiliśmy manifest ryzyka, który ma pomóc menedżerom. W tym artykule zadamy odwieczne pytanie: „Ile testowania wystarczy?”. Spoiler: zależy to od interesariuszy.
Zapisz się do newslettera The QA Lead, aby otrzymywać powiadomienia o publikacji nowych części serii. Te wpisy są fragmentami kursu Przywództwo w testowaniu autorstwa Paula, który zdecydowanie polecamy, aby lepiej zgłębić ten i inne tematy. Jeśli się zapiszesz, użyj naszego ekskluzywnego kodu kuponu QALEADOFFER, aby otrzymać 60 USD zniżki od pełnej ceny kursu!
Ile testowania wystarczy? To klasyczne, pozornie niemożliwe do rozstrzygnięcia, filozoficzne pytanie, które zadają sobie wszyscy testerzy, ponieważ sami są o to pytani przez interesariuszy.
Interesariusze chcą to wiedzieć, ponieważ chcą mieć pewność, że systemy zostały odpowiednio przetestowane, ale ponieważ za to płacą i muszą dotrzymać terminów, chcą również znać potencjalny koszt testowania oraz czas jego trwania.
Dlatego to interesariusze powinni ocenić, ile testowania wystarczy. Twoim zadaniem jako menedżera testów jest dostarczyć im jak najwięcej wartości, pomagając im podjąć decyzję. W tym artykule omówimy:
- Wartość testowania dla interesariuszy
- Teoria kwantowa i teoria względności (nie chodzi o fizykę)
- Używanie właściwego języka
- Szacunki, budżety i negocjacje
Zacznijmy.
Wartość testowania dla interesariuszy
Każdy przeprowadzony przez nas test powinien mieć wartość dla interesariuszy, ponieważ dostarcza dowodów wspierających podejmowanie przez nich decyzji na cztery sposoby:
- Dowody na to, że system spełni cele biznesowe projektu.
- Dowody na to, że system nie ulegnie awarii, a jeśli do niej dojdzie, jej wpływ będzie możliwy do zaakceptowania.
- Dowody umożliwiające odtworzenie i zdiagnozowanie awarii oraz naprawę i ponowne przetestowanie systemu, w którym wystąpiła awaria.
- Dowody wspierające podejmowanie decyzji w kontekście projektu (zaakceptować, wydać, odrzucić itp.).
Naszym celem w testowaniu jest tworzenie testów, które stopniowo zwiększają pokrycie testami systemu w odniesieniu do rozpoznawalnego modelu testowego. Nasze testy powinny wykazać, że system spełni cele biznesowe oraz że ryzyko awarii jest znane i, miejmy nadzieję, możliwe do zaakceptowania.
Z czterech wymienionych wyżej rodzajów dowodów pierwsze trzy stanowią podstawę czwartego. Ostatecznie interesariusze muszą podjąć decyzję opartą na dowodach. To ich decyzja, a nie testerów, dlatego to oni powinni ocenić, czy mają wystarczająco dużo informacji, aby czuć się pewnie. W każdym razie wartość testowania zależy od punktu widzenia interesariusza.
Każdy tester dokonuje wyboru tego, co testować, korzystając z formalnego modelu lub nawet intuicji. Wybory te są dokonywane na podstawie postrzeganej wartości.
Jeśli tester nie jest jednocześnie interesariuszem, zazwyczaj ocenia wartość na podstawie pewnej miary kompletności lub pokrycia. Ewentualnie, jeśli zna sposób myślenia interesariuszy, bierze pod uwagę to, czy test wesprze określoną decyzję akceptacyjną.
Powyższe zasady mają kilka ważnych konsekwencji.
Po pierwsze, jeśli nie znasz sposobu myślenia interesariusza, twoje postrzeganie wartości testu prawdopodobnie nie będzie takie samo jak jego. Jeśli wybierzesz testy bez odniesienia do jego wartości, gdy nadejdzie czas przedstawienia wyników, interesariusze mogą uznać, że w niektórych obszarach mają niewystarczającą ilość danych, a w innych ich nadmiar. Z pewnością nie będą czuć się tak pewnie, jak powinni.
Po drugie, gdy projektujesz lub przeprowadzasz test, jaki jest jego wkład w podejmowanie decyzji przez interesariuszy? Jeśli test nie dostarcza żadnych dodatkowych informacji wspierających decyzję albo interesariuszy nie obchodzi, czy test zakończy się wynikiem pozytywnym czy negatywnym, nie ma dla niego miejsca w planie testów.
W trzecim artykule poświęconym modelom powiedzieliśmy, że używane przez ciebie modele testowe muszą być istotne dla interesariuszy. Jeśli wyniki testów można powiązać z modelami, które interesariusze rozumieją i cenią, docenią oni twój wkład.
Have an account? Log In
Teoria kwantowa i teoria względności
Istnieją jeszcze dwie zasady odnoszące się do wartości i znaczenia testów. Jedną z nich nazywam teorią kwantową, a drugą teorią względności. Te określenia brzmią pretensjonalnie (z pewnością używam ich żartobliwie), ale opisują dwa zjawiska, które leżą u podstaw wszystkich dyskusji na temat wartości, ustalania priorytetów i zakresu testów.
Kiedy przeprowadzamy test, zwykle interpretujemy jego wynik jako zaliczenie albo niezaliczenie. Ocena zaliczenie/niezaliczenie jest wynikiem binarnym – prawda albo fałsz, tak albo nie, jeden albo zero. Wynik testu generuje dyskretną porcję dowodów. Dowody gromadzą się w miarę wykonywania kolejnych testów. Niezależnie od wyniku test stopniowo zwiększa pokrycie naszego modelu testów oraz naszą wiedzę o zachowaniu systemu. Testy, które nie poszerzają naszej wiedzy, nie mają wartości.
Jeśli test nie zwiększa stopniowo pokrycia w jakiś sposób, ma niewielką wartość.
Drugim aspektem jest wartość testu. Jaka jest wartość testu? Czy naprawdę można przypisać pojedynczemu testowi wartość wyrażoną w dolarach, funtach lub euro? Prawdopodobnie nie. Możemy jednak – i często dość łatwo – stwierdzić: „ten test jest bardziej wartościowy niż tamten”.
Załóżmy, że korzystamy z modelu pokrycia kodu, takiego jak pokrycie instrukcji. Możemy uruchomić test, który wykonuje pięć wierszy kodu albo pięć tysięcy wierszy kodu. Jaka jest wartość każdego z nich? Trudno powiedzieć. Jeśli jednak naszym celem jest pokrycie instrukcji, drugi test ma większą wartość.
Nie możemy przypisać bezwzględnej wartości żadnemu testowi, ale zwykle możemy porównywać testy i wywnioskować względną wartość każdego z nich. Oznacza to, że jeśli działamy pod presją czasu, zwykle możemy stwierdzić, że jeden test ma mniejszą wartość niż inny, a zatem w razie potrzeby wyłączyć pierwszy test z zakresu.
Możemy porównywać wartość testów, ale tylko wtedy, gdy wynikają z tego samego modelu.
Musimy jednak podkreślić, że takie porównania mają znaczenie tylko wtedy, gdy testy korzystają z tego samego modelu. Test obejmujący szeroki zakres ekstremalnych warunków w procesie prawdopodobnie ma większą wartość niż test ścieżki „bezpośredniej”. Na przykład testów kompleksowego procesu od początku do końca nie można bezpośrednio porównywać z testami jednostkowymi kluczowych komponentów.
Chociaż teorie kwantów i względności mogą nie mieć bezpośredniego zastosowania do testowania, zasady adaptacyjności i perspektywy już tak. Znajdź narzędzie do zarządzania testami zgodne z tymi zasadami, aby zoptymalizować strategię testowania.
Używanie właściwego języka
Skoro ustaliliśmy już, kto odpowiada za decyzję, „ile testowania wystarczy”, jak my, sumienni testerzy, możemy wspierać podejmowanie tej decyzji?
Zauważmy, że nasze podejście do wartości testów jest bardzo podobne do naszej oceny ryzyka. Jak omówiono w poprzednim artykule, bardzo trudno jest przypisać liczbowe wartości skali lub ekspozycji na ryzyko. Zwykle można jednak porównać jedno ryzyko z innym i uszeregować je, aby podejmować decyzje dotyczące ryzyk objętych zakresem testów.
Posługując się językiem ryzyka, testerzy będą słyszani przez kierownictwo.
Liderzy zespołów programistycznych często wydają się być słuchani przez menedżerów, nawet gdy mówią językiem technicznym. Różnica polega na tym, że przedstawiają technologię jako ekscytującą i korzystną. Kiedy testerzy mówią własnym językiem technicznym – o „urzędniczych” szczegółach testów, takich jak statystyki incydentów – przekaz ma tendencję do bycia negatywnym, a menedżerzy mogą się nudzić lub irytować.
Kierownictwo może już uważać testerów za nieco nudny gatunek, ale można argumentować, że wynika to z faktu, iż wielu menedżerów tak naprawdę nie rozumie, czym zajmują się testerzy i jaką wartość wnoszą. Dlatego testerzy powinni podnieść swój język do poziomu kierownictwa.
Testowanie oparte na ryzyku przemawia do osób zarządzających użytkownikami i projektami w ich języku.
Są to osoby, które w dużej mierze myślą w kategoriach ryzyka i korzyści. Jeśli testerzy będą zwracać się do nich w podobny sposób, kierownictwo z większym prawdopodobieństwem ich wysłucha, a tym samym podejmie lepsze decyzje. Odnosząc testy do celów projektu, możemy skupić uwagę na rezultatach o największej wartości dla interesariuszy, dzięki czemu poświęcimy czas na testowanie najważniejszych elementów.
Co więcej, w miarę postępów testowania możemy wykazać, że najcenniejsze korzyści są już dostępne. Decyzja o wydaniu jest ostatecznie oceną tego, czy uzyskane korzyści przewyższają ryzyko, dlatego testowanie będzie dostarczać kierownictwu lepszych danych, na których będzie ono mogło oprzeć swoje decyzje.
Używaj języka ryzyka (i korzyści) do określania zakresu, planowania oraz raportowania postępów testowania.
Testerzy oczywiście muszą rozmawiać językiem technicznym z programistami i innymi pracownikami technicznymi. Na przykład jakość raportów incydentów jest kluczowym czynnikiem umożliwiającym szybkie i niezawodne usuwanie usterek. Mówię po prostu, że rozmawiając z kierownictwem, tester powinien mówić o ryzykach, którym zaradzono, oraz o ryzykach pozostających do rozwiązania, zamiast o testach, incydentach i usterkach.
More Articles
Szacunki, budżety i negocjacje
Na początku nowego projektu kierownik projektu pyta: „Muszę odpowiednio wcześnie zaplanować testowanie i zasoby, czy możesz podać mi szacunkową liczbę osób oraz czas potrzebny na przeprowadzenie testów systemowych?”
Zastanawiasz się nad tym i idziesz porozmawiać z szefem.
„Potrzebuję sześciu testerów na osiem tygodni.”
Kierownik projektu przez chwilę się zastanawia i konsultuje swój wstępny harmonogram oraz plan zasobów.
„Możesz mieć czterech testerów przez sześć tygodni i to wszystko.”
Sprzeciwiasz się i mówisz: „Ale to potrwa dłużej niż sześć tygodni! Będzie kosztować więcej, niż przeznaczyliście na testowanie tego systemu. System jest większy niż ostatnim razem. Jest bardziej skomplikowany. Z pewnością tym razem ryzyko ograniczenia testów jest dla nas zbyt duże. To po prostu za mało.”
Jednak kierownik jest nieugięty i mamrocze coś o innych zależnościach, wyższych przełożonych i tak dalej…
Jak myślisz, jaki był sens sporządzania estymacji, skoro kierownik od początku wiedział, jaki musi być budżet? Jakie znaczenie dla stojącego przed nami zadania ma arbitralnie ustalony budżet? Dlaczego oni nigdy nie traktują testowania poważnie? Deweloperzy zawsze dostają tyle czasu, o ile proszą, prawda? To nie wydaje się sprawiedliwe.
Możesz czuć się pokrzywdzony i mieć wrażenie, że podważa się Twój profesjonalny osąd. Problem polega jednak na tym — i zawsze polegał — że budżet na testy w tej sytuacji był ustalony z góry. Wszystko, co możesz zrobić, to ustalić, jakie testy będą najlepsze lub najbardziej wartościowe i które zmieszczą się w Twoim budżecie.
Często jednak PM naprawdę chce wiedzieć, ile czasu coś zajmie, aby można było odpowiednio dostosować plan. Jeśli uważasz, że bierzesz udział w negocjacjach, potrzebujesz argumentów do targowania się. Musisz również omawiać rezultaty planu, a nie dane wejściowe. Zakres jest rezultatem planowania, a nakład pracy, który stosujesz, jest daną wejściową.
Musisz negocjować zakres.
Negocjacje dotyczące budżetu na testy powinny zawsze koncentrować się na zakresie, a nie na nakładzie pracy.
Zakres może być przedstawiony w jednym lub kilku formatach, a sposób jego prezentacji i omawiania będzie się różnić, ale oto kilka typowych wzorców. Niezależnie od tego, jaki masz zakres, wykorzystasz go jako podstawę swojej estymacji i uzasadnienia jej:
Zakres jako wykaz wymagań lub funkcji
Gdy estymacja zostanie zmniejszona o 30%, zapytaj: „Których 30% systemu nie powinienem testować?”
Zakres jako wykaz ryzyk
Gdy estymacja zostanie zmniejszona o 30%, zapytaj: „Które ryzyka interesariuszy należy usunąć z planu?”
Zakres jako model tabelaryczny lub graficzny
Gdy estymacja zostanie zmniejszona o 30%, zapytaj: „Którym ścieżkom/podróżom/elementom powinienem powiedzieć interesariuszom, że nie będą testowane?”
Mam nadzieję, że widzisz, co się tutaj dzieje.
- Zakres testowania opiera się na pewnym modelu, który został najpierw omówiony i uzgodniony z interesariuszami. Zakres ten jest wstępny, zależny od dostępności zasobów i czasu, i powinieneś ich o tym poinformować.
- Wykonujesz estymację na podstawie tego wstępnego zakresu. Użyj modelu (ryzyk, wymagań, procesu biznesowego lub dowolnego innego modelu), aby wyznaczyć cel pokrycia, policz elementy pokrycia i na tej podstawie wykonaj estymację.
- Porozmawiaj z kierownikiem projektu. Jeśli estymacja jest zbyt wysoka, wykorzystaj powyższe odpowiedzi, aby rozpocząć dyskusje z interesariuszami.
Jako tester lub kierownik testów nie jesteś w dobrej pozycji do negocjowania testowania z kierownikiem projektu. Interesariusze mają swoje obawy, a jeśli udostępnisz im modele definiujące zakres testowania, będą mieli własne opinie, zaakceptują zakres i będą mogli go bronić. Interesariusze są również odpowiedzialni za uzasadnienie budżetu swojego systemu, dlatego najlepiej potrafią wyważyć koszt testowania i potrzebę uwzględnienia swoich obaw.
Kilka tematów do przemyślenia
Zastanów się, kto w Twoich projektach bierze odpowiedzialność za zakres testowania, które ma zostać przeprowadzone:
- Czy to Ty, jako tester, definiujesz zakres i ilość testowania?
- Czy kierownik projektu ustala budżet, a Ty robisz, co możesz, w przydzielonym Ci czasie?
- Czy zakres jest negocjowany z kierownikiem projektu i interesariuszami w celu uzgodnienia równowagi między nakładem pracy a zakresem testowania, które ma zostać przeprowadzone?
Jednym z kluczowych obowiązków testera jest upewnienie się, że projekt jest świadomy podejmowanych ryzyk związanych z produktem, oraz ich udokumentowanie. Tylko wtedy, gdy ryzyka są widoczne, kierownictwo może rozpoznać ryzyka podejmowane w wyniku ograniczania testowania.
Nie ma wzoru określającego właściwą ilość testowania. W większości środowisk poziom testowania może zostać określony wyłącznie na podstawie konsensusu między kierownictwem projektu, sponsorami po stronie klienta, deweloperami, specjalistami technicznymi i testerami — testy uznaje się za objęte zakresem, jeśli odnoszą się do istotnych ryzyk.
Wystarczający zakres testowania powinien zostać określony na podstawie konsensusu, przy czym tester ułatwia ten proces i wnosi do niego informacje.
Zapisz się do newslettera The QA Lead, aby otrzymywać powiadomienia o publikacji nowych części serii. Te wpisy są fragmentami kursu Przywództwo w testowaniu 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 kuponu QALEADOFFER, aby uzyskać zniżkę $60 od pełnej ceny kursu!
Powiązane artykuły:
