Redakcja
Wspomniana grafika wygląda tak:
W dużym skrócie: Pan Samuel Lipoff, podpisany tutaj jako „tester”, rozwiązuje zagadkę „wieku siostry” używając przy tym zagadnienia wartości granicznych, potencjalnego scenariusza, w którym siostra jest już martwa lub adoptowana, ktoś skłamał na temat jej wieku lub też poleciała w kosmos i czas biegnie dla niej inaczej niż dla nas.
W domyśle chodziło o to, by pokazać jak ważna jest rola testera oprogramowania i ile jest rzeczy, które tester musi przewidzieć.
Przejdźmy więc do pułapek.
1. Samuel nie jest testerem. Na Harvardzie studiował filozofię, a na MIT chemię. Zajmuje się więc nauką na poziomie filozoficznym. Do tego jest przedsiębiorcą, który buduje własny produkt i zapewne musi analizować wiele scenariuszy biznesowych.
Jest więc osobą, która widzi rzeczy z wielu perspektyw, a szukając odpowiedzi nie koncentruje się na tych oczywistych. Rozkłada zadanie na czynniki pierwsze. Zapewne po dobrym przeszkoleniu mógłby być świetnym testerem.
2. Tester nie może analizować zagadnień tak głęboko, jak Samuel ponieważ w swojej pracy musi takich zagadek rozwiązać setki.
Zostało genialnie pokazane, że testowanie jest nieskończone, ale musimy brać pod uwagę to, że przecież nie może toczyć się w nieskończoność.
3. Tester musi ocenić problem i prawdopodobieństwo jego wystąpienia oraz krytyczności dla samej aplikacji. Musi spojrzeć na problem z poziomu tego co jest możliwe i co jest realne. Wartości brzegowe – TAK, śmierć – TAK, niepoprawne dane wejściowe – TAK, ale już podróże kosmiczne – NIE (scenariusz zbyt mało prawdopodobny).
4. Problem został narysowany jako różnica w myśleniu programistów i testerów, ale przecież nie o to tu chodzi! To wymagania są nieprecyzyjne. Nie dają odpowiedzi na pytania Samuela. W normalnym świecie tester z taką listą pytań uda się do product ownera lub innego przedstawiciela klienta i omówi swoje wątpliwości.
5. Programista nie popełnił błędu. Testy unitowe pokazałyby, że implementacja jest poprawna. System zadziałby w najbardziej typowym przypadku i pewnie dla większości danych. To czego brakuje to podejścia biznesowego. Jak bardzo opłaca nam się drążyć różne, choć najbardziej absurdalne scenariusze? Jest to przykład jak ważne są kompetencje programistyczne, testerskie i biznesowe w jednym zespole.
Reasumując rola testera nie sprowadza się do testowania, tak jak rola programisty nie sprowadza się tylko do kodowania. Przy każdym zadaniu trzeba myśleć, a czym bardziej staramy się zrozumieć problem tym większą wartość dajemy projektowi.
PS. Możemy też uznać, że to w zasadzie tylko śmieszny obrazek.
