Ile to potrwa i dlaczego tak długo – czyli o estymacjach w testowaniu (i nie tylko)

5 Styczeń 2018
1 Komentarze

Tytułowe pytanie pojawia się bardzo często w codziennej pracy. Zadają je kierownicy projektu, dyrektorzy, przedstawiciele zarządu firmy. Jak na nie odpowiadać? Jak radzić sobie w przypadku dużej zmienności i niepewności będącej nierozłączną częścią projektów informatycznych?

Czym jest estymacja?

Na początek zajrzyjmy do słownika ISTQB® (wersja 2.3 2014) „szacowanie testów: Obliczona aproksymacja wyniku związana z różnymi aspektami testowania (takimi jak wysiłek, data zakończenia, poniesione koszty, ilość przypadków testowych itp.), która jest użyteczna, nawet gdy dane wejściowe są niekompletne, niepewne lub zakłócone.

Brzmi trochę skomplikowanie, prawda?

W praktyce spotkasz się najczęściej z pytaniami o oszacowanie:

  • ilości pracy potrzebnej do zrealizowania zadania, serii zadań lub całego procesu testowego. W tym przypadku istotna jest ilość godzin lub dni pracy związanej z testowaniem.
  • czasu trwania – wbrew pozorom jest to coś zupełnie innego niż ilość pracy. Zdarzają się projekty, gdzie budżet jest sprawą drugorzędną, a czas dostarczenia staje się krytyczny (na przykład, gdy konkurencja również planuje uruchomienie podobnego produktu). Oszacuj więc ilość pracy, a następnie zaplanuj jej realizację w czasie. Ważne, aby uwzględnić dni wolne, zaplanowane nieobecności a także przewidzieć pewien zapas wynikający z analizy ryzyka (na przykład choroba lub odejście kluczowej osoby z zespołu).
  • budżetu – jeżeli będziemy pytani o opracowanie budżetu procesu testowego, to poza kosztami wynikającymi z ilości pracy, należy doliczyć jeszcze opłaty takie jak: licencje, sprzęt, delegacje, zewnętrzne konsultacje, szkolenia wymagane do realizacji projektu (zewnętrzne lub wewnętrzne). Warto również zostawić pewien margines na nieprzewidziane wydatki, który finalnie może zostać przeznaczony na wspólne świętowanie sukcesu projektu (o ile wszystko pójdzie zgodnie z planem).

Jakie są istotne czynniki wpływające na estymacje?

Wiemy już czym jest szacowanie i jakich obszarów głównie dotyczy. Kolejnym krokiem jest przeanalizowanie uwarunkowań dotyczących projektu i zespołu, które mogą wpłynąć na oczekiwany zakres i dokładność estymacji. Co zatem wpływa na estymację? 

 

Typ umowy (kontraktu)

Najczęściej mamy do czynienia z umowami typu:

  • Projekty ze stałym budżetem (fixed price)  – w tej sytuacji zamawiający/zleceniodawca i dostawca/wykonawca umawiają się na konkretną kwotę za realizację projektu (ewentualnie z dodatkową premią).  Estymując zadania testowe w takiej formie, należy między innymi:
    • wykonać to bardzo skrupulatnie, poświęcając odpowiednią ilość czasu,
    • zweryfikować estymacje z przynajmniej jeszcze jedną osobą,
    • przewidzieć margines na nieoczekiwane sytuacje i problemy,
    • uwzględnić wszelkie dodatkowe koszty związane z realizacją.
  • Projekty rozliczane według poniesionych kosztów (time & material, cost-reimbursable) – istnieje wiele odmian projektów rozliczanych według faktycznie poniesionych kosztów. Jeżeli interesują Cię szczegóły, zajrzyj na przykład do PMBOK® Guide. Z perspektywy szacowania testów należy zwykle:
    • oszacować zgrubny budżet, najczęściej w formie górnego limitu, który nie może zostać przekroczony (bez wchodzenia w szczegóły),
    • bardzo dokładnie raportować ponoszone wydatki, co ułatwia późniejsze przeniesienie ich na zamawiającego (jako formalne refakturowanie lub według ustalonych wcześniej stawek zawierających marże dostawcy).

 

