Czy ktoś stosuje zasadę z reguły do oszacowania wysiłku wymaganego do testowania jako procent wysiłku wymaganego do rozwoju? A jeśli tak, jaki procent wykorzystujesz?oszacowanie wysiłku testowego jako procent czasu rozwoju
Kiedy oceniasz testy, musisz określić zakres testów - czy mówimy o teście jednostkowym, funkcjonalnym, UAT, interfejsie, bezpieczeństwie, obciążeniu wydajnościowym i wolumenie?
Jeśli pracujesz nad projektem kaskadowym, prawdopodobnie masz pewne zadania, które są dość stałe. Daj czas na przygotowanie wszelkich dokumentów planistycznych, harmonogramów i raportów.
Dla fazy testów funkcjonalnych (jestem "testerem systemu", więc to jest mój główny punkt odniesienia), nie zapomnij uwzględnić planowania! Sprawa testowa często wymaga co najmniej tyle wysiłku, aby wyodrębnić z historii wymagań/specyfikacji/użytkownika, jak to będzie wymagało wykonania. Dodatkowo musisz poświęcić trochę czasu na podnoszenie/testowanie defektów. Dla większego zespołu musisz uwzględnić zarządzanie testami - planowanie, raportowanie, spotkania.
Ogólnie moje szacunki są oparte na złożoności dostarczanych funkcji, a nie na procencie wysiłku twórców. Jednak wymaga to dostępu do zestawu instrukcji na co najmniej wysokim poziomie. Lata przeprowadzania testów pozwalają mi stwierdzić, że test o określonej złożoności wymaga x godzin wysiłku na przygotowanie i wykonanie. Niektóre testy mogą wymagać dodatkowego wysiłku podczas konfiguracji danych. Niektóre testy mogą wymagać negocjacji z systemami zewnętrznymi i trwać znacznie dłużej niż wymagany wysiłek.
Koniec końców należy jednak przejrzeć go w kontekście całego projektu. Jeśli twoje szacunki są znacznie wyższe niż dla BA lub Development, może być coś nie tak z twoimi bazowymi założeniami.
Wiem, że to stary temat, ale jest to coś, co w tej chwili wracam i jest od zawsze interesujący dla kierowników projektów.
testowania Google Blog discussed this problem recently:
Więc odpowiedź jest naiwny, że pisanie testu niesie podatku 10%. Ale płacimy podatki, aby uzyskać coś w zamian.
(wycinek)
Te korzyści przekładają się na rzeczywistą wartość dzisiaj, jak jutro. Piszę testy, ponieważ dodatkowe korzyści dostaję więcej niż zrekompensuję dodatkowy koszt 10%. Nawet jeśli nie uwzględnię długoterminowych korzyści, wartość, jaką otrzymam z testu dzisiaj, jest tego warta. Szybciej rozwijam kod z testem. Ile, to zależy od złożoności kodu. Im bardziej złożone jest to, co próbujesz zbudować (więcej ifs/loops/dependencies), tym większa korzyść z testów.
Kilka lat temu, w dziedzinie bezpieczeństwa krytycznego, usłyszałem coś takiego jak jeden dzień dla jednostki testującej dziesięć linii kodu.
Zauważyłem również 50% nakładów na rozwój i 50% na testowanie (nie tylko testowanie jednostkowe).
Czy mówisz o zautomatyzowanych testach jednostkowych/integracyjnych lub testach ręcznych?
Dla pierwszego z nich moja zasada (w oparciu o pomiary) wynosi 40-50% czasu dodanego do czasu rozwoju, tzn. Jeśli opracowanie przypadku użycia zajmuje 10 dni (przed kontrolą jakości i poważnym naprawieniem błędów), pisanie dobrych testów bierze inny 4 do 5 dni - choć najlepiej powinno się to stać przed i podczas rozwoju, a nie później.
Czas testu jest prawdopodobnie silniej skorelowany z zakresem funkcji niż z czasem wywoływania. Podejrzewam również (być może kontrowersyjnie), że czas testowania jest skorelowany z umiejętnościami twojego zespołu programistów.
W przypadku trwających od 6 do 9 miesięcy prac nad rozwojem, wymagam absolutnie minimalnego 2-tygodniowego okresu testowania, wykonywanego przez rzeczywistych testerów (nie zespół programistów), którzy są dobrze zorientowani w oprogramowaniu, które będą testować (tj. , 2 tygodnie nie uwzględniają czasu na rozruch). To jest dla projektu, który ma ~ 5 programistów.
Jedyny moment, w którym biorę pod uwagę dodatkowy czas na testowanie, to fakt, że nie jestem zaznajomiony z technologią testową, której będę używał (np. Po raz pierwszy przy użyciu testów Selenium). Następnie mogę wziąć pod uwagę 10-20% za przyspieszenie działania narzędzi i stworzenie infrastruktury testowej.
W przeciwnym razie testowanie jest tylko wrodzoną częścią programowania i nie gwarantuje dodatkowego oszacowania. W rzeczywistości prawdopodobnie zwiększyłbym szacunek dla kodu wykonanego bez testów.
EDYCJA: Zauważ, że zazwyczaj piszę test kodu najpierw. Jeśli mam przyjść po fakcie i napisać testy dla istniejącego kodu, które spowodują spowolnienie. Nie uważam, że ten test-pierwszy rozwój spowalnia mnie w ogóle, z wyjątkiem bardzo odkrywczego (czytaj: wyrzucania) kodowania.
Kiedy mówisz o testach, możesz oznaczać rozwój wodospadu lub zwinnego testu. W zwinnym środowisku programiści powinni poświęcić 50% czasu na opracowywanie i utrzymywanie testów.
Ale to 50% dodatkowego będzie zaoszczędzić czasu, gdy przychodzi czas ponownego faktoringu i ręcznej weryfikacji.
Zdaję sobie sprawę, że nie byłem zbyt jasny. Przeprosiny. Mówię o tym w kontekście przygotowywania oferty dla klienta i stosowania metodologii, która jest bardziej wodospad niż zwinna. Klienci chcą wiedzieć, jaki jest budżet. Musimy nadać im realistyczną postać, ale jednocześnie uchronić się przed nieznanymi gazetami, które czekają tak wcześnie w projekcie. Zwykle zgadzamy się na stałą wycenę w celu sprecyzowania i określenia zakresu projektu; ale tylko wskazują na iteracje/fazy, które następują po tym. –
Sędzia według wczorajszej pogody. Ile czasu minęło ostatnim razem? Czy trendujesz dłużej lub krócej? Każdy sklep jest inny.
Najbardziej zwinne sklepy potrzebują dużo mniej czasu, mają drastycznie mniej wad i szybszy czas na ich rozwiązanie z powodu TDD. Mimo to, najbardziej zwinne sklepy mają pewien wymierny czas spędzony na testowaniu/kontroli jakości.
Jeśli jest to pierwsze uruchomienie testowe dla tej aplikacji, wówczas odpowiedź brzmi "wyświetlaj", po czym następuje próba. To zależy od tego, jak szybko można uzyskać odpowiedzi na pytania, - jak testować to, - ile cechy/funkcje - ile odkrycia wad - jak szybko problemy zostaną rozwiązane, - ile razy cykle kod poprzez testowanie i - ile razy testowanie jest blokowane przez błędy . Nie ma sposobu, aby powiedzieć. Możesz nazwać to 50% lub 175% lub więcej i nie mylisz się. Dlaczego nie zgadnąć i pomnożyć przez Pi? To nie będzie dużo gorsze niż jakakolwiek inna odpowiedź, którą możesz wymyślić.
Należy (musi) wiedzieć, jak długo trwa teraz i czy robi się szybciej lub wolniej oraz czy zasięg zwiększa się, czy maleje. Z tymi trzema bitami informacji powinieneś być w stanie odgadnąć całkiem dobrze.
Gartner w październiku 2006 r. Stwierdza, że testowanie zwykle pochłania od 10% do 35% pracy nad projektem integracji systemu. Zakładam, że dotyczy to metody wodospadu. Jest to dość szeroki zakres - ale istnieje wiele zależności od ilości dostosowań do standardowego produktu i liczby systemów, które mają zostać zintegrowane.
Z mojego doświadczenia wynika, że 25% wysiłku poświęcono na analizę; 50% na projekt, rozwój i test jednostkowy; pozostałe 25% na testowanie. Większość projektów mieści się w granicach +/- 10% tej zasady, w zależności od charakteru projektu, wiedzy o zasobach, jakości danych wejściowych, itp. Można dodać koszty zarządzania projektem w ramach tych wartości procentowych lub jako napowietrzne u góry w zakresie 10-15%.
Dla bezpieczeństwa krytycznego jest to również stosunek 10 linii testu do każdej linii kodu. –
Czy ktoś ma renomowane odniesienie do tej statystyki? – Steztric