Z tego artykułu dowiesz się, jakie aktywności uwzględniać w wycenie pracy. Poznasz także kilka cennych wskazówek, o których warto pamiętać przekazując informację o estymacji innym osobom.

Z wyceną naszej pracy spotykamy się na różnych etapach życia projektu. Zaczyna się zwykle od pierwszej estymacji w czasie tworzenia oferty (proposal). Następnie przeliczamy wszystko jeszcze raz po wygraniu projektu, kiedy znamy więcej szczegółów, a jeszcze później wyceniamy poszczególne user stories podczas sesji planingowych.

Sama estymacja, w zależności od etapu czy specyfiki pracy w projekcie lub organizacji, może być przygotowywana w różnych jednostkach: story pointach, godzinach, MD czy w pieniądzach.

Ale co uwzględniać?

Wszystko! Wycena samych testów funkcjonalnych to za mało.

• Dokumentacja – należy dodać czas na przygotowanie dokumentacji (test case, test plan, test report). Ilość potrzebnej dokumentacji będzie zależne od sposobu naszej pracy oraz wymagań klienta. Piszę o tym w innym poście.
• Dane testowe – nie należy zapominać o przygotowaniu danych testowych. W przypadku niektórych funkcjonalności może to być bardzo czasochłonne.
• Testy niefunkcjonalne – warto pomyśleć, które z testów performance, security, accessibility, disaster recovery, itp. mogą być potrzebne w danym projekcie.
• Testy automatyczne – jeśli zakładacie testy automatyczne w projekcie, to potrzebny będzie też czas na wybranie odpowiedniego narzędzia, konfigurację frameworka oraz CI. To wszystko trzeba dodatkowo uwzględnić poza samym czasem pisania testów oraz ich utrzymania. Oczywiście do tego będzie potrzebne przyjęcie strategii samej automatyzacji. Potrzebujecie określić, które z testów (unit test, integration test, end to end) będą pokryte przez testerów, a które przez developerów.
• Test Management – w niektórych projektach będzie to kluczowe. Komunikacja z klientem lub też innymi dostawcami ma często bardzo duży wpływ na projekt dlatego warto pamiętać, by uwzględnić ten czas w estymacji.
• Inne fazy testów – oczywiście musimy jeszcze dodać czas na ewentualne systemowe testy integracyjne, testy UAT, itp.
• Cross-browser testing – w przypadku aplikacji webowych należy też pamiętać o wykonaniu testów pod różnymi przeglądarkami, zwłaszcza w przypadku kiedy aplikacja jest otwarta na świat. Czasami będzie tak, że klient określi na jakich przeglądarkach i ich wersjach aplikacja ma działać. Czasami jednak tej informacji może nie dostarczyć. Wtedy warto sprawdzić informację o udziale w rynku poszczególnych przeglądarek w kraju gdzie dana aplikacja będzie używana.
• Testy na urządzeniach mobilnych – podobnie jak z przeglądarkami, jeśli mamy do czynienia z aplikacją webową, to o ile nie ma dedykowanej aplikacji natywnej, warto też stronę sprawdzić na różnych urządzeniach mobilnych, pod różnymi systemami i ich wersjami. W tym przypadku znowu przydadzą się informację o udziale w rynku poszczególnych wersji Androida i iOS. Kluczowa może też być rozdzielczość ekranu.
• Inne czynności specyficzne dla danego projektu np. testy migracji danych

Czy to wszystko?

Poza elementami wymienionymi powyżej warto wypracować sobie pewne podejście do samego estymowania. W przypadku grubszych tematów lepiej sprawdzić może się przedział np. 20-25 dni zamiast jednej wartości. Czasami stosuje się też poziom niepewności dla poszczególnych wycenianych elementów. Do tego należy dodać informację o przyjętych założenia oraz ryzykach.

Przygotowanie estymacji to bardzo ważny element pracy testera. Warto się w nią zaangażować, by mieć wpływ na ilość czasu przeznaczonego na testy. Jest sporo rzeczy, o których trzeba pamiętać, by wszystko uwzględnić, a pominięcie jakiegoś elementu może mieć negatywne konsekwencje. W tym celu można przygotować sobie check listę, z której można skorzystać w czasie przygotowywania estymacji.

Dobrym zwyczajem jest też estymowanie niezależnych rzeczy osobno i podawać tą informację jawnie np. testy automatyczne, performance, dokumentacja itp. W takim przypadku dajemy klientowi możliwość zrezygnowania z dowolnej aktywności jeśli będzie chciał obniżyć koszty. Dzięki takiej transparentności łatwiejsze powinno być podjęcie decyzji co obciąć i jednocześnie lepiej będzie widać czego nie dostarczymy. Może też pomóc uzasadnić podawane liczby jeśli będziemy w stanie wytłumaczyć co się pod nimi kryje.

*obrazek zaczerpnięty z internetu, autor nieznany