Jak wyjaśnić czym jest testowanie? Każdemu.

W większości przypadków ludzie nie są zainteresowani tym, co robimy i nudzą się w piątej sekundzie naszej opowieści. Możemy ich wtedy zbyć uniwersalną odpowiedzią. W zależności od pytającego odpowiedź można sformułować następująco: pracuję przy komputerze (wyjaśnienie dla członków rodziny), płacą mi za krytykowanie innych (dla nietechnicznych znajomych), analizuję systemy informatyczne w celu określenia poziomu jakości oraz weryfikacji występowania krytycznych awarii (dla żony lub dziewczyny wskazując też na to, że nasza praca jest ważna i trudna).

Czasami jednak ludzie naprawdę chcą wiedzieć, co robimy i dopytują się prosząc o możliwie najprostsze wyjaśnienie.

Jeśli tylko chcemy wyjaśnić, czym się zajmujemy, oto kilka rzeczy, o których trzeba wspomnieć. Nie można się jednak zagłębiać w szczegóły, bo szybko stracimy ich uwagę:

1. Powiedz, czym jest testowanie. Użyj własnej definicji uzupełnionej o analogie i metafory. Odwołaj się do rzeczy, które mogą być znane pytającemu.
2. Powiedz dlaczego testowanie jest trudne. Nieskończoność testowania wynika ze złożoności oprogramowania, a większość ludzi i tak uważa, że oprogramowanie pochodzi z połączenia magii i niepojętej nauki. Skoro i tak 99,99% społeczeństwa nie rozumie, czym jest i jak działa kod, to Twój rozmówca prawdopodobnie nie będzie oczekiwał technicznych szczegółów.
3. Powiedz o definiowaniu końca testowania, o jakości akceptowalnej przez końcowego odbiorcę.

To wystarczy, żeby zaspokoić ciekawość większości pytających. Co jednak, gdy rozmówca drąży dalej, i to w najmniej spodziewanym momencie, na przykład przy ekspresie do kawy albo w windzie?

James Bach, jeden z pionierów eksploracyjnego podejścia do testowania, opisał ten scenariusz jako „wyjaśnienie na korytarzu”, czyli rozmowę, która zaczyna się przypadkowo, trwa kilka minut i może albo przeciągnąć współpracownika na naszą stronę, albo utwierdzić go w przekonaniu, że testerzy tylko klikają i narzekają. 

Bach uważa, że większość nieporozumień wokół testowania nie wynika ze złej woli, a z tego, że nikt nigdy porządnie nie wytłumaczył, o co w tym chodzi. I że to my, testerzy, jesteśmy za to odpowiedzialni. Trochę irytujące, ale trudno się z tym nie zgodzić.

Dobre wyjaśnienie to nie jest wykład. To rozmowa, w której chcemy dać rozmówcy narzędzia do lepszego rozumienia naszej pracy, a nie zaimponować mu terminologią. 

9 zasad skutecznego wyjaśniania

Bach sformułował dziewięć zasad, które działają niezależnie od tego, czy tłumaczysz testowanie szefowi, programiście, czy sąsiadce na imprezie urodzinowej. 

1. Mów z własnego doświadczenia. Unikaj cudzych definicji, jeśli sam ich dobrze nie rozumiesz. Sceptyczny rozmówca szybko wyczuje, że recytujesz z pamięci, i zacznie drążyć tam, gdzie nie masz pewnego gruntu. Miej pod ręką jeden konkretny przykład z własnej pracy – realny defekt, który znalazłeś, realna konsekwencja, której udało się uniknąć. 
2. Myśl o rozmówcy, a nie o sobie. Co tak naprawdę interesuje osobę, z którą rozmawiasz? Managera projektu interesuje harmonogram i ryzyko, nie pokrycie testami. Programistę interesuje to, czy jego kod okaże się problematyczny. Znajomego spoza IT interesuje to, czy jego ulubiona aplikacja przestanie się wysypywać. Dostosuj przekaz do tego, co dla nich ważne. 
3. Uważaj na słowa-pułapki. Takie terminy jak „przypadek testowy”, „regresja”, „plan testów” czy nawet samo słowo „defekt” mają różne znaczenia dla różnych ludzi. Jeśli czujesz, że rozmowa zaczyna kręcić się w kółko, sprawdź, czy nie mówicie o dwóch różnych rzeczach używając tych samych słów. 
4. Traktuj pytającego poważnie. Nawet jeśli pytanie brzmi naiwnie – „ale po co testować, skoro programista mógł sprawdzić to sam?” – odpowiedz tak, jakby za nim stała szczera ciekawość. Bo zazwyczaj tak właśnie jest. Rozmówca, który poczuje się potraktowany z góry, zamknie się i przestanie słuchać. 
5. Prowokuj dobre pytania. Suche wyjaśnienia nudzą. Wrzuć do rozmowy coś, co wzbudzi ciekawość – nieoczywistą analogię, zaskakujący przykład. Gdy rozmówca zaczyna pytać „ale jak to?”, masz go. To moment, w którym zaczyna naprawdę rozumieć. 
6. Mów o tym, co ma znaczenie praktyczne. Teorię zostaw dla siebie. Rozmówcę interesuje: co się zmieni, jeśli zrozumie testowanie lepiej? Jakie decyzje podejmie inaczej? Czego uniknie? Wyjaśnienie, które nie prowadzi do żadnej zmiany w zachowaniu rozmówcy, jest straconym czasem dla obojga. 
7. Mów krótko. Krótkie zdania, jeden wątek na raz. Jeśli zdążysz powiedzieć trzy rzeczy, zanim rozmówca spojrzy na telefon, to będzie to dobry wynik. Długie wywody działają tylko wtedy, gdy ktoś naprawdę chce zdobyć wiedzę. 
8. Pokazuj, że to wspólny problem. Testowanie nie jest domeną testerów, a częścią procesu, w którym biorą udział wszyscy. Gdy coś idzie nie tak, wszyscy ponoszą konsekwencje. Wyjaśniaj testowanie jako element wspólnej odpowiedzialności za jakość, nie jako aktywność izolowanej grupy specjalistów. 
9. Przygotuj się wcześniej. Najlepsze wyjaśnienia rzadko rodzą się w spontanicznej rozmowie. Bach radzi prowadzić notatki, zapisywać analogie, przykłady, odpowiedzi na pytania, które zaskoczyły nas w rozmowach. Dobry zapas historii i metafor jest czymś, co buduje się latami, ale zaczyna się od pierwszego zapisanego przykładu. 

Żadna z tych zasad nie wymaga przygotowania prezentacji ani znajomości definicji z podręcznika. Wymagają za to czegoś trudniejszego, czyli przemyślenia własnej pracy na tyle, żeby móc o niej mówić prosto, konkretnie i bez zażenowania.

Pełne omówienie tematu, wraz z przykładową rozmową z menedżerem ilustrującą większość z tych zasad w akcji, znajdziecie w artykule Jamesa Bacha „Explaining Testing to Them”, opublikowanym w magazynie STQE w 2001 roku.

Tekst publikowany pierwotnie 10.06.2014 r.