Estymacja czasu pracy testera

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 nieznają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. Zatem 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 dwutygodniową 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 do 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 scenariusz 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żnie estymujemy czas w Godzinach lub „Man day”. Natomiast w planning 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.

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ł, dlaczego tak, a nie inaczej.

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

Ja w 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.