Przywództwo w testowaniu: modelowanie i pokrycie

W świecie testowania oprogramowania skuteczne przywództwo wie, jak wyznaczyć jasny kierunek, aby strategie testowania były zgodne z celami rozwoju. W miarę jak systemy oprogramowania stają się coraz bardziej złożone, tradycyjne metody testowania mają trudności z dotrzymaniem im kroku.

Właśnie tutaj kluczowe znaczenie zyskują innowacyjne podejścia, takie jak modelowanie testów i analiza pokrycia. Praktyki te zapewniają zespołom pokrycie ścieżek krytycznych i przypadków brzegowych, a także umożliwiają lepszą współpracę, zmniejszenie ryzyka i szybsze dostarczanie.

W tym artykule przyjrzymy się temu, co oznacza przywództwo uwzględniające modelowanie i pokrycie. Omówimy, w jaki sposób liderzy testów mogą wykorzystywać te strategie do optymalizacji procesów, podnoszenia jakości produktu i zapewnienia kompleksowego pokrycia testami — jednocześnie wspierając kulturę doskonałości i odpowiedzialności. Niezależnie od tego, czy jesteś menedżerem ds. zapewniania jakości, liderem zespołu, czy po prostu chcesz pogłębić swoją wiedzę na temat przywództwa w testowaniu, ten przewodnik wyposaży Cię w praktyczne spostrzeżenia i techniki, które pomogą podnieść poziom testowania.

Przejdźmy do rzeczy.

Czym jest model testów?

Testowanie jest procesem, w którym tworzymy modele mentalne środowiska, programu, ludzkiej natury i samych testów. Każdy model jest używany do chwili, gdy uznamy, że zachowanie jest prawidłowe, albo do momentu, gdy model przestaje być wystarczający do danego celu.

Boris Beizer, Techniki testowania oprogramowania, 1990

Projektowanie testów to proces, w ramach którego spośród całej gamy dostępnych możliwości wybieramy testy, które naszym zdaniem będą najbardziej wartościowe dla nas i naszych interesariuszy. Modele testów pomagają nam wybierać testy w sposób systematyczny i mają fundamentalne znaczenie dla testowania.

Sposób, w jaki testerzy wykorzystują modele:

1. Identyfikujemy i analizujemy źródła wiedzy, aby budować modele testów.
2. Wykorzystujemy te modele do kwestionowania i weryfikowania naszych źródeł, udoskonalając zarówno źródła, jak i modele.
3. Wykorzystujemy te modele do planowania testowania, a także rozwoju.

Mając określoną misję testowania, naszym pierwszym zadaniem jest zidentyfikowanie źródeł wiedzy. Mogą nimi być:

• Dokumentacja: specyfikacje, projekty, wymagania, standardy, wytyczne i tym podobne.
• Ludzie: interesariusze, użytkownicy, analitycy, projektanci, programiści i inni.
• Doświadczenie: własna wiedza i doświadczenie dotyczące podobnych (lub odmiennych) systemów, własne preferencje, uprzedzenia, przypuszczenia, przeczucia, przekonania i obciążenia poznawcze.
• Nowy system: system testowany, jeśli istnieje, jest dostępny i można uzyskać do niego dostęp.
• Stary system: system, który ma zostać zastąpiony, jest oczywiście źródłem informacji — w niektórych obszarach funkcjonalności może służyć jako punkt odniesienia dla oczekiwanego zachowania.

Należy pamiętać, że wszystkie nasze źródła wiedzy są omylne i niekompletne, podobnie jak nasze modele. Testerzy wykorzystują doświadczenie, umiejętności i osąd, aby przesiać te źródła, porównać je, skonfrontować i poddać krytycznej ocenie, a następnie osiągnąć konsensus. 

Wszystkie modele są błędne, ale niektóre są użyteczne

George Box, ekonomista.

Model testów może być listą kontrolną lub zestawem kryteriów. Może też być diagramem wyprowadzonym z dokumentu projektowego albo analizą tekstu narracyjnego. Wiele modeli testów nigdy nie zostaje zapisanych na papierze — mogą to być modele mentalne tworzone specjalnie po to, aby kierować testerem podczas badania systemu poddawanego testom.

