Aktualnie przyjmuje się, że zespoły scrumowe powinny być samowystarczalne i zdolne do iteracyjnego dostarczania oprogramowania. W praktyce oznacza to, że zespół pracujący w tej metodologii odpowiada za dostarczony produkt od początku tj. od przyjęcia dokumentacji biznesowej i projektowania aż do wypuszczenia gotowego produktu do klienta. Oczywiście przy małych projektach może to być gotowy produkt, ale najczęściej są to modyfikacje lub poprawki do modułów większych aplikacji.

Zgodnie z powyższym, aby zespół mógł odpowiedzialnie wytwarzać oprogramowanie powinien być zróżnicowany tzn. posiadać wiedzę i umiejętności dotyczące różnych aspektów wytwarzania oprogramowania.

Najczęściej w skład takich zespołów wchodzą programiści i testerzy, ale zdarza się, że także product manager, analitycy czy specjaliści od UX. Należy pamiętać, że specyfika pracy takich zespołów może się różnić pomiędzy firmami, a często również w obrębie jednej organizacji.

Dla przykładu team, który pracuje nad dużym nowym projektem i składa się z 8-9 osób (np. 5 programistów i 3 testerów) ma inne zadania, potrzeby i cele niż mniejszy team 3-4 osobowy odpowiadający wyłącznie za poprawki wykrytych na produkcji błędów.

Do czynników różnicujących dochodzą także specyfika branży, dla której dostarczane jest oprogramowanie, stosowane technologie, zasoby czasowe firmy, sprzętowe i ludzkie.

Bardzo ważne dla powodzenia prac zespołu i dobrego efektu końcowego jest zaangażowanie i udział testerów w każdej z faz powstawania oprogramowania. Dlatego w tym poście chciałbym się pochylić nad tematem projektowania testów.

Wewnątrz zespołów scrumowych testerzy są odpowiedzialni za egzekwowanie i dbanie o jakość projektowanych i dostarczanych rozwiązań. Do ich zadań należy pilnowanie zgodności wytwarzanego oprogramowania z dokumentacją i co równie ważne – weryfikacja przydatności i użyteczności dostarczanego rozwiązania dla klienta.

Należy pamiętać, że oprogramowanie zgodne z dokumentacją, które nie spełnia zapotrzebowania klienta ostatecznie będzie dla niego nieużyteczne. Tester w fazie projektowania testów (co powinno odbywać się równolegle z projektowaniem funkcjonalności) powinien zadbać o sporządzenie przypadków testowych na podstawie dokumentacji, zebranych materiałów oraz własnego doświadczenia. Przypadki te powinny wychodzić poza ramy podstawowych ścieżek, którym docelowo będzie poddawana aplikacja i zawierać także te mniej oczywiste, ale mogące wywołać jej niepożądane działanie.

Przy projektowaniu testów dobrze jest stosować zarówno czarnoskrzynkowe jak i białoskrzynkowe metody projektowania przypadków testowych. W zależności od poziomu wiedzy technicznej testerów mogą oni projektować zarówno czarnoskrzynkowymi jak i białoskrzynkowymi metodami, jednak dość często za testy białoskrzynkowe odpowiadają programiści. Zdarza się też, że tester wspomaga programistę przy wymyślaniu przypadków testowych do testów białoskrzynkowych. Jest to zależne od ustaleń wewnątrz zespołu.

Najczęściej wykorzystywane metody projektowania testów czarnoskrzynkowych to:

  • podział na klasy równoważności
  • analiza wartości brzegowych
  • grafy przyczynowo skutkowe
  • zgadywanie błędów (bazowanie na wiedzy i doświadczeniu testerów)

Ponieważ w sieci nie brakuje opisów i przypadków stosowania powyższych metod, nie będą się na ich temat rozwodził.

Spisując przypadki testowe jednocześnie tworzona jest dokumentacja testów. Dzięki projektowaniu testów równolegle z pracami projektowymi funkcjonalności udaje się uniknąć wielu potencjalnych błędów i ograniczyć nadmiar pracy przy implementacji.

W teamach scrumowych kluczową rolę odgrywa komunikacja wewnątrz zespołu. Testerzy i programiści powinni wymieniać się wzajemnie informacjami na każdym z etapów tworzenia aplikacji, co pozwala jeszcze we wstępnej fazie wykluczyć niektóre potencjalne defekty. Ma to również korzystny wpływ na końcową formę specyfikacji technicznej i specyfikacji testów, bo jeszcze przed przystąpieniem do pisania kodu wyklucza z nich błędne rozwiązania i co najważniejsze w późniejszych fazach może się to przekładać na wyższą jakość produktu końcowego.

Projektowanie przypadków testowych daje testerom możliwość wyłonienia tych, które nadają się do automatyzacji. Najlepszymi kandydatami są tutaj przypadki często powtarzane i sprawdzające kluczowe miejsca w aplikacji. Jeżeli zespół nie zadba o zautomatyzowanie takich scenariuszy będzie musiał je sprawdzić ręcznie przed wgraniem kolejnej iteracji na produkcję (testy regresyjne). Im więcej zautomatyzowanych testów regresyjnych, tym więcej czasu zespół może poświecić na bardziej złożone przypadki, w których automaty nie są w stanie zastąpić doświadczonego testera.

Ważne jest również określenie, które z zaprojektowanych przypadków testowych przy dostępnych zasobach mogą być faktycznie wykonywane. Tutaj trzeba kierować się jedną z fundamentalnych zasad testowania: Testowanie gruntowne jest praktycznie niemożliwe lub możliwe, ale kompletnie nieopłacalne. Co za tym idzie testerzy powinni sporządzić optymalny zestaw testów dopasowany do mocy przerobowych zespołu. Wykonanie optymalnego zestawu przypadków zawsze daje lepsze efekty niż ich losowe wykonywanie.

W fazie projektowania testów zespół powinien określić również, jakiego środowiska testowego oraz danych testowych będzie potrzebował. Konieczne jest też sporządzenie listy dodatkowych narzędzi koniecznych do przeprowadzenia testów takich jak np.: narzędzia diagnostyczne, klient do testów web serwisów, debugery, dodatkowe urządzenia np. tablety, telefony itp.

Należy pamiętać, że nawet przy małych funkcjonalnościach warto poświecić czas na zaprojektowanie testów, bo poza tym, że daje to możliwość rzetelnego i optymalnego przetestowania dostarczanego rozwiązania, to pozwala już na wstępie wykryć błędne założenia projektowe, określić jakie dane, środowisko i narzędzia będą konieczne przy wykonywani testów. Pozwala to zaoszczędzić sporo czasu i zdecydowanie daje lepszy efekt końcowy niż losowe klikanie po gotowej aplikacji. Porządnie zaprojektowane przypadki testowe stanowią przydatną przy wykonywaniu retestów dokumentacji a także stanowią potwierdzenie sumiennie wykonanej przez testerów pracy.

Michał Zubik, tester oprogramowania