Redakcja
Tych z Was, którzy przegapili nasze wprowadzenie do skalowania testowania zapraszamy do lektury prologu >>
Analizę skalowania oprzemy o proces testowy znany z ISTQB. Dlaczego? Ponieważ jest to najbardziej sformalizowany i rozbudowany proces testowy. Można go więc łatwo redukować i dopasowywać do swoich potrzeb.
Pierwszym etapem redukcji procesu będzie to, co niestety nie występuje w naturalnym środowisku IT, czyli... specyfikacja. Brak specyfikacji zmusza nas do usunięcia "analizy" rozumianej jako testowanie statyczne specyfikacji połączone z przygotowaniem założeń do testów. Te czynności, które służą do definiowania funkcji podlegających weryfikacji przesuniemy do planowania (gdzie i tak w praktyce się to wykonuje). Z drugiej strony mamy "czynności zamykające testy", których w normalnym projekcie nikt nie realizuje z powodu braku czasu, wypalenia projektem lub brakiem wiedzy o wartości retrospektywy. Mało kto rozumie również różnicę między projektowaniem i implementacją testów. W związku z tym w procesie pozostanie jedynie "projektowanie", które jest wymyśleniem testu i opisaniem go specyfikacją.
Pewną specyfiką skalowanego testowania będzie redukcja ról. W standardzie jest to lider i testerzy. W małych projektach zostanie to ograniczone do pojedynczego testera oprogramowania bez lidera / kierownika / managera. Innym rozwiązaniem jest planowanie, które realizowane jest bez konsultacji z testerem / testerami (lub też z ich ograniczonym wpływem). Czynności zarządcze stają się więc zbędne, ponieważ tester nie będzie kontrolował samego siebie. Kontrola menedżerska w takim przypadkach sprowadza się do przyjęcia raportu z testów. Pozostanie nam proste monitorowanie jakości. Z drugiej strony zredukowane planowanie nie uwzględni końca testowania jako kryterium jakości. Zadowolimy się więc wypuszczeniem oprogramowania, kiedy będzie "wystarczająco dobre".
Ostatnim etapem redukowania procesu testowego będzie zejście do testowania eksploracyjnego, gdzie pozostają tylko te czynności, które są wymaganym przez projekt informatyczny minimum. Usuwamy projektowanie umieszczając je w planowaniu, gdzie specyfikacja weryfikacji funkcji zamknie się na poziomie opisu samej funkcji.
Część z tych czynności nie będzie miała prostego (zadaniowego) mapowania na rozbudowany proces, ale będzie miała znacznie większą skuteczność w osiąganiu celu. Ma również ograniczenia związane z ilością specyfikacji, a co za tym idzie ze zubożeniem komunikacji, ograniczoną kontrolą czy trudniejszym transferem wiedzy.
Pozostaje pytanie o to, czy istnieje dalsza redukcja. Dalej mamy już tylko testowanie ad-hocowe, bez przygotowania, z mało efektywnym raportowaniem i nieskutecznością w ocenie jakości.
Czy rozbudowany proces będzie domeną dużych organizacji pracujących zgodnie z modelami kaskadowymi (w tym z modelem V)? Niekoniecznie. Czynności rozbudowanego procesu można zmapować również na zwinne projekty. Można zrobić to w bardzo prosty sposób, przesuwając podstawowe czynności planowania i retrospektywy poza iteracje, a monitorowanie i kontrolę przerzucając nie na managera, a na zespół. Duże organizacje mogę używać również metody przeskalowanej do minimum, korzystając z doświadczenia pracowników i zbudowanego w organizacji zaufania co do sumienności wykonywanej pracy.
W kolejnej części zapraszam na skalowanie czasu w testowaniu.
Radek Smilgin