Celem modeli jest upraszczanie złożonych sytuacji poprzez pomijanie szczegółów, które w danym momencie nie są istotne. Wykorzystujemy modele do upraszczania problemu — na przykład do wyboru elementów, które należy przetestować. Model kształtuje nasz sposób myślenia, a testy wybieramy, identyfikując wystąpienia pewnego kluczowego aspektu modelu.

Możemy wybierać gałęzie na schemacie blokowym lub diagramie przepływu sterowania, przejścia między stanami w modelu stanów, granice w modelu domeny wejściowej (lub wyjściowej) oraz scenariusze wyprowadzone z historyjek użytkownika zapisanych w języku dziedzinowym Gherkin.

Należy jednak zachować ostrożność, ponieważ czasami modele pomijają elementy, których pominięcie nie jest bezpieczne — być może model nadmiernie upraszcza daną sytuację — i musimy zwracać na to uwagę. Aby zwiększyć skuteczność modeli testów, kluczowe znaczenie ma wykorzystanie specjalistycznego oprogramowania do zarządzania testami.

Jeśli nasze źródła nie dostarczają nam bezpośrednio modeli, musimy je stworzyć. Na przykład gdy wymagania są przedstawione w formie tekstu narracyjnego, musimy wykorzystać język wymagań, aby wyprowadzić funkcje i logikę ich działania. Może to być trudne dla programistów i testerów i często jest wspólnym wysiłkiem, ale musimy wytrwać.

Wykorzystanie modeli do testowania

Wykorzystujemy modele testów do:

• Upraszczaj kontekst testu. W modelu pomijane są szczegóły nieistotne lub nieznaczące.
• Skupiaj uwagę na jednym aspekcie zachowania systemu. Mogą to być funkcje krytyczne lub ryzykowne, aspekty techniczne, interesujące operacje użytkownika albo elementy konstrukcji lub architektury systemu.
• Generuj zestaw unikalnych testów (w kontekście modelu), które są zróżnicowane (w odniesieniu do tego modelu).
• Umożliwiaj szacowanie, planowanie, monitorowanie i ocenę kompletności testowania (pokrycia).

Z punktu widzenia testera model pomaga nam rozpoznać aspekty systemu, które mogą stać się przedmiotem testu.

Modele i pokrycie

Pokrycie to termin używany do opisania dokładności lub kompletności naszego testowania w odniesieniu do modelu testowego. Element pokrycia to coś, co chcemy uwzględnić w naszych testach.

W idealnej sytuacji nasz model testowy powinien identyfikować elementy pokrycia w obiektywny sposób. Gdy zaplanujemy lub wykonamy testy obejmujące elementy zidentyfikowane przez nasz model, możemy określić osiągnięte pokrycie ilościowo i, jako proporcję wszystkich elementów modelu, wyrazić je w procentach.

Każdy model, który umożliwia identyfikację elementów pokrycia, może być używany.

Modele są często graficzne; przykładami mogą być schematy blokowe, przypadki użycia, diagramy sekwencji i tak dalej. Te oraz wiele innych modeli zawierają elementy (lub bloby) połączone liniami albo strzałkami. Zwykle nazywa się je grafami skierowanymi. 

Wyobraźmy sobie model graficzny składający się z blobów i strzałek. Można zdefiniować co najmniej dwa cele pokrycia:

• Pokrycie wszystkich blobów
• Pokrycie wszystkich strzałek
• I tak dalej

Zatem każdy model będący grafem skierowanym można traktować w ten sam sposób.

Modele nieformalne mają zwykle postać list kontrolnych lub kryteriów używanych do przeprowadzenia burzy mózgów i utworzenia listy elementów pokrycia, zainicjowania pomysłów na testowa nie albo przeprowadzenia testów w ramach sesji testów eksploracyjnych. Listy lub kryteria mogą być zdefiniowane wcześniej, przygotowane jako część planu testów albo przyjęte podczas sesji testów eksploracyjnych.

