Czy dzięki certyfikacji ISTQB uspójnia się słownictwo?

Często prowadzimy dyskusje - warto czy nie warto certyfikować się z zakresu ISTQB? Ile osób tyle stanowisk za i przeciw. Warto jednak spojrzeć na temat szerzej i pogrzebać w korzeniach słownika testerskiego i jego źródeł.

Przyczynkiem do pogłębionej rozmowy o słowniku jest panel dyskusyjny prowadzony przez Jakuba Rosińskiego, w którym to po raz kolejny mówimy o wartości „Słownika pojęć testerskich”, czyli tłumaczenia haseł z ISTQB dokonanego przez SJSI.

W mojej opinii "ISTQB uwspólnia język" to (nomen omen) humbug. Oto kilka faktów, które pokazują zamęt w definicjach.

1.  Główne miejsce ISTQB do publikowania definicje testerskich to https://glossary.istqb.org/en/search/
   Warto zauważyć, że po odejściu od publikacji słownika w formie PDF, zaczęła się wolna amerykanka w pracach nad słownikiem. Pojęcia zmieniają się bez kontroli wersji i bez informowania o zmianach. Doprowadza to do sytuacji, kiedy tak naprawdę ciężko jest mapować hasła ze słownika z sylabusami. Dodatkowo, często najnowsze wersje definicji w Glossary różnią się od swoich narodowych tłumaczeń. Nastąpił dość poważny rozjazd, które pojęcia są aktualne i które z nich mamy znać na egzamin.

2. W Polsce mamy przynajmniej dwa różne źródła definicji udostępnione przez SJSi (organizacja, która m.in. zajmuje się tłumaczeniem słownika i sylabusa ISTQB):
   Słownik w wersji PDF
   Słownik online
   Tutaj też są różnice. Przykładem może być pojęcie: „procedura testowa”.

3. Rozjeżdżają nam się również definicje w słowniku i w sylabusie.

   Przykład to proces testowy.

   W słowniku proces testowy to: podstawowy proces testowy składa się z następujących faz: planowanie testów i kontrola, analiza i projektowanie testów, implementacja i wykonanie, ocena kryteriów wyjścia i raportowanie oraz czynności związane z zakończeniem testów.

4. Przez dynamikę zmian osoby zdające egzamin w 2010, 2015 czy 2019 korzystały z różnych słowników. W większości zmiany nie są drastyczne, ale często są redefiniowane są kluczowe słowa. Przykładowo pojęcie „zapewnienie jakości”  dla osób, które nie śledzą na bieżąco zmian w słowniku, a czytały sylabus w odstępach kilku lat znaczy zupełnie coś innego.

   Pisaliśmy o tym tutaj.

5. Tłumaczenia. Wiadomo, że niezmiernie trudno jest znaleźć polski odpowiednik dla angielskojęzycznych określeń. Branża IT raczej kopiuje i spolszcza pojęcia zamiast szukać ich tłumaczeń. W SJSi próbujemy wszystko tłumaczyć. Przykłady

   - framework, w wersji spolszczonej to popularny „frejmłork”[oczywiście tak go nie zapisujemy], a w SJSi to… „struktura”;

   - test bed, to po prostu testbed, ale w SJSi to… „łoże testowe”;

   - mock to mok, w wersji SJSI… „atrapa”.

   Można mnożyć jeszcze więcej mniej lub bardziej udanych prób tłumaczeń, ale w większości się one nie przyjęły. Na korytarzach firm IT raczej usłyszymy, że „zamokowałem część frejmłorku na testbedzie” niż „zbudowałem atrapy obiektów dla części struktury na łożu testowym”.

6. Narzucone rozdzielenie pojęć błąd, defekt, awaria jest nie tylko nieużywane w IT, ale również jest odrzucane przez samych testerów. czy możemy winić ludzi za to, że mówią i piszą o „błędzie komputera” jeśli tylko dwie komunikujące się strony wiedzą o czym rozmawiają? W samym sylabusie ISTQB z 2018 jest 7 zasada testowania, która brzmi: „Przekonanie o braku błędów jest błędem”, a do niej jest przypis „Ta zasada powinna się nazywać „Błędne przekonanie o braku defektów”, tym niemniej zdecydowaliśmy się zostawić „Przekonanie o braku błędów jest błędem” jako najbliższe angielskiemu „Absence-of-errors fallacy”.

7. Część definicji w ISTQB jest niejednoznacznych i niezrozumiałych. Kiedyś żartowało się z pierwszych definicji atrybutów jakości oprogramowania, które kompletnie nic nie wnosiły jak np. testy bezpieczeństwa – testowanie mające na celu sprawdzenie bezpieczeństwa. to zostało już naprawione, ale ciągle jest wiele haseł, pojęć, które pomimo definicji i opisu w słowniku pojmujemy inaczej.

   Przykładem jest "scenariusz testowy", który opisujemy tutaj i tutaj.

   Warto podkreślić, że wszystkie publikacja opisujące scenariusz podpierają się wiedzą z ISTQB.

8. Inną kontrowersją jest sama koncepcja wdrażania osobnego słownika w testerskiej niszy. Testowanie jest jedną z czynności w procesie wytwarzania oprogramowania i zamiast kreować swój własny niezrozumiały dla innych członków zespołu slang, powinniśmy korzystać z bardziej globalnych słowników.
   Samo posługiwanie się pojęciem "terminologia ISTQB" jest nadużyciem. Można mówić co najwyżej o „kompilacji ISTQB”. Słownik powstał na bazie glossary z BS 7925-1, a dużo popularnych haseł pochodzi z innych standardów jak ISO 24765, ISO 9126 czy ISO 29119.

   to one mają szerszy zasięg i standaryzują słowniki w programowaniu, analizie biznesowej czy zarządzaniu projektami.

ISTQB / SJSi stoi w rozkroku. Kiedyś było mocno zamknięte na inne obszary cyklu życia. Promowało niezależności testowania i miało chęć budować silosy zamiast zachęcać do współpracy w ramach zespołów wytwórczych. Dziś otwiera się i dostrzega, że rola testera zastępowana jest przez zwykłą czynność testowania.

Kiedyś silnie stawiająca na trwanie w świecie najlepszych praktyk i niezmiennych definicji, dziś próbuje je dynamicznie zmieniać. Niestety ta ewolucja postępuje dość powoli i chaotycznie. Dziś praktycznie w każdym źródle powiązanym z ISTQB możemy znaleźć różne definicje i wyjaśnienia dla testerskich pojęć. czy możemy więc mówić o uspójnienia testerskiego języka? W mojej opinii jest to uprawnione, ale tylko dla małych grup ludzi, zazwyczaj pracujących w jednej firmie, które wspólnie przyswoiły ten sam materiał, z tego samego źródła i w podobnym czasie.