Zakres i czas trwania projektu

Przystępując do estymacji działań testowych, należy znać odpowiedź na następujące pytania:

  • czy plan projektu obejmuje całość działań? Czy produkt będzie dostarczany w iteracjach,  które będą posiadały każdorazowo konkretny budżet i termin realizacji? Ten drugi przypadek jest dużo korzystniejszy, gdyż nawet popełniając błąd oszacowania w pierwszej czy drugiej iteracji, będziesz w stanie naprawić go później i prawdopodobnie uratować finalny budżet przewidziany na testy. Jeżeli wymagane jest oszacowanie całości projektu od razu, poświęć temu zadaniu odpowiednią ilość czasu.
  • czy zakres projektu obejmuje komplet działań związanych z dostarczeniem oprogramowania? Czy celem projektu są tylko testy? W pierwszej sytuacji w zakresie projektu znajdzie się m.in. analiza wymagań, projektowanie, wykonanie, testowanie, wdrożenie, utrzymanie i wiele innych działań. Daje to pewien komfort i miejsce na margines błędu w oszacowaniach, gdyż przekroczenie budżetu w jednym z tych działów może zostać skompensowane nadwyżką z innego. Przypadek, gdy testowanie jest osobnym projektem (często spotykane w outsourcingu) będzie dla Ciebie sporym wyzwaniem. W takiej sytuacji planuj naprawdę dokładnie, analizuj ryzyka i skonsultuj plan z doświadczonymi menedżerami.

 

Metodyka realizowania projektu

Chyba wszyscy doskonale wiedzą co pojawi się w tym punkcie,:) więc tak tylko dla formalności wspomnę o konieczności uwzględnienia podejścia do realizacji projektu tj. zwinne czy kaskadowe? W pierwszej sytuacji szacujemy dokładnie tylko najbliższy okres, a pozostała część projektu jest bardzo ogólnie oszacowana. W tym drugim przypadku potrzebujemy znać wycenę dla całego projektu od razu.

Skład zespołu

Dobieranie członków zespołu pod konkretny projekt jest niezmiernie ważne i wpływa znacząco na oszacowanie działań testowych. Pamiętaj o uwzględnieniu:

  • doświadczenia zawodowego – początkujący tester wykona zadanie dużo wolniej niż doświadczony, jednak koszty będą w obu przypadkach zupełnie różne. Co jest dla Ciebie ważniejsze?
  • znajomości branży – jeżeli projekt wymaga sporej wiedzy domenowej, pamiętaj o oszacowaniu czasu koniecznego na jej zdobycie. Być może jest w zespole ktoś, kto posiada taką wiedzę a brakuje mu innych umiejętności, które jednak łatwiej (i taniej) można uzupełnić?
  • kompetencji zespołu – czasami wymagania projektu nie są możliwe do zrealizowania przez zespół np. skomplikowane testy bezpieczeństwa. Wynajęcie zewnętrznej firmy może być tańsze niż przeszkolenie zespołu, jednak w tym drugim przypadku wiedza zostanie w firmie i przyda się w kolejnych projektach.

Zadania testowe – co warto oszacować?