Modele nieformalne różnią się od formalnych tym, że wyprowadzenie elementów pokrycia zależy od doświadczenia, intuicji i wyobraźni praktyka, dlatego pokrycia z użyciem tych modeli nigdy nie można określić ilościowo. W odniesieniu do tych modeli nigdy nie możemy wiedzieć, co oznacza pełne pokrycie.

Modele upraszczają, więc używaj więcej niż jednego

Dobry model zapewnia sposób rozumienia złożoności i osiąga to częściowo przez wykluczanie szczegółów, które nie są istotne. Model może wykorzystywać pojęcie stanu, trybów awarii lub przepływów, kombinacji danych wejściowych, wartości dziedzinowych i tak dalej. 

Jeden model nigdy nie wystarczy do pełnego przetestowania systemu. Wszystkie modele są kompromisem, dlatego potrzebujemy wielu modeli. Pojęcie to zwykle określa się jako „zróżnicowane półśrodki”. Oznacza to, że do prawidłowego przetestowania systemu potrzebujemy różnorodnych modeli częściowych.

Chociaż zwykle nie opisuje się tego w ten sposób, etapy testowania w projekcie kaskadowym wykorzystują modele z różnych perspektyw. Testy jednostkowe, integracyjne podsystemów, na poziomie systemu i testy użytkownika mają odmienne cele; każdy z nich korzysta z innego modelu i innej perspektywy – właśnie stąd bierze się różnorodność.

Wykorzystywanie modeli do zarządzania

Modele są podstawą testowania, a także zarządzania testami. Obejmują cztery kluczowe aspekty:

• Zaangażowanie interesariuszy
• Zakres
• Pokrycie
• Szacowanie i monitorowanie postępów

Zaangażowanie interesariuszy

Planując testy i określając ich zakres oraz wyjaśniając interesariuszom postępy i znaczenie pokrycia, musimy korzystać z modeli zrozumiałych i istotnych z punktu widzenia celów interesariuszy.

Jeśli planujemy test użytkownika, prawdopodobnie przyjmiemy przepływ procesu biznesowego jako nasz model i szablon do śledzenia ścieżek służących do sprawdzania funkcji systemu, które mają znaczenie dla użytkownika. Jeśli testujemy integrację komponentów usług w imieniu architekta technicznego, jako podstawę testów wykorzystamy model architektury, diagramy współpracy, specyfikacje interfejsów itd. Jeśli testujemy funkcje zdefiniowane przez użytkowników, wykorzystamy historyjki użytkownika, które powstały w wyniku wcześniejszych wspólnych prac nad wymaganiami.

Jeśli interesariusze nie rozumieją modeli, nie będą rozumieć testów, ufać im ani w nie inwestować. Mogą nawet nie ufać tobie.

Zarządzanie zakresem

Pierwszym działaniem w ramach dyscypliny myślenia systemowego jest zdefiniowanie granicy systemu. W testowaniu pierwszy zdefiniowany model pomoże określić zakres testów. Poniższy diagram przedstawia schemat architektury systemu – „system systemów” – w organizacji.

Każdy system (koncentryczne okręgi) znajduje się w obszarze aplikacji, takim jak CRM, księgowość czy strona internetowa. Wszystkie systemy i obszary aplikacji znajdują się wewnątrz „systemu systemów”. Oczywiście model nie zawiera szczegółów, ale wyraźnie widać, jak każdy system wpisuje się w całą architekturę.

Bez trudu moglibyśmy na przykład zdefiniować zakres naszych testów jako systemy ERP.

Na drugim diagramie poniżej dodaliśmy więcej szczegółów do architektury systemu i zaproponowaliśmy trzy sposoby bardziej precyzyjnego zdefiniowania zakresu.

• Systemy zacieniowane na żółto to tak zwane systemy będące źródłem danych. Systemy te mogą na przykład współdzielić bazę danych, a zmiany w schemacie bazy danych mogłyby niekorzystnie wpłynąć na dowolny z tych systemów – i objąć go zakresem testów.
• Systemy ograniczone fioletową linią mogą współdzielić pewne funkcje lub infrastrukturę – być może wszystkie korzystają ze wspólnego zestawu usług internetowych, tego samego systemu komunikatów albo działają na tym samym serwerze.
• Przerywana niebieska linia oznacza podróż użytkownika, która wykorzystuje systemy połączone tą linią. Być może podróż użytkownika uległa zmianie, a naszym celem jest spójność i dokładność przepływu danych między tymi systemami.

