Nie mam żadnych dokumentów naukowych ani statystyk, które mogę ci przekazać, ale opowiem o swoich doświadczeniach z pracy w zespole / organizacji, która historycznie miała niską do średniej liczbę testów jednostkowych i żadnych testów kompleksowych, i stopniowo przesunięcie poprzeczki do miejsca, w którym jesteśmy teraz, z bardziej ATDD (ale, o ironio, nie tradycyjnym TDD).
W szczególności tak wyglądały harmonogramy projektu (i wciąż rozgrywane w innych zespołach / produktach w tej samej organizacji):
- Do 4 tygodni analizy i wdrożenia
- 2 tygodnie testów regresji, naprawy błędów, stabilizacji i przygotowania do wydania
- 1-2 tygodnie naprawy znanych usterek
- 2-3 tygodnie czyszczenia kodu i problemów postprodukcyjnych / wsparcia (nieznane wady / nieplanowane przestoje)
Wydaje się to niedorzeczne, ale w rzeczywistości jest bardzo powszechne, po prostu często jest maskowane w wielu organizacjach przez brak lub nieskuteczną kontrolę jakości. Mamy dobrych testerów i kulturę intensywnych testów, więc te problemy są wychwytywane wcześnie i naprawiane (przez większość czasu), a nie wolno im grać powoli przez wiele miesięcy / lat. 55-65% kosztów utrzymania jest niższe niż powszechnie przyjęta norma 80% czasu poświęcanego na debugowanie - co wydaje się rozsądne, ponieważ mieliśmy pewne testy jednostkowe i zespoły międzyfunkcyjne (w tym QA).
Podczas pierwszego wydania naszego zespołu przez nasz najnowszy produkt zaczęliśmy modernizować testy akceptacyjne, ale nie były one dość wymagające i wciąż musieliśmy polegać na wielu testach ręcznych. Wydanie było nieco mniej bolesne niż inne, IMO częściowo z powodu naszych przypadkowych testów akceptacyjnych, a także częściowo z powodu naszego bardzo wysokiego zasięgu testów jednostkowych w porównaniu z innymi projektami. Mimo to spędziliśmy prawie 2 tygodnie na regresji / stabilizacji i 2 tygodnie na kwestiach poprodukcyjnych.
Natomiast każde wydanie od pierwszego wydania miało kryteria wczesnej akceptacji i testy akceptacyjne, a nasze obecne wersje wyglądają następująco:
- 8 dni analizy i wdrożenia
- 2 dni stabilizacji
- 0-2 połączone dni wsparcia poprodukcyjnego i czyszczenia
Innymi słowy, przeszliśmy od 55–65% kosztów utrzymania do 20-30% kosztów utrzymania. Ten sam zespół, ten sam produkt, a główną różnicą jest stopniowe doskonalenie i usprawnianie naszych testów akceptacyjnych.
Koszt ich utrzymania wynosi na sprint 3-5 dni dla analityka ds. Kontroli jakości i 1-2 dni dla programisty. Nasz zespół ma 4 programistów i 2 analityków ds. Kontroli jakości, więc (nie licząc UX, zarządzania projektami itp.) To maksymalnie 7 osobodni na 60, które zaokrąglić do 15% narzutów związanych z wdrożeniem bezpieczna strona.
Wydajemy 15% każdego okresu wydania na opracowanie automatycznych testów akceptacyjnych, a tym samym jesteśmy w stanie wyciąć 70% każdego wydania, przeprowadzając testy regresji i naprawiając błędy przedprodukcyjne i postprodukcyjne.
Być może zauważyłeś, że druga oś czasu jest znacznie bardziej precyzyjna, a także znacznie krótsza niż pierwsza. Jest to możliwe dzięki wstępnym kryteriom akceptacji i testom akceptacyjnym, ponieważ znacznie upraszcza „definicję ukończenia” i pozwala nam być znacznie bardziej pewnym stabilności wydania. Żadnemu innemu zespołowi (jak dotąd) nie udało się wydać dwutygodniowego harmonogramu wydań, chyba że robią to dość trywialne wydania konserwacyjne (tylko poprawki błędów itp.).
Kolejnym interesującym efektem ubocznym jest to, że byliśmy w stanie dostosować nasz harmonogram wydań do potrzeb biznesowych. Pewnego razu musieliśmy go wydłużyć do około 3 tygodni, aby zbiegło się to z kolejną wersją, i byliśmy w stanie to zrobić, zapewniając większą funkcjonalność, ale bez poświęcania dodatkowego czasu na testowanie lub stabilizację. Innym razem musieliśmy skrócić go do około 1,5 tygodnia z powodu świąt i konfliktów zasobów; musieliśmy podjąć mniej pracy programistów, ale zgodnie z oczekiwaniami mogliśmy spędzić odpowiednio mniej czasu na testowaniu i stabilizacji bez wprowadzania jakichkolwiek nowych wad.
Z mojego doświadczenia wynika zatem, że testy akceptacyjne, zwłaszcza gdy są wykonywane bardzo wcześnie w projekcie lub sprincie, i gdy są dobrze utrzymane zgodnie z kryteriami akceptacyjnymi napisanymi przez właściciela produktu, są jedną z najlepszych inwestycji, jakie możesz zrobić. W przeciwieństwie do tradycyjnego TDD, na co inni słusznie wskazują, skupia się bardziej na tworzeniu testowalnego kodu niż kodu bez wad - ATDD naprawdę pomaga znacznie szybciej wykrywać defekty ; jest to organizacyjny odpowiednik posiadania armii testerów codziennie wykonujących pełny test regresji, ale o wiele tańszy.
Czy ATDD pomoże ci w długoterminowych projektach wykonanych w stylu RUP lub (ugh) Waterfall, projektach trwających 3 miesiące lub dłużej? Myślę, że jury wciąż nie bierze udziału w tym. Z mojego doświadczenia wynika, że największym i najbrzydszym ryzykiem w długoterminowych projektach są nierealne terminy i zmieniające się wymagania. Nierealistyczne terminy spowodują, że ludzie zaczną używać skrótów, w tym skrótów testowych, a znaczące zmiany wymagań prawdopodobnie unieważnią dużą liczbę testów, wymagając ich przepisania i potencjalnie zwiększając koszty wdrożenia.
Jestem prawie pewien, że ATDD ma fantastyczną wypłatę dla modeli Agile lub zespołów, które oficjalnie nie są Agile, ale mają bardzo częste harmonogramy wydawania. Nigdy nie próbowałem tego w długoterminowym projekcie, głównie dlatego, że nigdy nie byłem w żadnej organizacji, ani nawet nie słyszałem o organizacji, która chciałaby wypróbować ten projekt, więc wstaw tutaj standardowe wyłączenie odpowiedzialności. YMMV i tak dalej.
PS W naszym przypadku „klient” nie wymaga dodatkowego wysiłku, ale mamy dedykowanego, pełnoetatowego właściciela produktu, który faktycznie zapisuje kryteria akceptacji. Podejrzewam, że jeśli zajmujesz się oprogramowaniem konsultingowym, o wiele trudniej będzie skłonić użytkowników końcowych do napisania użytecznych kryteriów akceptacji. Właściciel produktu / Product Manager wydaje się być bardzo istotnym elementem do wykonywania ATDD i chociaż mogę ponownie mówić tylko z własnego doświadczenia, nigdy nie słyszałem o tym, że ATDD jest skutecznie praktykowany bez kogoś, kto pełniłby tę rolę.
