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 email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *