Można żartobliwie powiedzieć, że największym wrogiem programisty jest użytkownik jego oprogramowania. Na etapie rozwoju aplikacji jeszcze groźniejszym przeciwnikiem może być jednak tester. Prezentacje przedstawione 12 września w ramach XXXI spotkania The Software House z cyklu „Uszanowanko Programowanko” poświęcone były głównie temu, jak skutecznie wyszukiwać błędy w oprogramowaniu i prowadzić testy eksploracyjne i akceptacyjne. I choć zgodnie z hasłem przewodnim spotkania tester może być widziany jako „koszmar dewelopera”, ostatecznie współpracuje z programistami i wspomaga ich w doskonaleniu programu.
Pierwszy wystąpił Jacek Bugajny. Jego prezentacja zatytułowana „Pięć twarzy kryptografii” stanowiła szybkie, zgrubne, lecz mimo to dość konkretne wprowadzenie w zagadnienia związane z szyfrowaniem danych. Prelegent wyjaśnił czym są kryptologia, kryptografia oraz kryptoanaliza i przedstawił podstawowe definicje związane z tymi dziedzinami wiedzy. W ramach wprowadzenia przedstawione zostały przykłady szyfrów przestawieniowych i podstawieniowych, w tym ROT13 oraz Cezara. Następnie prelegent płynnie wprowadził uczestników w problem uzgadniania kluczy w niezaufanym środowisku oraz jego rozwiązanie, jakim jest protokół Diffiego-Hellmana, w praktyce używany w algorytmie RSA.
Następnie prelegent opisał funkcje skrótu takie jak MD5 i SHA-1. Do tego fragmentu można było mieć pewne zastrzeżenia, gdyż zastosowanie funkcji skrótu nie zostało dobrze wyjaśnione, a z prezentacji można było wręcz odnieść mylne wrażenie, że stanowią one kolejną formę szyfrowania danych.
Na koniec jako praktyczne, codzienne zastosowanie przedstawionych rozwiązań i technik został wymieniony protokół SSL (nota bene zastąpiony już dawno przez TLS).
Druga prezentacja, zatytułowana „Testy eksploracyjne: lucky shot czy zaplanowana akcja?”, została przedstawiona przez Adama Nowrota. Testy eksploracyjne to technika testowania polegająca na badaniu funkcjonalności „w ciemno”, z minimalną znajomością działania funkcji oraz szczątkową dostępną dokumentacją. Powinien prowadzić je doświadczony tester, charakteryzujący się dużą intuicją oraz wnikliwością, znający domenę biznesową testowanej funkcjonalności.
Jednym z warunków, by sesja testów eksploracyjnych była udana, jest ustalenie skończonego budżetu czasu oraz dobre przygotowanie się do testów. Można przyjąć, że 20% założonego czasu powinno być poświęcone na przygotowanie do testów, 60% na same testy, a pozostałe 20% — na opracowanie raportu. W ramach przygotowania tester komunikuje się z architektami i programistami, wyszukuje i gromadzi dokumentację oraz określa zakres testowania, który powinien obejmować funkcje najbardziej istotne z punktu widzenia biznesowego.
Istotne jest, by tester nie wpadł w utarte ścieżki i nie testował detali aplikacji, nie dotykając krytycznych wątków logiki biznesowej. Można to osiągnąć na przykład zlecając testy eksploracyjne nowym testerom, którzy nie zajmowali się jeszcze daną funkcjonalnością i nie ulegną pokusie sprawdzania ciągle tych samych operacji.
Wynikiem sesji testów eksploracyjnych powinien być raport zawierający informacje o zakresie czasowym sesji, testowanym obszarze aplikacji i znalezionych defektach (wraz z dokładnym opisem sposobu powtórzenia, o ile to możliwe). W przypadku znalezienia łatwo powtarzalnych błędów warto zaproponować w raporcie nowe scenariusze testowe do uwzględnienia w ramach testów automatycznych. Jeżeli tester nie ma jasności co do sposobu działania niektórych funkcji, w raporcie można też umieścić pytania do kierownika zespołu.
Testy eksploracyjne najlepiej przeprowadzi „świeży umysł”, nie zatruty jeszcze pracą z danym modułem aplikacji. Doświadczony tester dużo szybciej i lepiej przygotuje się jednak do sesji testów niż ktoś, kto dopiero rozpoczyna pracę testera. Dobre przygotowanie się do sesji pozwoli też uniknąć powtórnego wejścia na utarte ścieżki w przypadku testerów mających wcześniej kontakt z tą lub podobną aplikacją. Mimo to, osoby świeżo wchodzące do nowego projektu (blisko końca sprintu, etapu lub całego projektu) mogą zyskać dzięki „szczęściu początkującego”, sprawdzając sekwencje poleceń które zaznajomiona z programem osoba od razu odrzuciłaby jako absurdalne.
Pozytywnym skutkiem prowadzenia testów eksploracyjnych jest lepsze poznanie aplikacji oraz jej zachowania w różnych sytuacjach. W efekcie przeprowadzonych testów tworzone są nowe scenariusze testowe oraz znajdowane miejsca warte poddaniu testom automatycznym. Do wad można zaliczyć z kolei trudność w odtworzeniu niektórych ścieżek prowadzących do błędów oraz brak informacji o stopniu pokrycia funkcjonalności testami. Tester może bowiem nie wiedzieć, które miejsca są szczególnie wrażliwe na powstawanie błędów lub istotne z punktu widzenia klienta. Dlatego właśnie tak istotne jest przygotowanie się do testów, by zacząć je nie od detali, lecz funkcji najbardziej interesujących klienta.
Ostatnia prezentacja, zatytułowana „Testy akceptacyjne: formalność czy droga przez mękę?” i przedstawiona przez Joannę Zembaczyńską, miała na celu przedstawienie środków prowadzących do tego, by testy akceptacyjne faktycznie stały się formalnością zwieńczającą projekt, a nie powodem zjawiska noszącego nazwę crunch, stanowiącego postrach zespołów programistycznych. Testy akceptacyjne przeprowadza się na etapie odbioru produktu by klient miał pewność, że otrzymywany program spełnia jego oczekiwania. Realizuje się je na serwerze produkcyjnym lub zbliżonym do produkcyjnego, by jak najbliżej odzwierciedlić środowisko, w którym ma później działać program.
Poziom istotności usterek znajdowanych na etapie testów akceptacyjnych może stanowić kość niezgody pomiędzy programistami a klientem. Usterki w stylu błędów literowych, możliwe do usunięcia w ciągu kilku minut, dla klienta mogą stanowić błąd krytyczny, decydujący o odrzuceniu produktu i skierowaniu go do poprawki. Dlatego testy akceptacyjne muszą być dostosowane do wymagań biznesowych klienta, a warunki akceptacji dokładnie określone przez samego klienta w formie zadań wpisanych do systemu typu Jira, arkusza kalkulacyjnego lub przynajmniej podpisanej i opieczętowanej kartki. Istotne jest, by kryteria były zatwierdzone, bezdyskusyjne i nie podlegały ani zawężaniu przez wykonawcę, ani rozszerzaniu przez zamawiającego. Musimy też zwracać uwagę na elementy niefunkcjonalne, często niewpisane bezpośrednio do wymagań, takie jak łatwość obsługi funkcjonalności lub logiczne działanie narzędzi.
Dla projektu najlepiej jest, by testy akceptacyjne prowadził wewnętrzny zespół testerów. Tester powinien brać udział w pracach już na etapie ustalania wymagań, komunikując się z klientem i nawiązując z nim relację pozwalającą dobrze poznać cele biznesowe projektu oraz wyeliminować nieufność i agresję, które mogą wystąpić na etapie odbioru. Pamiętanie o testach akceptacyjnych od samego początku projektu pozwoli stworzyć bazę wiedzy dla scenariuszy testowych, przygotować testy automatyczne oraz wyeliminować część błędów na długo przed odbiorem. W efekcie znacząco skraca się czas testowania na końcu projektu.
Istnieje wiele sposobów, by mimo wszystko testy akceptacyjne zmienić w drogę przez mękę. Pierwszym błędem jest brak jasnych zasad współpracy z klientem. Jeżeli klient nie ustali listy osób odpowiedzialnych za zgłaszanie usterek, zasypią nas różnej jakości, powielające się zgłoszenia pochodzące od wszystkich pracowników biorących udział we wdrożeniu. Utrudni to odtwarzanie problemów oraz zwiększy koszty obsługi komunikacji z klientem. Z kolei jeżeli po stronie wykonawcy nie będzie osoby (lub osób) zajmujących się obsługą zgłoszeń, niektóre zgłoszenia mogą pozostać bez obsługi lub bez właściwej weryfikacji ich zrealizowania.
Kolejnym błędem jest brak weryfikowania spełnienia kryteriów akceptacji po każdym etapie rozwoju produktu (lub każdym sprincie w przypadku stosowania metodologii scrum). Sprawdzanie kryteriów akceptacji dopiero na etapie odbioru opóźnia wykrycie błędów i powoduje, że na tak istotnym etapie zaawansowania projektu następuje znaczące przesunięcie daty gotowości do odbioru.
Trzecia kategoria problemów wynika paradoksalnie z dużej dbałości, z jaką klient chce podejść do testów akceptacyjnych. Do testowania może zostać oddelegowana bardzo liczna grupa pracowników zainteresowanych nowym produktem, z których część może nie mieć czasu, chęci lub predyspozycji do testowania. W efekcie niektóre błędy mogą zostać niewykryte. Z kolei niektórzy „testerzy z przypadku” mogą zbyt gorliwie wypełniać nowy obowiązek i zgłaszać jako błąd każdą najdrobniejszą znalezioną niedogodność. Przy tak dużej liczbie testerów może też dojść do sytuacji, w której poprawka błędu zostaje zgłoszona jako nowa usterka, gdyż dwie różne grupy pracowników mają odmienne poglądy na sposób, w jaki powinna działać pewna funkcjonalność.
Z powyższym problemem łączy się zjawisko „defektu fałszywie pozytywnego”, zgłaszanego przez klienta, jednak tak naprawdę nie stanowiącego usterki w rozumieniu kryteriów akceptacji. Czasem bowiem kryteria akceptacji albo są zapisane niepoprawnie, albo są różnie rozumiane przez różne grupy testerów, albo wręcz nie są znane niektórym pracownikom klienta. W tym ostatnim przypadku błędy mogą pozostawać w konflikcie z kryteriami akceptacji, gdyż zgłoszenia powstają na podstawie oczekiwań testerów, a nie porównania działania programu z zapisami umownymi.
Klienta należy dyscyplinować nie tylko w zakresie liczby i jakości testerów oraz sposobu, w jaki interpretują oni kryteria akceptacji. Częstym zjawiskiem jest też przemycanie przez klienta rozszerzeń funkcjonalności jako błędów w działaniu produktu. Zdarza się też, że klient na późnych etapach projektu wręcz zmienia kryteria akceptacji na podstawie dotychczasowych doświadczeń z testowymi wersjami produktu. Można to przyjąć, jeżeli zmiany uściślają lub upraszczają pewne kwestie, lecz należy przeciwstawić się zmianom które mogą spowodować zwiększenie zakresu potrzebnych prac lub całkowitą przebudowę już stworzonych części produktu.
Nie jest też dobrym pomysłem wydzielanie czasu (lub odrębnego sprintu) na wyszukiwanie i usuwanie usterek. Powoduje to, że zespół nie przykłada wagi do testowania produktu oraz usuwania znanych błędów, czekając na wydzielony etap projektu mający na celu poprawę jakości. Nawarstwienie się wielu usterek może spowodować, że etap ten znacząco się przedłuży, niwecząc wysiłki związane z przewidywaniem czasu realizacji i terminu odbioru.
Jako kwestie najważniejsze dla pomyślnego przetrwania testów akceptacyjnych prelegentka wskazała jasne ustalenie i wiążące zatwierdzenie kryteriów akceptacji produktu, zbudowanie możliwie zwartych i dobrze współpracujących zespołów testowych po obydwu stronach, klarowne i czytelne zapisywanie zadań do zrealizowania przez programistów, a przede wszystkim dobre, odpowiedzialne i wszechstronne testowanie produktu przez testerów.
Jak zwykle po spotkaniu z serii „Uszanowanko Programowanko” po ostatniej prezentacji uczestnicy mieli czas na wspólne rozmowy, w tym na zadawanie pytań prelegentom. Wszyscy zostali też poczęstowani pizzą oraz napojami. Poziom organizacyjny i merytoryczny były jak zwykle bardzo wysokie. Poruszane były kwestie istotne dla programistów, testerów oraz kadry zarządzającej i choć na pewno tematy te nie zostały wyczerpane, to przedstawione informacje stanowią podstawę dla dalszych poszukiwań lub szkoleń.
Programowanie