Kto nie idzie do przodu, ten się cofa – czyli jak podejść do zmian w procesie testowym

Kto nie idzie do przodu, ten się cofa – czyli jak podejść do zmian w procesie testowym

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.

Anna Chacińska

Opublikuj w:
Anna Chacińska

Od dziesięciu lat pracuję jako koordynator projektów testowych o różnym stopniu złożoności i dla wielu branż. Udało mi się zebrać doświadczenie zarówno w firmach sektora telekomunikacyjnego, instytucjach finansowych oraz sektorze publicznym, pracując zarówno w metodykach klasycznych jak i zwinnych, w środowisku polskim oraz międzynarodowym. Zdobytą wiedzę praktyczną potwierdziłam certyfikatem ISTQB Test Manager. W kolejnych projektach w szczególności cenię sobie możliwość zdobycia nowej wiedzy, nie tylko branżowej, oraz pracę w Zespołach, w których budowaniu uczestniczę. Prywatnie chętnie podróżuję na dwóch kółkach, zgłębiam tajniki świata roślin oraz metod diagnozy talentów.

Zostaw komentarz!

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *