Wytwarzanie oprogramowania sterowane przypadkami testowymi ...czyli Test Driven Development inaczej Arnika Hryszko obrazek

O mnie ARNIKA Analysis Department Shared IT Services Arnika Hryszko 30.09.2016

O projekcie System o krytycznym znaczeniu dla firmy: Obsługa produkcji ciężarówek, maszyn budowlanych i autobusów Istnieje od 10 lat – duży i skomplikowany Co ważne: po 10 latach programiści mają swoje przyzwyczajenia, kod jest w wielu miejscach neiczytelny, cięzko wdrożyć się do projektu (2lata), w projekcie pracuje około 40 osób z różnych lokalizacji Arnika Hryszko 30.09.2016

W czym tkwił problem? Zdarzało się, że wprowadzenie nowych funkcjonalności powoduje usterki podstawowych elementów systemu, co ujawniały testy regresyjne Gorzej - w efekcie naprawy takich usterek pojawiały się nowe Rosła frustracja testerów, marnowany był ich czas Czas instalacji jednej z wersji środowiska to 3-4 godziny, po których moze okazac się, ze program się nie uruchamia. Arnika Hryszko 30.09.2016

Podjęte próby rozwiązania problemu Szkolenia dla programistów z wiedzy o systemie Rozszerzenie zakresu przeglądu kodu Więcej testów jednostkowych Efekt? Jedynie niewielka poprawa... Arnika Hryszko 30.09.2016

Nowy pomysł testerów Jak zminimalizować ryzyko, że retest rzekomo naprawionego błędu zakończy się niepowodzeniem? Programiści będą wstępnie testować Tylko jak ich do tego przekonać? Arnika Hryszko 30.09.2016

Założenia nowego podejścia Dla każdej nowej funkcjonalności tworzone jest „krytyczny”scenariusz Scenariusz przygotowuje tester Programista wykonuje scenariusz na swoim środowisku, przed dodaniem zmian Tester pomaga, w razie potrzeby Gdy scenariusz wykonany zostanie z powodzeniem, zmiany dodawane są do repozytorium Zamienić punkty na graf Arnika Hryszko 30.09.2016

Wdrożenie nowego podejścia „Pilot” dla dwóch funkcjonalności Początkowe opory przed „nowym” Dezorientacja – korzystać z testów akceptacyjnych czy krytycznych scenariuszy? Obrazek „going uphill” Arnika Hryszko 30.09.2016

Efekt? Znaczące zmniejszenie liczby niedziałających buildów Zmniejszenie liczby „oczywistych” błędów Większa wiedza programistów o systemie Zacieśnienie współpracy między programistami i testerami Zadowoleni testerzy! Znaczaąe = ciezko okreslić dkłądnie, gdyż nie były to jedyne zmianny (nie tylko TCDD miało wpływ), ale jest to około 40-50% Arnika Hryszko 30.09.2016

Spróbujmy tego samego z błędami! Arnika Hryszko 30.09.2016

Jak to ugryźć? Przypadki testowe, które wykryły błąd, nie zawsze są zrozumiałe dla programisty Brak scenariuszy dla błędów wykrytych w testach eksploracyjnych Pisanie dodatkowych scenariuszy – zbyt czasochłonne Brak aprobaty dla dodatkowej procedury ? Znaczaąe = ciezko okreslić dkłądnie, gdyż nie były to jedyne zmianny (nie tylko TCDD miało wpływ), ale jest to około 40-50% Arnika Hryszko 30.09.2016

Decyzja Efekty Scenariusz tylko dla błędów poważnych i krytycznych Scenariusz, który wykrył błąd lub inny - wybrany przez testera z repozytorium Nie jest to część procesu – raczej dobrowolne działanie Efekty Drobna, ale zauważalna poprawa Częściej uśmiechnięci testerzy Znaczaąe = ciezko okreslić dkłądnie, gdyż nie były to jedyne zmianny (nie tylko TCDD miało wpływ), ale jest to około 40-50% Arnika Hryszko 30.09.2016

Podsumowanie Test Case Driven Development bardziej sprawdziło się w długoterminowych zadaniach Zacieśniła się współpraca między programistami i testerami Zwiększyła się wiedza na temat działania systemu Poprawiła się jakość Inne projekty zainteresowały się naszym podejściem Testerzy zyskali większe zadowolenie z pracy! Arnika Hryszko 30.09.2016

Arnika Hryszko 30.09.2016