Estymacja czasu pracy testera
Estymacja czasu pracy - blog wyszkolewas.com.pl

W tym wpisie postaram się wyjaśnić na czym polega estymacja czasu pracy. Odpowiem na pytanie dlaczego bardzo ważne jest uczciwe podejście do tego tematu. Jak ma się wycena w kontekście projektów małych i dużych oraz czy ma jakieś znaczenie poziom zaawansowania prac nad projektem?

Czym jest estymacja czasu pracy i dlaczego pracodawca / klient wymaga od nas estymacji naszych zadań?

Estymacja czasu pracy polega na określeniu czasu potrzebnego na wykonanie zadań w projekcie. Czyli mówiąc krótko i na przykładzie:

Kierownik pyta – “Ile czasu potrzebujesz by przetestować logowanie?”

Ty odpowiadasz : “Trzy godziny”.

Dzięki dobrej estymacji czasu pracy jesteśmy w stanie konkretnie wskazać ile czasu poświęcimy na zadania. A to umożliwia określenie ilości zadań, które będziemy w stanie zrealizować w ramach, np. miesiąca. 

Co należy brać pod uwagę podczas estymacji czasu pracy?

Istnieje wiele czynników, które jako tester powinieneś uwzględnić podczas estymacji swojego czasu pracy. Należą do nich między innymi wymienione poniżej.

  • Skład zespołu pracujący nad zadaniem.
  • Wielkość zadań.
  • Stabilność kodu/środowiska.
  • Dokumentacja testowa + planowanie testów + czas na raportowanie błędów oraz Retesty
  • Współpraca z innymi zespołami
  • Twoja wiedza o produkcie , który będzie testowany.
  • Czas jaki pozostał do oddania projektu.
  • Wieloprojektowość.

Skład zespołu pracujący nad zadaniem

Załóżmy, że pracujesz w zespole złożonym z doświadczonych i pracujących w projekcie od jakiegoś czasu osób. Wówczas nakład pracy potrzebnej do wykonania zadania będzie mniejszy niż w przypadku zespołu, w którym jest kilka osób z krótkim stażem pracy w projekcie. Wynika to z tego, że osoby nie znające produktu będą potrzebować czas na wdrożenie się w niego. Dlatego estymując czas testów funkcjonalności weź pod uwagę kto będzie poprawiał błędy, które zgłosisz.

Wielkość zadania, którego wykonanie masz oszacować

Duże zmiany w aplikacji to też odpowiednio długi czas poświęcony na ich wdrożenie. To też zwykle duża ilość dokumentacji do przeczytania oraz do napisania. Testowanie większej funkcjonalności wiąże się z tym, że testujemy ją w mniejszych “paczkach”. W związku z tym, programista stale ingeruje w kod testowanego komponentu dodając nowe funkcjonalności (“paczki”). Co za tym idzie nawet przetestowany wcześniej obszar może się zepsuć. A to z kolei powoduje, że pod koniec developmentu powinniśmy przeprowadzić dodatkowe Smoke testy. Tak więc estymując czas testów dużej funkcjonalności powinieneś wziąć pod uwagę testy “paczek” i całej funkcjonalności. 
Małe zadania mają to do siebie, że łatwo je oszacować ze względu na ich wielkość i przeważnie małe skomplikowanie. Nie chodzi mi o skomplikowanie w kodzie bo nawet najmniejsze zmiany mogą skutkować testami Regresji. Ale o to, że najczęściej otrzymujemy małą ilość “paczek” do testów. Mamy też dużo mniej dokumentacji do przetworzenia by przetestować funkcjonalność.

Stabilność kodu/środowiska.

Im większa stabilność kodu, tym mniejsza szansa na dużą ilość błędów w modułach, które już rozwijaliśmy od jakiegoś czasu. Łatwiej jest też wprowadzać kolejne moduły do aplikacji zbudowanej na „dobrym” kodzie. To samo tyczy się środowiska, na którym mamy postawioną aplikację. Im jest ono bardziej zadbane tym mniej czasu stracimy by dało się aplikację testować.

