Skalowanie testowania - czas

[Wprowadzam w tym artykule duże uproszczenie związane z naszym teoretycznym wpływem na czas. Mam nadzieję, że czytelnicy mi to wybaczą. Przypominam, że nie wynaleziono jeszcze metody wpływania na bieg czasu.]

Nawet najbardziej skomplikowana i sformalizowana metoda pracy czy proces w pewnym momencie musi zostać zredukowany do minimum z powodu skrócenia czasu projektowego. Uproszczenie metody opisaliśmy w poprzednim wpisie. Może się jednak zdarzyć, że w metodzie nie ma już z czego rezygnować i pozostaje nam zejść na niższy poziom operacyjny i zarządzać pojedynczymi zadaniami. Możemy "zdobywać czas" przez redukowanie zadań i możemy je również redukować w czasie przygotowania i wykonania. Takie działania zazwyczaj nie są zaplanowane przy doborze strategii testowej czy też w planie testów. Realizowane są zazwyczaj w chaotycznej metodzie "gaszenia pożaru", czyli próby szybkiej reakcji na nieprzewidziane albo pominięte w analizie ryzyka. Wiele projektów boryka się z tzw. "end game", czyli końcowej rozgrywki i walki o dostarczenie produktu na rynek. W zależności od profesjonalizmu organizacji i panujących w niej warunków może dochodzić w organizacji do "spychologii stosowanej", czyli "to nie ja, winni są wszyscy inni" lub "ty zawaliłeś, więc to napraw". Bardziej otwarte organizacje będą wspólnym wysiłkiem próbować dostarczyć produkt zamiast przerzucać się odpowiedzialnościami. Pojawia się tu również klasyk testerski czyli "kiedy wydłuża się czas na kodowanie skraca się czas testowania" Jest to niestety częsty przypadek i wielu testerów się z nim boryka. Jak nigdzie indziej kwestia przeskalowania zadań w czasie staje się tu kluczowa. Nasze planowanie nie ma żadnego znaczenia bo wszystko, co sobie założyliśmy musi być zmodyfikowane w zmieniającym się otoczeniu. Trzeba podkreślić, że takie działanie jest oznaką bardzo słabego zarządzania projektami i brakiem szacunku do samego testowania. Jest to ewidentny pstryczek w nos liderów testów, których głos jest absolutnie pomijany, albo nadpisywany.

Zamiast jednak użalania się można próbować zarzadząć zadaniami i czasem w następujących obszarach:

1. Redukcja zadań. Jakie zadanie testowania możemy zredukować i jakie jest ryzyko, że je skrócimy lub całkowicie wyrzucimy z naszego harmonogramu? Może to rodzić dodatkowe pytania. Czy to zadanie rzeczywiście było takie ważne, że możemy je zredukować? Kiedy i w jaki pojawi się efekt zredukowania ważnego zadania? Kiedy "odzyskamy" te zadania i czy przesunięcie ich na przyszłość jest możliwe? Każda odpowiedź powinna nam pomóc określić jak bardzo stracimy na świadomości jakości poprzez modyfikacje pierwotnych planów i czy będzie szansa na podniesienie świadomości w przyszłości.

2. Ustalenie priorytetów. Najwyższe priorytety to zazwyczaj najważniejsze funkcjonalności lub cechy oprogramowania i przypisane do nich zadania testowe.  Priorytety rzadko kiedy będą sterowane przez długość i czas wykonania danego zadania. Może się jednak okazać, że zamiast testować najważniejsze funkcje dla 100 wzorcowych użytkowników możemy to zrobić dla połowy. Długość trwania zadania pewnie nie skróci się o połowę, ale na pewno zostanie zredukowane w czasie. Podobna sytuacja może mieć miejsce również dla liczby uruchomień zadań, testów konfiguracji i środowisk, liczby pokrytych klas równoważności i wartości granicznych itd. Zadania z najmniejszym priorytetem przestają mieścić się w czasie i po prostu z zakresu wypadają.
Należy jednak bronić się przed precedensem jaki taka zmiana wprowadza. Nie możemy zaakceptować twierdzeń liderów, którzy mówią, że poprzednio udało się coś zrobić w 3 dni znaczy, że w kolejnej iteracji znów możemy poświęcić temu tylko 3 dni. Oprócz czasu na przeprowadzenie testów należy uwzględnić również ryzyka jakie wiążą się ze skróceniem czasu kontroli jakości.

3. Nadgodziny. Choć nie jest to skalowanie czasu, a próba zwiększenia ilości czasu możemy próbować tą metodę stosować. Mając na testy 3 dni po 8 godzin, możemy przez wydłużenia czasu pracy o 2 godziny uzyskać więcej czasu na zadania testowe. Pamiętajmy, że takie podejście nie może być stosowane regularnie, gdyż szybko prowadzi do znużenia, zmęczenia i wypalenia projektowego. Pomijam jednocześnie sytuacje patologiczne i zakładam, że każda (nad)godzina musi być albo wypłacona, albo odebrana.

4. Kupowanie godzin poza grupą testową. W czasie testów nie wszyscy muszą być równomiernie obciążeni zadaniami. Może się więc zdarzyć, że do samego testowania można włączyć innych członków zespołu projektowego. Część z nich będzie bronić się przed tym rękami i nogami, ale jak uczą najlepsi eksperci jakości, zaangażowanie programistów czy analityków w testy jest z korzyścią zarówno dla jakości jak i dla tych osób. Dzięki temu uzyskujemy dodatkowe godziny pracy, które w większości przypadków nie będą warte tyle ile praca profesjonalnego testera. Jest to jednak kolejne ryzyko związane z brakiem czasu na  przeprowadzenie testów przez samych testerów.

To tylko niektóre, najbardziej ogólne reguły skalowania czasu, czy dokładnie ujmując jego pozyskiwania. Szerzej temat można opisać już w stosunku do konkretnego kontekstu projektowego, gdzie mamy konkretne zadania i konkretne role. Spróbujcie zastanowić jak Wasza specyfika projektowa pozwala Wam na skalowanie / pozyskiwanie czasu.