Tam gdzie w organizacji wykonuje się testy – zanim system albo zmiana znajdzie się w produkcyjnym użytkowaniu – w którymś momencie osoby najbardziej zaangażowane w czynności testowania dochodzą do wniosku że np. ilość danych towarzyszących testom jest coraz większa, coraz trudniej się je zbiera i nimi zarządza. Ponadto osoby na co dzień pracujące w komórkach biznesowych, które także angażujemy w testy – będą ponosić coraz bardziej dotkliwe konsekwencje przeciążenia pracą, bo prawdopodobnie najbardziej ucierpią na tym czynności obsługi realnego biznesu, czekające na swoją kolej. Dzięki nim przecież firma istnieje i generuje zyski.
Spróbujmy nazwać kilka takich trudności albo sformułować problemy w poczuciu, że podejmowany wysiłek aktualnie jest kierowany nie tam gdzie być powinien, bo na przykład:
- praca którą wykonujemy jest niepotrzebnie powielana (bo nie wiemy czym już dysponujemy, np.: w wielu miejscach w firmie powstają scenariusze, ktoś spędza mnóstwo czasu na ich przygotowanie, a potem nie wiadomo gdzie one się znajdują, na ile są aktualizowane i mogą być wykorzystane w kolejnych iteracjach testów, itp.);
- spędzamy cenne godziny po to aby menedżerowie otrzymali dzienne raporty z testów;
- testerzy intensywnie korespondują z programistami dostawców w temacie zgłoszeń znalezionych nieprawidłowości i uzupełniają zgłoszenia w systemie dostawcy zamiast w naszym systemie tylko po to aby mogły być one przyjęte do realizacji;
- przy kolejnych iteracjach testów poświęcamy czas i pieniądze (angażując do tego np. dodatkowe osoby), aby żmudnie wykonać gorzej lub lepiej zdefiniowany zakres testów regresyjnych, itp.
Te i inne trudności, jeśli powracają – mogą znaleźć swoje rozwiązanie, jeśli rozsądnie podejdziemy do wykonania analizy tego czego tak naprawdę potrzebujemy i jakie problemy poprzez zmiany zostałyby rozwiązane.
Przygotowanie i wykonanie testów jest niczym innym jak tylko jednym z procesów biznesowych istniejących w organizacji, które można odwzorować jako:
- strumień przebiegu kolejnych czynności,
- przypisanie do realizujących je osób (aktorów),
- możliwych alternatywnych ścieżek,
- potrzeb podejmowania decyzji,
- wąskich gardeł,
- ścieżek procesów, które nie wiadomo jak i gdzie się kończą, itp.
Opowiadając albo odwzorowując graficznie to jak wygląda testowanie w naszej firmie, w jakiej ilości i przez kogo realizowane są czynności i co tak naprawdę się dzieje, bez kolorowania rzeczywistości – zobaczymy te wszystkie elementy, które mają znaczenie albo ułatwiają lub utrudniają przebieg procesu. Włączając w te rozważania osoby, z którymi podczas przygotowania oraz testowania się kontaktujemy, dostaniemy dodatkowo cenny wkład do naszej „chwili prawdy” i dzięki temu bardziej kompleksowy będzie nasz proces projektowanej zmiany.
Zanim zdecydujemy się na np. jedno z supernowoczesnych, modnych i wiele mogących narzędzi zaprezentowanych przez elokwentnego handlowca albo napiszemy kolejną martwą instrukcję postępowania, warto rozważyć realizację zmiany poprzez klasyczne podejście projektowe z:
- zebraniem listy potrzeb,
- zdefiniowaniem listy problemów, z którymi regularnie musimy się mierzyć we wszystkich miejscach w organizacji,
- odnalezieniem jak najpełniejszej grupy osób, które w jakikolwiek sposób uczestniczą albo korzystają z efektów pracy albo informacji związanych z testami – i danie im możliwości przygotowania się oraz przedstawienia wypowiedzi o problemach, ale też zebrania informacji o tym co już wg nich działa dobrze.
W dalszej kolejności na podstawie np. zamodelowanego procesu lub/i listy zebranych wśród interesariuszy problemów i pomysłów, warto uporządkować je wg ważności i znaczenia a także tego na ile przedstawione pomysły zmian będą odpowiedzią na problemy, które mamy. Bo czy np. dedykowane raporty z określoną zawartością generowane na potrzeby 3 osób rozwiążą jakiś problem, bo może to co muszą zawierać w efekcie poszukiwania rozwiązania ograniczy wachlarz rozważanych narzędzi do zarządzania testami?
Co może być wynikiem takiej analizy? Czasem zakup narzędzia, czasem zmiana organizacji pracy w konkretnym obszarze, zmiana komunikacji wewnątrz firmy, może budowa repozytorium, uporządkowanie zarządzania środowiskami testowymi albo zmiana zapisów umów z dostawcami oprogramowania.
Jeśli organizacja znajdzie podstawy do tego że warto podejść do wytwarzania oprogramowania po nowemu, dzięki czemu uda się też zatrzymać pracowników posiadających unikalne kompetencje kluczowe dla firmy – czasem wynikiem zmiany będzie przejście na metodyki zwinne.
Warto przy dochodzeniu do formułowania wniosków z analizy wziąć pod uwagę kwestie natury strategicznej organizacji, czyli np.:
- możliwą konieczność dostosowania się do innego procesu testowego, w wyniku np.: przyszłej fuzji (w wyniku której będziemy się dostosowywać do innej ścieżki testowania albo metodyki);
- perspektywę zmiany strategii firmy (np. zwolnienia grupowe, w wyniku których odejdą ludzie z wiedzą biznesową, z którymi aktualnie współpracujemy i których np. moglibyśmy przejąć);
- czas w roku kiedy planujemy budżet na kolejny rok, w którym można przewidzieć inwestycję związaną z ew. zakupem narzędzia do testów (jeśli w analizie wyjdzie nam, że rozwiązaniem problemów będzie zakup narzędzia), żeby nie czekać do kolejnego roku budżetowego, co opóźni wprowadzanie zmian;
- zebranie informacji czy obowiązują nas albo obowiązywać będą przepisy regulujące obszar naszej działalności i mają one wpływ na sposób, w jaki powinny być wykonywane i akceptowane testy?
Jednym ze sposobów przejścia przez zmianę procesu testowego może być zaangażowanie osób z zewnątrz, które zajmą się analizą stanu obecnego, niejednokrotnie żmudnym zebraniem informacji oraz przedstawieniem możliwych sposobów rozwiązań problemów albo referencyjnych przypadków z branży. Zbierając doświadczenia z udziału w projektach rozwoju oprogramowania oraz uczestnicząc w autorskich projektach optymalizujących procesy związane z wytwarzaniem oprogramowania specjaliści z firmy ForProgress posiadają wiedzę i kompetencje przeprowadzenia organizacji przez taką zmianę. Zapraszamy do rozmowy i do współpracy.