Teraz skupimy się na konkretach już typowo związanych z testowaniem. Czasami początkujący liderzy zespołów testerskich błędnie estymują tylko czas wykonania poszczególnych testów (t.j. przypadków testowych, scenariuszy). Z mojego doświadczenia, minimalny zakres jaki należy brać pod uwagę to:

  • czas potrzebny na planowanie testów (czyli również na ich estymację) oraz zarządzanie (aktualizacja planu, raportowanie postępu, spotkania z zespołem itp.).
  • przygotowanie testów w tym opracowanie scenariuszy testowych czy przypadków testowych oraz wszelkie prace związane ze środowiskiem testowym, narzędziami itp.
  • wykonywanie testów – pełny cykl testowy dla określonego zakresu.
  • raportowanie błędów – jeżeli system ma sporo błędów, to ich zgłaszanie może być naprawdę czasochłonne. Zastanów się, ile czasu zajmuje opisanie kroków, dodanie zrzutu ekranu lub filmu?
  • retesty, czyli weryfikacja błędów. W trakcie retestów zwykle okazuje się, że jakaś część błędów nie została naprawiona lub pojawiły się nowe defekty. Konieczne jest więc powtarzanie tego kroku.
  • testy regresji, które są konieczne po każdym większym wydaniu wersji, w celu sprawdzenia czy naprawione błędy nie spowodowały nowych defektów.  Określ jaki zakres jest krytyczny dla działania systemu i oszacuj czasochłonność takiej weryfikacji.
  • cykle testowe – oszacuj, ile pełnych cykli testowych będzie potrzebnych do wydania stabilnej wersji oprogramowania.
  • przygotowanie i utrzymanie automatyzacji – jeżeli decydujesz się na automatyzację testów, uwzględnij czas i koszt jej wprowadzenia oraz utrzymania.
  • dokumentacja – w zależności od specyfikacji projektu, może być koniecznie przygotowanie dokładnej dokumentacji z testów (np. systemy medyczne).
  • testy niefunkcjonalne – często pomijane w oszacowaniu i zwykle generują spore koszty w projektach. Dzieje się tak ze względu na to, że wymagają często specjalistycznej wiedzy i narzędzi, a także z powodu wykrywania przez nie dużej liczby błędów, gdyż często te aspekty są pomijane na etapie wytwarzania, co w konsekwencji wiąże się z koniecznością częstego ich powtarzania.

Jak szacować – techniki estymacji?

Wiesz już co należy estymować, w jakim zakresie i jakiego typu zadania należy szacować. Teraz poznasz odpowiedź na pytanie „jak?”. Podstawowe techniki estymacji to:

  • Ocena ekspercka – osoba, która posiada duże doświadczenie i wiedzę dokonuje oszacowania działań testowych.
  • Estymacja na podstawie historycznych danych – jeżeli projekt jest podobny do uprzednio zrealizowanego  i warto skorzystać z takich informacji. Jest to wygodny i prosty sposób, który jednak może być obarczony dużym błędem – w przypadku, gdy okaże się, że projekty nie są aż tak bardzo podobne.
  • Estymacja w oparciu o parametry projektu – metoda dość złożona, ale w dłuższej perspektywie daje przyzwoite rezultaty. Może również stanowić drugie źródło weryfikacji dla oceny eksperckiej. W podejściu tym opracowujemy wzory matematyczne, które obliczają czasochłonność lub budżet na podstawie wprowadzonych parametrów. W naszym przypadku danymi wejściowymi może być na przykład ilość punktów funkcyjnych i ich złożoność. Jednym z klasycznych przykładów zastosowania tego podejścia jest model COCOMO.
  • Trzypunktowa estymacja – określamy najbardziej optymistyczny scenariusz, średni oraz pesymistyczny. Finalna wartość estymacji jest średnią tych liczb, przy czym wzór może być modyfikowany poprzez zastosowanie innych wag dla parametrów, przykładowo: (opt. + 3 x śr. + pes)/5. Takie podejście stosuje się, gdy brakuje danych historycznych lub projekt obarczony jest dużym ryzykiem.
  • Estymacje „od dołu do góry” (bottom-up) – bardzo dokładna technika, ale zarazem czasochłonna i czasami wręcz niemożliwa do wykonania. Wymaga estymacji niskopoziomowych zadań w projekcie a następnie pogrupowania ich i zsumowania. W projektach typowo zwinnych jest to więc niemożliwe w dłuższym horyzoncie czasowym.
  • Spotkania, głosowania – wszelkie interaktywne dyskusje, które mają na celu wypracowanie wspólnych szacunków. Tego typu szacowanie ma miejsce w podejściu zwinnym przed każdą iteracją, ale można je także zaaplikować do wyceny dłuższych etapów lub nawet całego projektu.

Na zakończenie

Uwzględnienie powyższych czynników znacznie poprawi proces estymacji i uczyni go bardziej wiarygodnym.

