Radek Smilgin
Mniej często znaczy więcej. Jest to uniwersalna zasada, która dotyczy wielu aspektów życia. Przykładowo, im więcej opcji wyboru mamy, tym ciężej jest nam podjąć decyzję. Często mówi się również "remove to improve" - poprawianie przez redukowanie. Sprawdza się to również w testowaniu.
Zawsze byłem zwolennikiem upraszczania i dostarczania wartości bez względu na to, jakim budżetem i jakimi zasobami dysponujemy. Z drugiej strony negowałem zbytnie komplikowanie rzeczy, które z zasady, niekoniecznie testerskiej, powinny być upraszczane. Dzięki prostej (lub uproszczonej) regule, że mniej testowania znaczy lepsze testowanie, w projektach testerskich jestem w stanie dostarczać wartość, zamiast utrudniać życie testerom i członkom zespołu projektowego.
Im większy zespół testowy, tym trudniejszy w zarządzaniu
Reguła małych zespołów wynikająca z lepszego zarządzania nimi jest stosowania w całej branży i daleko poza nią. Większej efektywności nie osiąga się poprzez ciągłe dorzucanie zasobów, a poprzez optymalne nimi zarządzanie. Chcesz mieć większy i skuteczny zespół, to z jednej strony upraszczasz reguły jego działania (o tym poniżej), albo/i dajesz mu większą autonomię. Duże zespoły nie będą się w stanie same zorganizować (jeśli wybierasz zwinność) i będą tak samo trudne w kontrolowaniu (jeśli idziesz ścieżką klasycznego zarządzania).
Czym bardziej skomplikowany proces testowania, tym więcej prób jego (p)ominięcia
Procesy i procedury mogą być ułatwieniem jeśli jest ich ani nie za dużo, ani nie za mało. Optimum jest trudne do zdefiniowania oraz silnie zależy od kontekstu, ale może być osiągnięte przez iteracyjne podejście do tworzenia reguł pracy. W testowaniu reguła jest dość prosta, definiujesz minimalny zbiór zadań do wykonania oraz produktów do dostarczenia i sprawdzasz, czy jest wystarczający do zmierzenia jakości produktu. Jeśli TAK — udało się osiągnąć optimum, jeśli NIE — musisz dodać kolejne elementy do układanki.
Złożony proces będzie wymagał większej ilości ludzi do wykonania jego wytycznych.
Im bardziej złożona dokumentacja testerska, tym mniejsza szansa, że ktoś ją przeczyta
Zapewne widziałeś, a może nawet tworzyłeś plany testów czy strategie tak rozbudowane, że męczące w pierwszym kontakcie z nimi. Jeśli autor ma poczucie zmęczenia swoją pracą, to co ma powiedzieć jego odbiorca? Zapewne zareaguje odrzuceniem. W dokumentach powinniśmy zawrzeć maksimum przydatnych informacji i minimum bezwartościowej treści, czyli informacje adekwatne do kontekstu, a nie przydatne w całej organizacji. Zwiększone audytorium dla dokumentacji to również większa świadomość tego, co w testowaniu się robi, a taki jest cel tworzenia dokumentów. Możemy to porównać do poczytnych autorów łatwej literatury zestawionych z klasykami posługującymi się hiperbolami i przesadnymi opisami. Ci pierwsi trafią do głów czytelników, ci ostatni wylądują na półce.
Czym więcej skryptów testowych, tym droższe ich utrzymanie
Automatyzowanie wszystkiego to jedna z większych patologii projektowych. Z jednej strony nie jest tanie, a z drugiej nie jest efektywne. Jest więc zaprzeczeniem tego, co chcemy osiągnąć. By zapewnić sobie skuteczną kontrolę jakości, musimy zbudować zbiór testowy dopasowany do budżetu i kontekstu projektowego. Nigdy nie będzie to pokrycie wszystkiego. Pamiętajmy, że im więcej wydamy na automatyzację, tym więcej wydamy na jej utrzymanie, a to niekoniecznie musi się przekładać na wyższą jakość.
Im bardziej skomplikowany raport, tym trudniej zrozumieć jego treść
W ostatnim etapie naszej pracy również musimy myśleć nad optimum i to bez względu na to, czy mówimy o raporcie defektu, czy raporcie z testów. Proste reguły tworzenia raportu nastawianego na czytelnika mogą pomóc nam osiągnąć nasze cele. Raport powinien być zwięzły i treściwy. Jeśli już chcemy go pompować, to przynajmniej postarajmy się, by najważniejsze informacje znajdowały się na jego początku. No i nie zapominajmy o formie. Im atrakcyjniejsza forma (np. kolorowa), tym szybciej dotrze do głowy czytającego.
Testowanie jest po części zasygnalizowaniem problemu, a po części dostarczeniem dla niego rozwiązania. Każdy członek zespołu jest lepiej postrzegany, jeśli raportując problem przyniesie ze sobą również propozycję rozwiązania.
Pamiętaj jednak, że złożonych problemów nie rozwiążesz poprzez ich dalsze komplikowanie. Jeśli już masz skomplikowaną sytuację projektową, to zamiast ślepo podążać za regułami, spróbuj uprościć to co istnieje.
