Problem milczących dowodów

5 lipca 2020 | Trochę teorii

Temat błędów poznawczych chodzi za mną już od dłuższego czasu, wciągnął mnie na tyle, poświęciłam mu prezentację. Szybko wchodzę w posiadanie każdej książki, która się z nim jakkolwiek wiąże. Nie mogłam więc przeoczyć tego, że w księgarniach po kilkuletniej przerwie pojawiły się publikacje Nassi a Nicholasa Taleba, a wśród nich „Czarny Łabędź”, którego upolować próbowałam dwa lata. Lektura (jak i pozostałe trzy) migiem znalazła się na mojej półce i jeszcze szybciej na liście moich ulubieńców.

Pośród wielu ciekawych zagadnień związanych z problemem Czarnych Łabędzi a przytaczanych przez autora w książce, pojawił się jeden, który szczególnie mnie zainteresował. Istnienie błędu poznawczego, o którym chcę dziś napisać w kontekście pracy testera, przeczuwałam już wcześniej, najczęściej w kontekście sytuacji, które przytoczę niżej, ale jakoś tak nie potrafiłam tego nazwać. A mowa tu o błędzie milczących dowodów.

Taleb poświęcił cały rozdział temu zagadnieniu uznając go za jedną z istotniejszych przyczyn ignorowania przez nas Czarnych Łabędzi (o tym problemie też jeszcze chciałabym napisać, więc bez spoilerów, wszystko w swoim czasie :)). Rozdział ten rozpoczął anegdotą na tyle w moim odczuciu uroczą, że i ja przytoczę.

Ponad dwa tysiące lat temu (…) Cyceron opowiedział następującą historię. Niejakiemu Diagorasowi, człowiekowi niewierzącemu, pokazano portrety ludzi wierzących, którzy modlili się w czasie sztormu i przetrwali katastrofę morską. Była to sugestia, że modlitwa chroni przed utonięciem. Diagoras zapytał jednak: >>A gdzie są portrety tych, którzy modlili się, a potem utonęli?<< [1]

I tak jak martwi marynarze nie są w stanie powiedzieć „hej, modlitwa nie działa!”, tak wiele razy my sami jesteśmy pozbawieni punktu widzenia kogoś, komu nie wyszło. „Błąd milczących dowodów” jest wiięć elegantszą nazwą znanego powiedzenia: historię piszą zwycięzcy. Zaczęłam się zastanawiać, czy i w swojej pracy jestem narażona na ten problem. Nietrudno się domyślić, że jak najbardziej; jeszcze jak.

Usterki, które się nie wydarzyły

Ten punkt akurat opisuję tutaj, że tak powiem – pro forma. Każdy, kto zrobił ISTQB, a także kto go nie zrobił, ale posiada podstawową przynajmniej wiedzę z zakresu jakości wie, że

Testowanie ujawnia usterki, ale nie może dowieść ich braku [2]

Nie muszą się chyba rozpisywać, bo w zasadzie widzę tutaj niemal dosłowny opis problemu milczących dowodów, czy raczej radę, jak mu nie dać się zwieść. Jeśli z jakiejś przyczynu usterka nie wystąpiła w czasie testów, to nie oznacza, że błędu nie ma. Ale błąd, który się nie ujawnił, może dać nam złudne poczucie, że nasze oprogramowanie jest od niego wolne.

Dobór narzędzi

Pierwsza rzecz, o jakiej pomyślałam, to dobieranie narzędzi. Zdałam sobie sprawę, że poszukując jakiegoś rozwiązania, które mogę wykorzystać w swoich testach, najczęściej opieram na case studies, artykułach blogowych albo propozycjach rozwiązań z grup fejsubkowych czy ze Stackoverflow. Przyznam, że przeszedł mnie dreszcz, kiedy zdałam sobie sprawę, że wszystkie te źródła raczej zachwalają narzędzia, niż punktują ich wady, a jeszcze rzadziej – opisują historię porażki przy wdrożeniu,. Tym większe mrowienie poczułam, kiedy przypomniałam sobie sytuacje, kiedy w pracy zarzucaliśmy kolejne framweorki czy programy do monitorowania, zbierania danych ponieważ – w dość oczywisty sposób – nie przystawały one do naszego produktu, projektu czy stylu pracy.

