Ponieważ zawsze uważałem, że obopólne porozumienie na linii programiści - testerzy jest kluczem do sukcesu, zacząłem zastanawiać się jak wyjaśnić programistom co to jest "czarna skrzynka" i jak myśli o niej i w niej tester.
Najfajniej byłoby - pomyślałem sobie - znaleźć jakiś błyskotliwy cytat opisujący czarną skrzynkę. Zacząłem grzebać po Internecie poszukując czegoś ciekawego. Odwiedziłem "Wikicytaty" i rozpocząłem poszukiwania od haseł typu "czarna skrzynka" lub "skrzynka". Jednak nie mogłem trafić na nic naprawdę mocnego.
"To musi być coś" - powtarzałem sobie - " co pobudzi ich wyobraźnie a jednocześnie da im do myślenia". I wtedy przypomniałem sobie dyskusję jaką przeprowadziłem pracując w zupełnie innym miejscu z jednym z testerów. Cytat pochodził od Donalda Rumsfelda i brzmiał:
"[…] wiemy, że - jak wiadomo - są rzeczy, o których wiemy, że o nich wiemy. Wiemy też, że są znane niewiadome, to znaczy, że są rzeczy, o których wiemy, że nic o nich nie wiemy. Ale są również nieznane niewiadome - takie, o których nie wiemy, że o nich nie wiemy […]"(1)
"Skoro ja to zapamiętałem to i oni przyswoją to na jakiś czas" pomyślałem sobie. Tak przy okazji to uważam te słowa za w dużej mierze oddające świat, horyzont wiedzy oraz oczekiwania i przeczucia testera testującego czarną skrzynką.
Rzeczy "o których wiemy, że o nich wiemy" to wymagania, specyfikacja i historia systemu oraz wszelkie inne informacje bardziej lub mniej oficjalne.
Rzeczy niewiadome to chociażby defekty, zmiany do wymagań lub specyfikacji i te wszystkie informacje, które do nas nie dotarły. Każdy tester jest świadom, że jego zasób wiedzy na temat testowanego systemu jest ograniczony.
Na przykład we wczesnych fazach projektu bardzo często pojawiają się rzeczy, które w żaden sposób nie są zdefiniowane przez architekta lub programistę. Dowiadujemy się o ich istnieniu przy projektowaniu testów, kiedy schodzimy na bardzo niski poziom. Fazą, która wprost obfituje w odkrywanie rzeczy, o których wiemy, że nic o nich nie wiemy jest testowanie dokumentacji. Nie wiemy także jakie defekty spotkamy po drodze ale wiemy, że one są.
Ten punkt jest także bardzo dobry do rozpoczęcia testów eksploracyjnych. Jeśli jesteśmy w stanie zdefiniować obszary, o których wiem, że nic nie wiemy i rozpoczniemy ich eksplorację testową to otrzymamy w większości przypadków bardzo ciekawe wyniki.
"Nieznane niewiadome" to wszystkie te rzeczy, za które tester się wstydzi (głównie "oczywiste" defekty wychodzące w testach polowych lub akceptacyjnych). To także te wszystkie zmiany w projekcie (bardzo często spontaniczne i nie do końca przemyślane), które powodują zmianę architektury co tak naprawdę powinno oznaczać rozpoczęcie testów od samego początku. Świadomość że nie wiemy o tym o czym nie wiemy bywa czasami przyczyną powtarzania testów.
(1)D. Rumsfeld, Departament Obrony USA, 12 lutego 2002 roku, "[...]as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns - the ones we don't know we don't know[...]"
Brak komentarzy:
Prześlij komentarz