Pamiętaj jednak o kilku ważnych aspektach:

  • Syndrom studenta, czyli odkładanie wszystkiego na ostatni moment. Jeżeli zespół z którym pracujesz ma taką tendencję, przygotuj dwie wersje estymacji – jedną oficjalną dla kierownictwa i drugą dla zespołu, w której przesuniesz terminy, aby zwiększyć motywację odpowiednio wcześniej.
  • Nie ufaj „ekspertom” – wcześniej wspominałem o technice polegającej na ocenie eksperckiej, skąd więc taka zmiana? Na co dzień spotkasz wielu doradców oferujących swoje wsparcie. Chociaż z pozoru wygląda to rewelacyjnie, to nie zawsze ich porady będą zgodne z Twoimi oczekiwaniami. Dlaczego? Po pierwsze świadomie bądź nie, będą nastawieni na realizację własnych celów. Po drugie, prezes zarządu, kierownik projektu czy lider techniczny nie mają odpowiedniej wiedzy, aby estymować zadania testerskie. Daniel Kahneman, laureat Nagrody Nobla za badania nad mechanizmami działania ludzkiego umysłu, opisuje to w ten sposób: „Jeśli w środowisku istnieją odpowiednie prawidłowości, a osoba dokonująca osądu miała szansę je poznać, jej maszyneria skojarzeniowa rozpozna podobne sytuacje i wygeneruje szybką, trafną prognozę. Jeśli te warunki są spełnione, można ufać cudzej intuicji.” (Pułapki myślenia. O myśleniu szybkim i wolnym).Warto więc ufać osobom, które realizowały bardzo podobne projekty, w zbliżonym środowisku. Autor przywołuje również popularną regułę 10 000 godzin – jest to czas, jaki jest niezbędny, aby osiągnąć poziom pozwalający trafnie prognozować (około 6 lat pracy nad jednym tematem).
  • Nie szukaj idealnego rozwiązania – Tom Gilb, niekwestionowany autorytet i prekursor inżynierii oprogramowania, napisał kiedyś: „Accurate estimation is impossible for complex technical projects, but keeping to agreed budgets and deadlines is achievable by using feedback and change. In other words, rather than trying to improve the initial project estimates, the budgets and deadlines must be set based on the value of delivery (not the cost), and then iterative re-engineering of product and process must be used to stay within acceptable resource bounds.” (Estimation: A Paradigm Shift Toward Dynamic Design-to-Cost and Radical Management, SQP Journal March 2011)
  • Bądź elastyczny – czasami spotkasz się z przysłowiową ścianą. Nie da się przesunąć terminu, nie można zwiększyć budżetu. Co wtedy? Dostosuj swój plan i estymacje, ale komunikuj w precyzyjny sposób konsekwencje każdej zmiany, typu „skrócimy proces testowy o 10 dni kosztem niesprawdzenia części X i ograniczenia testów modułu Y do minimalnego zakresu”.

 

Jeżeli po przeczytaniu tego artykułu w dalszym ciągu nasuwają Ci się pytania związane z szacowaniem, napisz je w komentarzu lub skontaktuj się ze mną bezpośrednio. Chętnie przeanalizuję Twój problem i pomogę go rozwiązać.

Artur Guła
Doświadczony Analityk Biznesowy, Team Leader i bloger. Aktywnie udziela się w ramach śląskiego oddziału PMI. Interesuje się tematyką efektywnego planowania, zarządzania i realizacji projektów, nie tylko informatycznych. Przygodę z IT zaczął w 2008 roku, właśnie od testowania. Od tego czasu zbudował w kilku firmach efektywnie działające zespoły, zajmujące się testowaniem oprogramowania, utrzymaniem systemów informatycznych, wsparciem klienta oraz analizą wymagań. Często uczestniczy w konferencjach, seminariach i meetupach na terenie Śląska i nie tylko. Na swoim blogu: http://arturgula.aretech.pl/prezentuje zagadnienia związane z pracą zawodową oraz własnymi zainteresowaniami. Prywatnie, zainteresowany tematem rozwoju osobistego, od zawsze uwielbia czytać i podróżować a także uprawiać sport, ten fizyczny oraz umysłowy.

1
Dodaj komentarz

avatar
1 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
1 Comment authors
ThomasRecent comment authors
  Subscribe  
najnowszy najstarszy oceniany
Powiadom o
Thomas
Gość

Wyczerpujący artykuł , super !