Redakcja
Podczas studiów często mamy do czynienia z osobami nie mającymi żadnego praktycznego doświadczenia w testowaniu i których dopiero mamy wszystkiego nauczyć. Osobiście na swoich zajęciach próbuję pokazać im szeroką perspektywę testowania, nieograniczoną tylko wykonaniem testów. Wspólnie próbujemy zrozumieć współczesny świat IT, modele wytwórcze i wpasowanie do tego testowania. Można pokazać teoretyczny model wytwarzania oprogramowania, ale można również pokazać jego zastosowanie.
Dla mnie ważną umiejętnością każdego testera jest zrozumienie kontekstu, w jakim pracuje. Przedstawiając procesy testowania zawsze podkreślam, że są one bardzo podobne, a główne różnice są w szczegółach, takich jak techniki czy kolejność wykonania operacji. Często takie same działania po prostu nazywają się inaczej, a podobne produkty mają zupełnie niepodobne nazwy. Procesy są jednak niczym bez wpasowania ich w modele wytwarzania oprogramowania. Na moich zajęciach każdy student musi zrozumieć, że dobre testowanie jest nierozerwalnie związane z dopasowaniem do modelu wytwórczego. Jednym z kluczowych i bardzo trudnych zadań jest zastosowanie teorii procesów testowych w realnym modelu. Moje podejście do edukacji w tym obszarze ewoluowało przez dotychczasowe zajęcia i wydaje mi się, że osiągnęło finalną formę podczas ostatnich zajęć na Uniwersytecie Jagiellońskim. Po krótkim wprowadzeniu teoretycznym poprosiłem studentów o dopasowanie testowania do wybranego modelu wytwórczego. Większość wybrała DevOps.
Wizualizacja DevOps z Wikipedii
Co ważne nie opowiadam czym jest DevOps, nie mówię o teorii modelu wytwarzania, bo specyfika danej organizacji i projektu w większości przypadków modyfikuje model wytwórczy do potrzeb konkretnego produktu. Nie ma więc sensu opowiadać o teorii, a jedynie skoncentrować się na odnalezieniu w tej prostej wizualizacji modelu czynności testowania. Nie odbieram studentom prawa do posługiwania się Internetem i poszukiwania źródeł. Jeśli nie wiedzą, czym są poszczególne działania i zadają pytania, co dzieje się w konkretnych fazach, chętnie udzielam odpowiedzi. Nie oczekuję, że proces testowy, jaki wysnują z modelu będzie doskonale poprawny. Bazują na szczątkowych informacjach i mają prawo popełniać błędy. Kolejna iteracja analizy modelu da im więcej informacji i dokładniejszy (zgodny z teorią) proces. Poniżej prezentuję wynik około 30-minutowej, samodzielnej pracy, której celem było wpisanie w DevOps testowania. Na model zostały naniesione czynności i produkty testowania.
PLAN
Czynności:
- testowanie wymagań
- wstępne przygotowanie przypadków testowych
- tworzenie/konsultacja wymagań do testów
Produkt:
- zgłoszenia poprawek do wymagań
- wymagania do testów
- Definition of done
CREATE
Czynności:
- przygotowanie przypadków, środowisk oraz danych testowych
- unit testy
- automatyczne testy regresyjne
Produkt:
- plan testów
- procedury testowe
- przypadki i dane testowe
VERIFY (na środowisku testowym)
Czynności:
- wykonanie testów w oparciu o przygotowane przypadki
- testy akceptacyjne
- testy regresyjne (automatyczne/manualne)
Produkt:
- zgłoszenia bugów
- raport z testów
PACKAGE (pre-prod)
Czynności:
- testy regresyjne automatyczne
Produkt:
- raport
RELEASE (produkcja; możliwy rollback do poprzedniej wersji)
Czynności:
- testy poinstalacyjne
MONITOR (produkcja; możliwy rollback do poprzedniej wersji)
Czynności:
- testy hot fixów
- pen testy
- testy wydajnościowe
Produkt:
- raport
Wejście w kolejny etap planowania powinno być poprzedzone retrospekcją poprzednich działań i wyciągnięciem z nich wniosków co do usprawnień i praktyk, które chcemy wdrożyć przed kolejną iteracją/sprintem.
Z olbrzymią satysfakcją czytam wynik tej pracy, ponieważ mam wewnętrzne przekonanie, że udało mi się tych studentów czegoś nauczyć, a może po prostu odkryć potencjał, który posiadali. W wynikach widać duże zrozumienie dla procesu testowego oraz umiejętne przeniesienie go na SDLC. Edukacja studencka w tym wypadku jest jak zapisywanie białej karty. Ludzie z praktycznie zerowym doświadczeniem wykonują zadania, które my - doświadczeni testerzy - wykonujemy (lub powinniśmy wykonywać) przy każdym kolejnym projekcie. Mam przekonanie, że tak nabyte umiejętności pozostaną na długo w ich głowach i przełożą się na lepsze świadczenie usługi testowania w projektach.
Radek Smilgin
