Testowanie oprogramowania to nasza codzienność i zawsze przyglądamy się ewolucji standardów i ogólnostosowanych wytycznych. Końcówka 2021 roku przyniosła nową wersję drugiej oraz trzeciej części „testerskiej” normy ISO/IEC/IEEE 29119 – normy, która opisuje: jak projektuje się proces testowy, techniki projektowania testów i dokumentacje, czyli wszystko, co jest związane z testowaniem oprogramowania niezależnie od branży.
Nowa wersja normy 29119–3:2021 została oficjalnie opublikowana pod koniec października 2021 roku. Pierwsze co rzuca się w oczy to jej „odchudzenie”. Ze 127 stron w wersji z 2013 roku do „tylko” 84 stron w obecnej wersji. Jest to głównie zasługa korekty redakcyjnej punktów znajdujących się do tej pory przed każdym rozdziałem. Zamiast je powielać, zostały objaśnione tylko raz, co znacząco poprawia przejrzystość treści tej normy. Zmian jest jednak znacznie więcej i dużo bardziej znaczących niż tylko redakcyjne korekty.
Jedną z najważniejszych zmian jest usunięcie dokumentu Organizacyjna Strategia Testowania (Organizational Test Strategy) i zastąpienie go dokumentem Organizacyjne Praktyki Testowania (Organizational Test Practices). Są w nim dwa nowe rozdziały dedykowane osobno poziomom oraz typom testów objętych zakresem opisywanym przez dokument. Ponadto zrezygnowano z podziału na podprocesy, jak to miało miejsce w poprzedniej wersji, a zastąpiono je podziałem na poziomy lub typy testowania. Co ciekawe podrozdziały opisujące każdy poziom lub typ testów są praktycznie identyczne jak w przypadku podprocesów. Nowością jest dodanie rozdziału dedykowanego danym testowym, które są koniecznie do przeprowadzenia danego poziomu lub typu testów. Co ważne, Polityka Testów jako dokument nadrzędny pozostała w niezmienionej formie.
Kolejne zmiany dotknęły Planu Testów. Podobnie jak w Organizacyjnych Praktykach Testowania, Plan Testów również ma odniesienie do konkretnego poziomu lub typu testów, a nie podprocesu jak poprzednio. Dodano tutaj również rozdziały związane z omówieniem podstawy testów, poziomami oraz typami testów przeprowadzanych w ramach zakresu opisywanego przez Plan Testów. Nowością są również kryteria startu oraz zakończeniu poszczególnych procesów testowych (takich jak planowanie, projektowanie i implementacja testów itd.), a także rozdział o stopniu niezależności testerów.
W nowej wersji normy usunięty został również rozdział o Specyfikacji Testów (Test Design Specification). Jak wyjaśniają autorzy normy, ma to związek z wątpliwościami, jakie pojawiały się na etapie projektowania warunków testowych i tego jak są one powiązane z przypadkami testowymi. W obecnej wersji normy, dokument ten został zastąpiony Specyfikacją Modelu Testowego (Test Model Specification). W tym wypadku model jest rozumiany na przykład jako diagram przejść między stanami, klasy równoważności albo zbiór wartości brzegowych opisujący testowane oprogramowanie. Wydaje się, że to podejście jest zdecydowanie bliższe praktyce, niż miało to miejsce w przypadku pracy z warunkami testowymi.
Zmiana dotknęła również rozdział o Specyfikacji Przypadku Testowego (Test Case Specification), gdzie już na samym początku dowiadujemy się, że przypadki testowe powinny wynikać z przyłożenia odpowiednich technik projektowania testów do posiadanego modelu.
Kolejną konsekwencją przejścia z warunków testowych na model jest uproszczenie procesu projektowania testów z sześciu do czterech kroków opisanych w drugiej części normy 29119.
Poza redakcyjnymi zmianami pojawiło się również kilka istotnych zmian mających wpływ na strukturę jak i samą zawartość poszczególnych dokumentów testowych. Z tego powodu warto zapoznać się z nową wersją normy oraz nanieść zmiany na obecnie posiadane dokumenty testowe, aby zachować częściową lub pełną zgodność z obecną normą.
W Solwicie codziennie, w ramach testowania oprogramowania przeprowadzamy tysiące różnego typu testów (automatyczne, funkcjonalne czy niefunkcjonalne). Jako Platynowy Partner ISTQB zawsze inspirujemy się w działaniu najlepszymi światowymi praktykami i normami. Wspieramy także naszych partnerów w procesie certyfikacji oprogramowania o charakterze ”safety – critical”.
