Czy są jakieś badania naukowe przeprowadzone na TDD, które wykorzystują całkowity koszt posiadania produktu jako miarę?

11

Kiedy czytałem streszczenie poprzedniej pracy w Dogsa T, Batic D. Skuteczność rozwoju opartego na testach: studium przypadku przemysłowego. Software Quality Journal. 2011; 19 (4): 643–661. Uderzyło mnie, że pomiary stosowane w wielu badaniach wokół TDD opierają się na liniach kodu, defektach i czasie poświęcanym na rozwój.

Czy istnieją jakieś badania, które koncentrują się na całkowitych kosztach posiadania produktów opracowanych przy użyciu TDD w porównaniu z tradycyjnym opracowaniem lub testem końcowym?

Szczególnie interesuje mnie całkowity koszt pozyskania i koszty operacyjne.

— Patrik Björklund
źródło

3

Istnieją badania dotyczące implikacji i korzyści płynących z zastosowania TDD, ale wyniki są sprzeczne. Niektóre projekty (z mojego doświadczenia) mają mniejszy wskaźnik błędów i niższy koszt posiadania w wyniku korzystania z TDD, ponieważ koszt zmiany funkcji drastycznie spada. Niektóre inne zostają zatrzymane.

Niektóre badania ( tutaj jest jeden - slajd n50) pokazują, że liczba błędów wzrosła wraz z zasięgiem. Zakładam, że większy zasięg oznacza TDD i że większa liczba błędów oznacza wyższy koszt posiadania.

Z mojego punktu widzenia żadna metryka lub praktyka sama w sobie nie może być związana z lepszą jakością lub niższym kosztem posiadania. Istnieje kombinacja czynników, które mogą prowadzić do pewnej korelacji. Te czynniki zmieniają się między zespołami i projektami.

Myślę, że wszyscy słyszeliśmy historie zespołów, które właśnie zaczęły robić TDD, pisząc 100-liniowe metody testowe, co (moim zdaniem) zwiększa koszt posiadania, ponieważ aktualizacja tego testu będzie kosztowna.

Moją pragmatyczną zasadą jest to, że ludzie, którym zależy i chcą się uczyć , pracują w środowisku, które ich wspiera, a ich pomysły mają lepszą jakość i koszty posiadania.

— Augusto
źródło

slide n50 jest bardzo mylący. „Im większy zasięg, tym więcej błędów” najprawdopodobniej oznacza „im większy zasięg, tym więcej błędów ... znajdziesz”. Jest to możliwe, ale wątpię, aby większe pokrycie doprowadziło do większej liczby wstrzykniętych wad. Oznacza to po prostu, że im większe pokrycie, tym wyższa wydajność defektu poza fazą rozwoju. I tak, istnieje wiele wskaźników, które mogą mierzyć jakość i koszt posiadania - # wstrzykiwane defekty po fazie, wydajność defektów po fazie i przeróbki są mierzalnymi rzeczami mającymi bezpośredni wpływ na jakość i koszt. Zobacz PSP / TSP, aby uzyskać świetne przykłady tych wskaźników.

— Michael

Michael, w kontekście tego slajdu, prezenter pokazuje, co koreluje z wyższą gęstością błędów. Jedną z miar były przypadki testowe, więc im więcej przypadków testowych ma klasa, tym wyższy będzie błąd w klasie. Prezenter próbuje powiedzieć, że żadna metryka sama w sobie nie koreluje z mniejszą gęstością błędów.

— Augusto

0

Nie mam żadnych konkretnych badań, ale mogę powiedzieć ci z własnego doświadczenia, a z doświadczeń innych programistów wiem, że przy prawidłowym zastosowaniu do średnich i dużych projektów TDD skraca czas wprowadzania na rynek, zmniejsza błędy i usterki oraz poprawia jakość kodu .

Powiedziawszy, że nie są to srebrne kule, czy możesz napisać dobry kod bez TDD? tak, czy możesz napisać zły kod za pomocą TDD tak. Również w zależności od projektu TDD może znacznie zwiększyć koszt posiadania kodu, dobrym przykładem jest NASA, gdzie koszt na linię kodu jest ogromny, ale koszt posiadania nie jest najważniejszy, to brak wad.

Przy prawidłowym zastosowaniu TDD zwiększy koszty początkowe i bazę kodu, ale zyskujesz długoterminowe korzyści z testowania regresji, wczesnego wykrywania błędów i lepszego projektowania kodu, który powinien zmniejszyć wady i koszty testowania oraz czas konserwacji, a tym samym zmniejszyć ogólny koszt własność.

— Bob The Janitor
źródło