piątek, 14 czerwca 2013

Test czy nie test case

Od wielu lat mam szczęście pracować ze stałym zespołem ekspertów zajmujących się testowaniem oprogramowania. Oczywiście ludzie w zespole zmieniają się, jednak wiedza i doświadczenie powinny pozostać. Ta właśnie "krzywa uczenia się" jest największą korzyścią z utrzymywania takiego zespołu. Oczywiście obok wielu innych czynników, jak "kuźnia talentów" dla innych działów, elastyczność w realizacji zadań z różnych dziedzin, obsługa zdarzeń ad-hoc, itd.

Obecność stałego zespołu ekspertów pracujących dla klienta wewnętrznego, eliminuje w dużej części konieczność dokumentowania przypadków testowych. Zaznaczam, że przez przypadek testowy rozumiem pełną gębą procedurę ściśle opisującą co i jak (pisałem o tym  między innymi tutaj lub tutaj).

Nie ma sensu przeznaczania cennego czasu inżyniera na opisywanie tego co będzie robił. Lepiej jest zachęcić go do zrobienia tego co zrobić ma. Z moich obserwacji wynika, że i tak większość testerów robi notatki i zapiski oraz stara się strukturalizować swoją pracę. Jedynie szczypiorniści w tym zawodzie mają tendencję do rzucania się na głęboką wodę. Ale i tutaj zespół przychodzi z pomocą i szybko wydobywa topielca z topieli problemu wskazując mu sposób na rozwiązanie problemu.

Bardzo pomocne przy tym trybie pracy są wszelkie listy kontrolne i heurystyki wspierające inżyniera w jego pracy. Dobrze jest aby takie narzędzia systematyzować i katalogować wewnątrz zespołu.

Problem szacowania, planowania i raportowania przeniosłem na poziom wymagań. Umożliwia mi to proces wytwarzania funkcjonujący w mojej firmie. Plan testów i raport z testów jest jedynym obowiązkowym dokumentem pracy testera/grupy testerów. Pozostałe elementy są opcjonalne.

Nie ma więc w tutaj przypadków testowych co nie znaczy, że jest bałagan. Formalizujemy te obszary, które podlegają częstej regresji. Te które jest sens automatyzujemy. Jednak w głównej mierze polegamy na znajomości środowiska, doświadczeniu i z własnych potrzeb wytworzonym na własny użytek narzędziach.

W zamian otrzymujemy elastyczność, niski nakład prac administracyjnych, jasny i prosty proces oraz - liczę na to - poczucie odpowiedzialności i autonomii.

Zilustruję to przykładem z niedalekiej przeszłości, kiedy w trybie awarii pojawiła się konieczność sprawdzenia sporego kawałka oprogramowania. Testy szacowaliśmy na dwa tygodnie dla 1 osoby. Harmonogram innych projektów nie pozwalał na zrobienie tego w wymaganym czasie. Podjęliśmy decyzję, że przez 1 dzień (8 godzin) cały zespół (8 osób) wykonana możliwe do wykonania testy. Proces rozdzielania pracy był bardzo krótki i polegał na "poborze ochotniczym". Jedna osoba zajęła się koordynowaniem prac aby się nie dublować.

Efekt był taki, że po przekazaniu na produkcję, awaria został zażegnana a inne defekty nie pojawiły się na w ten sposób przetestowanym releasie.

Brak komentarzy: