Wytwarzanie oprogramowania sterowane przypadkami testowymi

Prezentacja na temat: "Wytwarzanie oprogramowania sterowane przypadkami testowymi"— Zapis prezentacji:

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

2 O mnie ARNIKA Analysis Department Shared IT Services Arnika Hryszko

3 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

4 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

5 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

6 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

7 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

8 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

9 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

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

11 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

12 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

13 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

14 Arnika Hryszko