Dokumentacja testowa + planowanie testów + czas na raportowanie błędów oraz Retesty

Bardzo ważną rzeczą podczas szacowania jest pamiętanie o tym, że estymacja czasu pracy na zadanie to nie same testy. Pamiętaj, że poza nimi powinieneś wycenić również czas potrzebny na wykonanie dodatkowych prac. Należą do nich zawsze planowanie, pisanie dokumentacji testowej, zgłoszenie różnic pomiędzy specyfikacją a aplikacją oraz retestowanie defektów.

Współpraca z innymi zespołami

Bardzo często nowo tworzona funkcjonalność ma zintegrować się za pomocą usług z innymi systemami. Systemy te niekoniecznie muszą być tworzone przez firmę, w której pracujemy. To stwarza dodatkowe ryzyko w kontekście estymacji czasu pracy. W takich sytuacjach nie zależy od nas to ile potrwa wyjaśnianie problemów czy naprawa błędów po stronie dostawcy usługi.

Twoja wiedza o produkcie , który będzie testowany

Estymacja powinna być wykonywana przez osobę, która realnie będzie wykonywała testy. Przykładowo, jeżeli trafimy do nowego projektu i z marszu będziemy mieli zacząć testować nowe funkcjonalności, to należy doliczyć konieczność głębszego wejścia w dokumentację analityczną – chyba, że założyliśmy testy za pomocą technik opartych na doświadczeniu.

Czas jaki pozostał do oddania produktu

Czas jest kolejnym niedocenianym czynnikiem w procesie estymacji. Bardzo często projekty sterowane są datą wdrożenia oprogramowania na produkcję. Niestety w takich projektach zdarza się, że w związku z ilością zadań do projektu są dorzucane nowe osoby, które mają pomóc szybciej wykonać zadanie. I teraz zależy kiedy są one przyjmowane. Jeśli jest to na początku projektu, wtedy estymując czas pracy powinieneś dodać godziny potrzebne tym osobom na wdrożenie. Czas ten zostanie jednak zrekompensowany tym że te osoby odpowiednio długo będą później pracować w projekcie. Ale jeśli nowe osoby są dodawane do projektu tuż przed wdrożeniem, to często czas potrzebny na ich wdrożenie i pomoc udzielaną przez doświadczonych pracowników powoduje, że prace nad projektem zwalniają zamiast przyspieszać.

Praca w wielu projektach

Pracując w kilku projektach podczas estymacji weź pod uwagę, czas potrzebny na przełączenie się między zadaniami/projektami. Przykładowo mając dwu tygodniową przerwę w pracy w projekcie, może być konieczne przeczytanie dokumentacji.

Estymacja czasu pracy powinna być zawsze uczciwa

Przy okazji estymacji czasu pracy musimy dbać o to, żeby była ona zawsze uczciwa. Głównym tego powodem jest zaufanie jakie budujemy sobie poprzez sumienną i szczerą estymację. Daje ona klientowi jasny przekaz, że „jesteśmy w stanie oddać x zadań o standardach jakościowych, które wcześniej ustaliliśmy”. Dodatkowo nam samym daje ona możliwość lepszego poukładania zadań z perspektywy najbliższych tygodni.

Jaki projekt jest łatwiej wyestymować Nowy czy taki, który jest realizowany od jakiegoś czasu?

Moim zdaniem dużo łatwiej jest wyestymować czas pracy dla produktu, który jest już na rynku. Głównym powodem, tego jest możliwość porównywania czasów jakie szacowałem na przestrzeni ostatnich x miesięcy dla tego produktu.
Zaletą nowo robionego projektu, może być za to świeży start, który nie jest możliwy przy projekcie trwającym już kilka miesięcy. Dodatkowo w przypadku trwającego projektu przeważnie jesteśmy proszeni o estymację funkcjonalności aplikacji. Natomiast dla nowo powstającej aplikacji będzie to określenie czasochłonności stworzenia nowego systemu.

Sztuka wyciągania wniosków