Model pomaga zdefiniować zakres testu, a także wyjaśnić go interesariuszom w kategoriach, które rozumieją, doceniają i (miejmy nadzieję) akceptują.

Zarządzanie pokryciem testami

Pomiar pokrycia może pomóc w lepszym zarządzaniu testami. Jeśli nie mamy pojęcia o pokryciu, możemy nie być w stanie odpowiedzieć na pytania takie jak: „co zostało przetestowane?”, „czego nie przetestowano?”, „czy już skończyliśmy?”, „ile testów pozostało?”. Jest to szczególnie kłopotliwe dla kierownika testów.

Planowane przez nas pokrycie jest naturalnym kolejnym krokiem po zdefiniowaniu zakresu.

Modele testów i miary pokrycia można wykorzystywać do definiowania ilościowych lub jakościowych celów dotyczących projektowania i wykonywania testów. W różnym stopniu możemy używać takich celów do planowania i szacowania. Możemy także mierzyć postępy i wnioskować o dokładności lub kompletności zaplanowanych albo wykonanych testów. Musimy jednak zachować dużą ostrożność w przypadku wszelkich ilościowych miar pokrycia lub wartości procentowych, których używamy.

Miara pokrycia (oparta na formalnym modelu testów) może być obiektywnie obliczona, ale nie istnieje żaden wzór ani prawo mówiące, że pokrycie na poziomie X oznacza jakość na poziomie Y lub zaufanie na poziomie Z. Wszystkie miary pokrycia dostarczają jedynie pośrednich, jakościowych i subiektywnych informacji na temat dokładności lub kompletności naszych testów. Nie istnieje znacząca zależność między pokryciem a jakością lub akceptowalnością systemów.

Ilościowe cele dotyczące pokrycia są często stosowane do definiowania kryteriów wyjścia oznaczających zakończenie testów, ale kryteria te są arbitralne. Bardziej rygorystyczny cel pokrycia może wygenerować dwa razy więcej elementów do pokrycia. Jednak dwa razy większa liczba testów, kosztujących dwa razy więcej, nie sprawia, że system jest przetestowany w dwukrotnie większym stopniu ani dwa razy bardziej niezawodny. Taka interpretacja jest pozbawiona sensu i nierozsądna.

Czasami formalne modele wykorzystywane do definiowania i budowania systemu mogą zostać narzucone testerom, aby używali ich do określania celów pokrycia. Innym razem testerzy mogą dysponować niewielką ilością dokumentacji i muszą samodzielnie tworzyć własne modele. Wybór dowolnego modelu testowego i celu pokrycia jest w pewnym stopniu arbitralny i subiektywny. W związku z tym nieformalne modele testowe i miary pokrycia mogą być równie użyteczne jak uznane, formalne modele.

Szybkie ćwiczenie z tworzenia modelu

Na zakończenie krótkie ćwiczenie. W poniższych przykładach naszkicuj, jak według Ciebie może wyglądać model – tylko jego kształt – w formie obrazu/schematu, tabeli lub listy:

• Użytkowników interesują kompleksowe ścieżki przechodzenia przez system.
• Usługa przesyłania wiadomości może znajdować się w jednym z czterech stanów: wyłączona, uruchomiona, uruchamiana i wyłączana.
• Kalkulator składki ubezpieczeniowej ma 40 wartości wejściowych, które łącznie wpływają na obliczenia; między niektórymi danymi wejściowymi istnieją zależności.
• Proces wyodrębniania, transformacji i ładowania ma siedem etapów. Po wyodrębnieniu każdy etap odrzuca rekordy, wysyła je do pliku oczekujących rekordów albo przekształca je i przekazuje do następnego etapu. Ostatni etap to proces ładowania, który obsługuje odrzucenia. Przetestuj, czy wszystkie wyodrębnione rekordy zostały uwzględnione.

Zapisz się do newslettera The CTO Club, aby uzyskać więcej informacji na temat testowania!