Temat: Test Driven Development

Czy ktoś może ma jakieś wiarygodne źródło mówiące o kosztach wykrycia i naprawiania błędów na różnym poziomie testowania (unit, integration, acceptance). Kiedyś chyba coś takiego widziałem, ale teraz nie mogę odszukasz. Interesują mnie również badania porównujące koszty utrzymania-rozwoju systemu, który był wykonywany zgdonie z TDD i takiego, który nie był.

Temat: Test Driven Development

Znalezienie takich badań jest trochę problematyczne. Mało kto lubi się chwalić przepisem na sukces. Widziałem natomiast wiarygodne badania porównujące metodyki zwinne (Agile) z tymi "ciężkimi". Być może będzie to dla Ciebie przydatne.Aleksander Olszewski edytował(a) ten post dnia 05.07.11 o godzinie 09:20

Temat: Test Driven Development

Sebastian Nowak:
Czy ktoś może ma jakieś wiarygodne źródło mówiące o kosztach wykrycia i naprawiania błędów na różnym poziomie testowania (unit, integration, acceptance).

Tja. Szef się nie zgadza i chce twardych danych finansowych? Pieniądze to nie wszystko, jeszcze jest satysfakcja klienta.

Takich rzeczy nie znajdziesz. Należało by wytworzyć aplikację bez TDD i puścić ją na rynek. Zresetować mózgi deweloperów, zrobić to samo w tym samym teamie ale z TDD i przy zgłaszaniu błędów przez klienta sprawdzać ile kosztuje naprawa i czy ten błąd istnieje w systemie z TDD. Wtedy niewierny Tomasz dotknąłby rany i uwierzył :)

Temat: Test Driven Development

Koszt wykrycia i naprawienia błędu to nie wszystko, co powinno mieć wpływ na wybór technik wytwarzania oprogramowania. Kluczowy jest biznes, który systemy wspierają. Jeśli koszt wykrycia, naprawienia, przetestowania i wdrożenia poprawki wyniesie 1md, nawet na produkcji, to nie wydaje się to jakimś dramatycznym kosztem. No chyba, że to kluczowy dla Klienta system, a jeden dzień przestoju generuje setki tysięcy złotych strat. Techniki powinny być dobrane do skali, złożoności i krytyczności systemu dla Klienta.

Trzeba też pamiętać, że TDD wymaga utrzymywania tak naprawdę dwóch projektów - głównego oraz samych testów. Co samo w sobie powoduje zwiększenie kosztów. Jeżeli budujemy prosty system, który nie będzie się często zmieniał, to TDD ograniczyłbym tylko do najbardziej kluczowych elementów. W przypadku bardzo złożonych systemów, warto zainwestować nie tylko w TDD, ale i warto pójść krok dalej i zautomatyzować testy integracyjne oraz testy procesów biznesowych.

Generalnie z testami jest jak z ubezpieczeniem. Jak kupimy samochód za 10 000 i płacimy ubezpieczenie 1 000 rocznie, a przez 10 lat nic się nie stało, to ponieśliśmy niepotrzebne koszty, ale jak ktoś nam ten samochód 'skasuje', to wydaje się, że ubezpieczenie nie było takim głupim pomysłem:)

Temat: Test Driven Development

Krystian robiłem w pracy prezentację o TDD i chciałem mieć jak najwięcej argumentów.
Podoba mi się analogia do ubezpieczenia, postaram się ją zapamiętać.

Temat: Test Driven Development

Moje 5 groszy (my stosujemy TDD dość ortodoksyjnie):

Łukasz pisze o testowaniu a nie TDD, to związane (oczywiście) tematy, ale nie to samo. TDD to głównie proces projektowania, pisania i dokumentowania systemu, a więc generalnie jego wytwarzania, a w mniejszym stopniu proces tworzenia testów. Teoretycznie można utworzyć system wykorzystując TDD (by utworzyć go w wysokiej jakości) a następnie wywalić testy (taaaa...) TDD nie służy więc posiadaniu testów do "wykrycia, naprawienia, przetestowania i wdrożenia poprawki", ale do wytworzenia produktu.

Oczywiście analogia do ubezpieczenia jest poprawna (jest to pewna inwestycja, choć jak sądzę rzędu parunastu procent przy programistach z umiejętnościami i wiedzą o TDD), z jednym wyjątkiem - normalnie ubezpieczasz siebie, więc sam bierzesz odpowiedzialność za ewentualne własne problemy. Z softwarem to ubezpieczenie dotyczy klienta, który w większości przypadków nie ma możliwości zweryfikowania różnicy jakości z testami i bez (a już w ogóle dobrze i źle zaprojektowanego), a łatwo wpada w pułapkę optymizmu, bełkotu marketingowego dostawcy itp. Za to łatwo mu podjąć decyzję czy ma być trochę szybciej czy trochę wolniej... Ma więc mentalną dysproporcję wiedzy i wartości przy podejmowaniu decyzji.

Natomiast zdanie "Trzeba też pamiętać, że TDD wymaga utrzymywania tak naprawdę dwóch projektów" jest nieprawdziwe. Z trzech powodów: po pierwsze to ten sam projekt - to samo API, te same funkcjonalności, itp. Po drugie to nie są równej wielkości bazy kodu, więc nie jest to tym bardziej 2x kod produkcyjny. Po trzecie (przynajmniej w językach statycznie typowanych) większość zmian w kodzie można zrealizować przez automatyczną refaktoryzację, więc wielu zmian utrzymaniowych nie trzeba w ogóle dokonywać więcej niż raz. A zmiany biznesowe są dużo łatwiejsze do zrealizowania przez zmianę od strony testu a nie implementacji, bo test ma wyłożone czarno na białym o co chodzi i jak ma być w nowej wersji.

Podsumowując - patrzenie na TDD z punktu widzenia posiadania testów powoduje faktycznie zastanawianie się, czy to się opłaca, czy błędów będzie dużo i jak trudno je będzie poprawić. A więc zapędzanie się samemu w gdybanie i huraoptymizm. Jeśli TDD to dla nas sposób pracy (tak tworzymy kod, a testy są tylko "pożądanym efektem ubocznym"), to nie ma pytania czy stosować TDD, tylko jak się nauczyć tworzyć kod wysokiej jakości. Tak więc jeśli w ogóle pytać biznes o to, to należy sformułować pytanie tak: "Czy jakość jest dla Ciebie drugorzędna, tylko chcesz np. wybadać rynek i zainwestować minimum, czy ma to być produkt docelowy?". Z resztą nawet sam Kent Beck tworząc JUnitMax zrobił go bez testów chcąc zobaczyć najpierw reakcję rynku. Należy jednak pamiętać, że jak już rynek odpowie pozytywnie, to może się okazać, że nie ma już czasu na dopisanie testów / przepisanie systemu, tylko trzeba się ratować... To też pewnie warto zaplanować.

Kurcze, długie to 5 groszy... ;-)