Radek Smilgin
W naszym codziennym, testerskim życiu, narzucane są nam pewne zasady, które ciężko przychodzi nam zakceptować. Jedną z nich jest słownictwo, jakim powinniśmy się posługiwać. Testerski słownik, standaryzowany jest głównie przez ISTQB®, który proponuje następujący ciąg zdarzeń i ich konsekwencji. Człowiek pracujący w projekcie informatycznym popełnia błąd (lub pomyłkę). Konsekwencją tego jest defekt (synonimy: usterka, pluskwa, bug), który pojawia się w oprogramowaniu lub ewentualnie w dokumencie. Po dynamicznym uruchomieniu oprogramowania z defektem, możemy zaobserwować awarię.
Strasznie to wszystko trudne do zapamiętania i rzeczywiście wydaje się, że większość ludzi nie posługuje się takim językiem. Co więcej, ISTQB® również nie przestrzega własnych zasad. W sylabusie poziomu podstawowego, możemy znaleźć siódną regułę testowania: "Przekonanie o braku błędów jest błędem" z następującą adnotacją:
Problem ze słownictwem, możemy zaobserwować również w mediach głównego nurtu.
W powyższych przykładach i zgodnie z ISTQB®, tytuły powinny brzmieć: "Skype’a sparaliżowała awaria oprogramowania" oraz "Awaria na Facebooku. Posty mogły trafiać do wszystkich."
Co więcej, niektóre języki nie są tak bogate jak angielski czy polski i tak naprawdę każdy z angielskich odpowiedników, to jedno słowo. Tak jest na przykład w języku duńskim.
Czy jest więc sens trzymać się tak nieżyciowej nomenklatury? Nie. Proponuję więc, uwolnić fantazję i dopuścić nazywanie awarii i defektu błędem, jeśli tylko ktoś ma na to ochotę.
Ilustracje oraz koncept omówiony został przeze mnie na prezentacji "Kwestionowanie ISTQB®", której slajdy można znaleźć tutaj: https://www.slideshare.net/testerzy/kwestionowanie-istqb