Nasze wyceny nie zawsze będą perfekcyjne, natomiast powinniśmy dążyć do tego aby były one jak najbliżej ideału. Biorąc wymienione w tym artykule czynniki, możemy się domyślić, że proces wytwarzania oprogramowania nie jest rzeczą prostą tylko składa się na niego wiele czynników, niektórych oczywistych i jasnych a innych ukrytych i straszących nas w najmniej spodziewanym momencie. Dlatego też uważam, że należy zbierać sobie dane z wycen i próbować przeanalizować ich wyniki. Dla mnie osobiście dobrą estymatą jest próg błędu rzędu +/- pół dnia pracy na zadaniu, które ma trwać przez 3 tygodnie (chodzi o testy). Jeżeli udaje mi się uzyskać tego typu wyniki to zapisuję sobie składowe oraz czynniki poboczne jakie wpłynęły na moją wycenę.

Techniki estymacji czasu pracy
  • Estymacja na podstawie danych historycznych.
  • Estymacja czasu pracy „botton-up”.
  • Ocena ekspercka.
  • Trzystopniowa estymacja.
  • Planning poker.
Estymacja na podstawie danych historycznych

Dosyć prosty sposób estymacji, ponieważ w ramach tej techniki porównujemy projekty, które wcześniej estymowaliśmy a są identyczne jak projekt, który mamy dostarczyć. Uwaga w ramach tej techniki istnieje ryzyko odnośnie pomyłki co do podobieństwa aplikacji uruchomionej przez nas wcześniej a aplikacji dopiero przez nas tworzonej. Skutkujące złym oszacowanie czasu potrzebnego na wykonanie testów.

Estymacja czasu pracy „botton-up”

Cechuje ją bardzo duża dokładność jeżeli chodzi o wyniki, natomiast minusem tej techniki jest konieczność poświęcenie dużej ilości czasu żeby ją wykonać. Dodatkowo warto wiedzieć, że ta technika nie zawsze będzie dla nas dostępnym narzędziem, np. w wypadku braku dokumentacji analitycznej nie będziemy w stanie wykonać tego typu estymacji.

Ocena ekspercka

Technika oparta na doświadczeniu osoby, która wycenia czas potrzebny do wykonania zadania.

Trzystopniowa estymacja

Ta technika polega na stworzeniu trzech scenariuszy. Pierwszy hurraoptymistyczny, w którym wszystko idzie jak po maśle bez żadnych problemów. Drugi scenariusz pesymistyczny bierzemy tutaj pod uwagę możliwości wystąpienia nawet plag egipskich na naszej aplikacji :). 
Trzeci sceneriusz to scenariusz realistyczny, w którym staramy się zdroworozsądkowo znaleźć złoty środek pomiędzy hurraoptymistycznym oraz pesymistycznym. Po stworzeniu wszystkich trzech scenariuszy próbujemy wyciągnąć z nich średnią, która później staje się naszą finalną wyceną.

Planning poker
Jest to technika typowa dla projektów Scrumowych. Różni się ona znacząco od pozostałych wymienionych, ponieważ przy poprzednich technikach przeważne estymujemy czas w Godzinach lub “Man day”. Natomiast w planing pokerze estymujemy za pomocą Story Pointów. Story Point jest jednostką złożoności lub ryzyka historyjki. W przeciwieństwie do poprzednich technik tutaj każde zadanie jest estymowane przez cały zespół. Skutkuje to tym, że tester bierze czynny udział w estymacji czasu programisty jak i programista estymuje czas jaki będzie potrzebny na testy. Wygląda to tak, że każdy członek zespołu szacuje czas wykonania każdego zadania.
Typowa skala wartości jakie podczas głosowania można podać to: 1/2, 0, 1, 2, 3, 5, 8, 13, 21 .

W tej skali wartości minimalne typu 1 lub 2 to zadania banalne do wykonania, z którymi bez problemu sobie poradzimy jako zespół. Wartość 21 jest specyficzna oznacza ona, że nie jesteśmy w stanie wykonać zadanie w ramach jednego cyklu, więc trzeba je rozbić na mniejsze zadania, a następnie ponownie dokonać estymacji.

Przykładowo

