Archaizmy sylabusa ISTQB Poziomu Podstawowego

Archaizmy sylabusa ISTQB Poziomu Podstawowego
Sylabus ISTQB Poziomu Podstawowego, pomimo aktualizacji, nie dogonił współczesnego świata IT. Oto lista grzechów nowej wersji najważniejszej testerskiej publikacji wszechczasów.

Chociaż moje nazwisko jest wymienione wśród wielu autorów sylabusa, to mam pewien niedosyt, że nie udało mi się przekonać członków zespołu redakcyjnego do prawdziwej rewolucji w sylabusie i uczynienia z niego aktualnej i wartościowej pigułki wiedzy.

 

1. Słownictwo, czyli nikt tak nie mówi

Nawet wśród testerów wiele z pojęć promowanych przez sylabus się nie przyjęło jak "jarzmo" czyli "mock", "testy modułowe", które wszyscy nazywają "jednostkowymi"czy subtelne słówko "pielęgnacja" tak ochoczo zastępowane przez "utrzymanie".

Były też postulaty by zrezygnować z rozróżnienia na "błąd", "defekt" i "awarię", bo w języku duńskim to jest jedno słowo. Polscy testerzy ciągle "raportują błędy", a nie jak chciałoby ISTQB "defekty".

 

2. "Dlaczego testowanie jest niezbędne?", czyli dlaczego Słowacki wielkim poetą był

W dzisiejszym świecie jest wiele obszarów, gdzie testowanie (w definicji ISTQB) nie tylko nie jest niezbędne, ale jest też eliminowane. W świecie DevOps mierzy się czy wypuszczanie wadliwego oprogramowania jest mniej kosztowne niż testowanie. I podejmuje się to ryzyko. Pytanie brzmi jak szybko zorientujemy się, że mamy awarię i jakie szkody nam to wyrządzi. Zamieniamy naszych użytkowników w armię nieświadomych testerów i monitujemy, jakie awarie udało się im wywołać.

 

3. Paradoks pestycydów, który nie jest żadnym paradoksem

Jedna z zasad testowania powołuje się na paradoks pestycydów. Używając tych samych pestycydów (przypadków testowych) przed dłuższy czas tracą one zdolność do eliminacji szkodników (znajdywania defektów), ponieważ podatne szkodniki zostają wybite (defekty zostaną znalezione), a niepodatne (nie pokryte przez testy) przetrwają i się rozmnażają. Nie możemy więc mówić o paradoksie. Tłumaczy to Adam Roman >>

 

4. Kontrola jest najwyższą formą zaufania

Z wielu kart sylabusa wyziera dążenie do ciągłego monitorowania i kontrolowania pracy testera. Miary, obowiązki raportowania, przypadki testowe - wszystko to układa się w obraz, w którym kierownik testów poświęca większość swojego czasu na sprawdzanie czy tester oby na pewno testuje.

 

5. Testy = przypadki testowe

A wcale, że nie. Test może mieć wiele notacji. Może to być szczegółowy warunek testowy, idea testowa, element listy kontrolnej, itp. Nie musi to być formalny przypadek testowy z oczekiwanym rezultatem, warunkiem początkowym i całą tą rozbudowaną formatką. O ile bardziej uniwersalny byłby proces testowy, gdy dać mu trochę przestrzeni na mniej sformalizowane testowanie?! Ostał się niestety ciężki, biurokratyczny proces.

 

6. Modele cyklu życia, czyli o archeologii IT

Modele sekwencyjne ciągle mają się dobrze w IT i warto o nich mówić. Po drodze pojawiły się kolejne, które pewnie miały jakiś wpływ na współczesne modele wytwarzania oprogramowania, ale sylabus nie tłumaczy jaki. Po co więc czytelnikom przypomina się o RUPie albo RADzie? Kto ich używa, ręka do góry. Nie widzę.

 

7. 4 poziomy testów rozpisane na 9 stronach

Praktycznie 15% sylabusa zajmują poziomy testowania. Czy aż tak szczegółowe ich poznanie jest testerowi naprawdę niezbędne? Przecież w projektach niezmiernie rzadko słyszymy stwierdzenie: "Dziś będę testował systemowo". Mówi się raczej "dziś przeglądam unity", "eksploruję GUI", "weryfikuję API".

 

8 Testowanie regresywne, czyli co?

Mamy następujące typy testów - funkcjonalne, niefunkcjonalne oraz białoskrzynkowe. Skoro w ramach testowania regresywnego będziemy uruchamiali zarówno testy funkcjonalne, niefunkcjonalne, jak i białoskrzynkowe, to dlaczego testowanie regresywne jest czwartym typem testów?

 

9. Mało Ci procesów? Oto proces przeglądu.

Jedna z najmniej wartościowych części sylabusa, bo tylko ekstremalnie sformalizowane organizacje weryfikują swoje produkty w ten sposób. A Ty byłeś już skrybą albo moderatorem?

 

10. Testowanie eksploracyjne jako uzupełnienie.

James Bach opisał 20 lat temu definicję testowania eksploracyjnego uwzględniając, że jest to technika. Wiele wody upłynęło i autor zdążył już swoją definicję przepisać kilkukrotnie, uznać, że eksploracja jest metodą, a następnie uznać, że nie ma czegoś takiego jak testowanie eksploracyjne, bo każde testowanie jest eksploracją. Jednak ISTQB twardo powiela pierwotną definicję, a najlepiej gdyby testowanie eksploracyjne stanowiło uzupełnienie do przypadków testowych.

 

Niestety przedstawione tu grzechy nie są jedyne, są jeszcze pomniejsze grzeszki, od których roi się w sylabusie. Daleki byłbym jednak od stwierdzenia, że najnowsza wersja sylabusa jest straconą szansą. Jest to, jak przy każdej pracy zbiorowej, kompromis wielu szkół testowania, doświadczeń i wielu perspektyw (współ)twórców dokumentu. Czy udało się osiągnąć najlepszy możliwy rezultat? Oceńcie sami.

LINK [wersja angielska] >>

 
Autor: Radek Smilgin