Tester-Driven Development

Programowanie oparte na testerach lub programowanie oparte na błędach spotykamy w swoich projektach informatycznych relatywnie często. W takim modelu „wymagania” określane są na podstawie wyników uruchomienia testów lub bazują na zgłoszeniach błędów. Choć o takiej  koncepcji zazwyczaj mówi się żartobliwie, to ze względu na częstotliwość występowania niestety jest to śmiech przez łzy. Programowanie sterowane przez testerów skraca proces, eliminując definiowanie i doprecyzowanie (części) wymagań i pozwala testerom (lub zespołowi kontroli jakości) definiować czym, ich zdaniem, powinien być końcowy produkt.

Realizacja projektu przy pomocy tego anty-wzorca często wynika z problemów źródłowych, takich jak:

• niekompletne wymagania,
• niedoświadczeni programiści,
• słabe zarządzanie projektem.

Sytuacja pogarsza się w momencie, gdy testerzy zdają sobie sprawę, że nie znają wymagań, a w związku z tym nie wiedzą, jak przetestować określone zmiany w kodzie. Gdy na programistach poszczególnych zmian spoczywa obowiązek napisania własnych przypadków testowych, to chętnie to robią, gdyż ich własne testy zwykle przechodzą. Liderzy projektów są również zachwyceni szybkim zmniejszeniem liczby otwartych zgłoszeń.

Jednak niekoniecznie musi tak być. Jesteśmy w stanie zmienić tester-driven development w team-driven development, gdzie zespół składający się z testerów, programistów oraz przedstawiciela zamawiającego oprogramowanie (właściciela produktu), wspólnie definiuje, jak końcowy produkt ma wyglądać. Wymaga to zaakceptowania i wdrożenia pewnych reguł projektowych: 

• „wszelkie antywzorce (patologie) projektowe należy wypleniać”, czyli wszystko co jest marnotrawstwem czasu oraz środków należy eliminować i dzięki temu podnosić efektywność pracy;
• „reguła ograniczonego zaufania” wywodząca się z reguł ruchu drogowego i zakładająca, że każdy może popełnić błąd. Jeśli będziemy z podejrzliwością podchodzić do swoich umiejętności lub umiejętności innych osób w naszym otoczeniu, to możemy uniknąć niebezpiecznych sytuacji;
• „za jakość oprogramowania odpowiada cały zespół”, a nie tester, który tę jakość kontroluje; dodatkowo jedynie poprzez współpracę możemy osiągnąć dobre rezultaty.

Rozważmy przykład, w którym system raportowania defektów ma również pole „sugerowane rozwiązanie”, wymagane do uzupełnienia przez testera. Zgodnie z metodyką ISTQB, tester oprogramowania nie ma obowiązku wiedzieć jak rozwiązać dany problem, ale takie podejście możemy uznać za archaiczne i nieprzystające do współczesnych metodyk wytwarzania oprogramowania. Obecność takiego pola możemy interpretować na dwa sposoby:

1. Programiści nie wiedzą, jak ma wyglądać końcowe rozwiązanie więc spychają odpowiedzialność za kształt produktu na testera. Z kolei managerowie akceptuję taki stan rzeczy. Jeśli końcowe rozwiązanie będzie niepoprawne, to obwini się testera. Jest to założenie skrajnie negatywne i od razu sugeruje pewną patologię projektową, którą należy zwalczać. 
2. Programiści / manager wierzą w wiedzę testera i proszą go o radę, jak rozwiązać dany problem. Oznacza to, że mają oni zaufanie do pracy testera i czekają na opinię. Jest to założenie pozytywne i wskazujące na dobre relacje projektowe oraz świadomość wspólnej odpowiedzialności za jakość. Jest to swoiste wyróżnienie dla testera, ale też odpowiedzialność, ponieważ przez swoje opisy tester będzie kształtował ostateczny produkt. Musimy jednak założyć, że możemy nie mieć pełnej wiedzy odnośnie najlepszego, końcowego rozwiązania problemu, musimy więc w samym „sugerowanym rozwiązaniu” użyć formy, która nie da odbiorcy, pełnego przekonania o naszej nieomylności:

• zaczniemy opis od „Sugeruję…” czy „Należy rozważyć następujące rozwiązanie…”, co od razu wskazuje, że nie dajemy sobie prawa do nieomylności, a jedynie widząc problem proponujemy dla niego rozwiązanie;
• uzasadnimy dlaczego takie rozwiązanie jest naszym zdaniem właściwe, np. „Tak zachowuje się aplikacja w obszarze X”, czy „Podobnej treści komunikat wyświetlany jest w procesie Y”.

Oczywiście uzupełnianie pola „sugerowane rozwiązanie” jest dla nas dodatkowym zadaniem, ale możemy je potraktować jako pokazanie management’owi, że zwiększając nam zakres odpowiedzialności, równocześnie daje nam prawdo i autonomię w kształtowaniu produktu.
 

Każdą projektową sytuację możemy interpretować jako potencjalny atak na testerską rolę, okopać się i bronić swojej pozycji. Możemy również próbować projektowe patologie potraktować jako punkt startowy do poprawiania organizacji pracy co docelowo powinno pomóc dostarczać lepszy produkt. Tester - Driven Development jest antywzorcem, który łatwo możemy obrócić w korzyści.