Z niewiadomych powodów utarło się, że testowanie w trakcie tworzenia oprogramowania nie jest istotnym elementem projektu. Niestety, takie podejście może narazić firmę na dużo większe koszty niż pierwotnie zakładano. Dlaczego? Ponieważ jest to swego rodzaju bomba z opóźnionym zapłonem. Okazuje się, że na samym końcu oprogramowanie zawiera takie błędy, których naprawa wydłuża cały proces wydania produktu – jakim jest oczywiście wcześniej wspomniane oprogramowanie.
Takie podejście do projektu jest bardzo kosztowne nie tylko dla firmy, która zleca wykonanie produktu, ale również dla samych developerów, testerów i menagerów. Wiąże się to z dłuższą pracą developera, dłuższym testowaniem i większą ilością spotkań prowadzonych przez menagera. Zatem doprowadzamy do sytuacji, kiedy sami sobie stwarzamy dużo więcej kosztów – a miało być przecież odwrotnie.
Weźmy na przykład projekt dostarczany inkrementalnie. Klient dostaje aktualizacje oprogramowania, która zawiera kolejne funkcjonalności. W TT PSC coraz więcej projektów prowadzonych jest w metodologii Agile, co wymusza uzupełnianie procesów o pisanie testów automatycznych i zredukowanie czasu potrzebnego na testy. Dlatego zakładamy, że:
- dostarczona nowa funkcjonalność powinna działać bez problemów zgodnie ze specyfikacją dostarczoną przez klienta.
- dostarczone nowe funkcjonalności nie powinny wprowadzić regresji w już istniejących funkcjonalnościach.
Dwa krytyczne punkty, w obu przypadkach rola testera jest bardzo ważna.
Przede wszystkim należy podkreślić fakt, że aby oszczędzić należy liczyć się z kosztami testowania. Firmy, które oszczędzały na testowaniu wydały później znacznie więcej środków finansowych na poprawienie błędów oraz zniwelowanie opóźnienia wydania produktu. Dlatego śmiem twierdzić, że pieniądze zainwestowane w testera – zwracają się.
Płynność projektu, bieżące wyłapywanie błędów. Tak naprawdę tester powinien być zaangażowany w projekt od samego jego początku. Często w takiej sytuacji pada jedno pytanie „Co on ma teraz robić? Szkoda pieniędzy! Przecież nic nie zostało jeszcze napisane, więc nie ma czego testować”. Nic bardziej mylnego! Rolą testera nie jest realizacja testów wyłącznie w momencie działania systemu. Jego zadaniem jest zrozumienie projektu, produktu, zapotrzebowania klienta – dzięki temu jest w stanie zrozumieć, jak powinny działać poszczególne funkcjonalności; jakie zadania, polecenia ma wykonywać system. Dlatego tester powinien brać czynny udział już na etapie tworzenia oprogramowania. Powinien uczestniczyć w spotkaniach projektowych z developerami i liderami technicznymi. Dzięki takiej wiedzy znacznie łatwiej jest później doszukiwać się błędów i mieć stu procentową pewność, że coś tym błędem naprawdę jest.
Jeśli chcemy skrócić czas, który potrzebny jest na przygotowanie testów, warto aby tester zacząć pisać testy równolegle w stosunku do tworzenia oprogramowania. Oczywiście nie jest to proste zadanie! Napisanie testów bazujących tylko na dostarczonej dokumentacji wymaga sporego doświadczenia. Zdarza się, że otrzymana przez testera dokumentacja nie jest wystarczająca do stworzenia dobrych testów. W takim przypadku tester musi wykazać się także zdolnościami komunikacyjnymi z developerami, menagerem projektu czy klientem zamawiającym produkt.
Ważnym jest również, aby być przygotowanym do wykonania testów zaraz po implementacji funkcjonalności. Rolą testera jest zwrócenie uwagi na to, czy w oprogramowaniu nie ma logicznych błędów, funkcji, które wzajemnie by się wykluczały.
Prawdą jest, że im wcześniej zostaną wykryte takie sytuacje, tym mniej czasu spędzimy na wykonywanie poprawek. Dużo więcej czasu i pracy wymagają gotowe systemy, których poziom złożoności jest znacznie trudniejszy w naprawie, a tym samym także kosztowniejszy – ale o tym już wspominałem na początku tego artykułu.
Zatem, podstawą w utrzymaniu budżetu jest nie tylko dobre planowanie, ale również zrozumienie problemu, komunikacja pomiędzy wszystkimi stronami biorącymi czynny udział w projekcie, tj. developerami, testerami, dokumentalistami, menadżerem oraz scrum masterami.