Nie zrozumcie mnie źle, nie uważam, żeby było coś złego w tym, żeby przetestować narzędzie i jeśli się nie sprawdzi porzucić pracę z nim. Ale często już na pierwszy rzut oka widać, że to narzędzie się nie sprawdzi i niemalże pewnym jest, że ktoś już kiedyś spróbował je wykorzystać, bez skutku. W chwili wyboru widzimy tylko pozytywne strony rozwiązania i to może zaburzyć nasz obiektywizm. Mało kto jednak opisuje historię nieudanego eksperymentu z narzędziem a tym samym – innym trudno uczyć się na jego błędach.

Mityczne drzwi do IT

Powiedzenie „Historię piszą zwycięzcy” podsunęło mi na myśl jeszcze jedną sytuację, w której narażamy siebie – a raczej innych – na problem milczących dowodów. Któż nie widział porady w stylu „Chcesz wejść w IT? Zostań testerem!”. Często takie rozwiązania pojawiają się jako odpowiedź pod pytaniem co od czego zacząć, żeby zostać na przykład programistą, i opatrzone są poniekąd ckliwą historią autora czy jego znajomego o tym, jak wszedł w branżę jako tester tekstów na Frondzie, a teraz jest senior ninja java master developerem. I okej, jest to argument. Ale powstaje pytanie – jak wielu jest ludzi, którym się nie udało? Którzy olali temat jeszcze przed podjęciem pierwszej pracy albo już w jej trakcie doszli do wniosku, że jednak klikanie w kąkuter to nie praca. Albo po prostu stwierdzili, że sama praca testera jest ok.

Podsumowanko

Wszelkie błędy poznawcze są wpisane w naszą naturę, więc nie może być inaczej z milczącymi dowodami. Niewiele możemy zrobić, żeby nie dać się zwieść na manowce, ale myślę, że świadomość naszej słabości pozwala nabrać trochę większego dystansu do podejmowanych decyzji. A to, że rzecz dotyczy wszystkich wydaje mi się dość krzepiąca 🙂

Jeśli temat Was zainteresował to zachęcam Was do zapoznania się z twórczością Taleba, nie tylko z „Czarnym Łabędziem”. Ale na recenzje jeszcze przyjdzie pora.

[1] Taleb N.N.: Czarny Łabędź, Poznań, Zysk i S-ka Wydawnictwo, 2020
[2] SJSI: Certyfikowany tester. Sylabus poziomu podstawowego ISTQB, Wersja 2018 V 3.1.
[3] https://images.pexels.com/photos/59816/swan-bird-nature-water-bird-59816.jpeg?auto=compress&cs=tinysrgb&dpr=2&h=750&w=1260

Najnowsze wpisy

Biały pasek na pączkach, czyli o TQM słów kilka

Total Quality Management jako zagadnienie od dawna chciałam opisać, ponieważ właśnie ono w czasie moich studiów zapadło mi w pamięć.

Akcja rekrutacja: Kto odpowiada za jakość oprogramowania?

To pytanie bardzo często pojawia się na rozmowach kwalifikacyjnych na stanowiska związane z testowaniem oprogramowania. Sama wiele razy je zadawałam, a jeszcze częściej słyszałam - nie skłamię, jeśli napiszę, że może tylko na jednej rozmowie...

#6 Antywzorce w testowaniu oprogramowania: Zwracanie nadmiernej uwagi na pokrycie testami

Czas na szybkie omówienie szóstego antywzorca z listy z Codepipes Blog, a mianowicie zwracania nadmiernej uwagi na pokrycie testami.

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!