Mamy zespół składający się z ośmiu osób. Podczas estymacji czasu wykonania zadania podały one następujące wartości: 

Pięć osób zagłosowało za wartością 5, dwie osoby zagłosowały za wartością 2, natomiast jedna za 21. 

W takim wypadku osoby, które dały skrajne wartości tłumaczą się dlaczego dokonaly takiej estymacji, a następnie estymujemy ponownie.. aż otrzymamy podobne wyniki w skali zespołu.

Plusem tej techniki jest aktywność całego zespołu przy estymacji.

Co w przypadku testera może pomóc w łatwiejszym zrozumieniu aplikacji, złożoności zadania oraz potencjalnych ryzyk wynikających z przeprowadzania testów danej funkcjonalności. Minusem jest tak zwana bezpieczna piątka, jest to efekt konieczności tłumaczenia się z rozbieżności w wycenie pomiędzy osobami (skrajne wartości, o których wcześniej wspomniałem). Dlatego część osób, może wychodzić z założenia, że lepiej dać jakąś bezpieczną wartość, żeby nikt się nas nie pytał dalczego tak a nie inaczej.

Co zrobić jeśli podana przez Ciebie estymacja czasu pracy nie została zaakceptowana?

Ja takim przypadku siadam ponownie nad danymi, które zebrałem w celu estymacji i analizuje je. Robię to w celu wyeliminowania lub zmniejszenia nakładu czasu dla zadań o niskim priorytecie. Następnie przedstawiam propozycję estymacji czasu wraz z informacją co zostało zmienione w stosunku do poprzedniej.

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Ten post ma 4 komentarzy

  1. Wszystko zależy z jakiej perspektywy patrzymy przeważnie za tymi liczbami, które wpisujemy stoją pieniądze naszej firmy/klienta.
    Porównałbym to do oddania samochodu mechanikowi. Dostajesz konkretne dane co do czasu i pieniędzy jakie będziesz musiał wydać żeby naprawiono Twój samochód. Jako klient możesz być nieusatysfakcjonowany tym co mechanik Ci powie i masz prawo do negocjacji.
    W sumie również bardzo dobrą rzecz napisałeś “świadoma akceptacja tego, że dany feature będzie przetestowany w “gorszy” sposob?” Dokładnie tak czasami trzeba zaakceptować sytuację, w której nie uzyskamy pełni obrazu. Musimy pamiętać o tym, że testowanie tak naprawdę mierzy nam jakość oprogramowania a nie zwiększa jej jakość (chyba, że mamy super programistów, którzy wszystko poprawiają)

  2. Cześć, bardzo ciekawy artykuł. Mam pytanie do ostatniego punktu czyli ponownej estymacji.

    Piszesz, że w przypadku takiej prośby eliminujesz zadania o niższym priorytecie lub zmniejszach dla nich naklad czasu. O ile eliminacja jest całkiem zrozumiała i oczywista to czy coś zmienia się w wymaganiach tych zadań, że początkowa estymacja jest inna niż zmodyfikowana? Nie do końca rozumiem dlaczego na przykład według pierwszej estymacji coś wymaga 4h czasu pracy, a potem bez zmiany wymagań zadanie będzie wymagało tylko 2h.

    1. Cześć,
      nic nie zmienia się w wymaganiach takich zadań, jedyne co się zmienia to czas jaki dostaliśmy na przetestowanie danego zadania. Jeżeli wcześniej dokonałeś estymacji i mówiła ona, że zadanie zostanie w pełni przetestowane w np. 4 godziny, a następnie okaże się, że masz budżet 3 godziny to musisz tak zmodyfikować swoje plany aby się wyrobić w trzech godzinach jednocześnie mając na uwadze jak najlepszą jakość aplikacji.

      1. Tylko czy to nie jest błędne założenie? Rozumiem, że jak mus to mus, ale dlaczego ktoś postronny (chodzi mi o osobę, która nie testuje) narzuca Ci estymatę. Czy to nie jest świadoma akceptacja tego, że dany feature będzie przetestowany w “gorszy” sposob?

Dodaj komentarz