Po SC Wro#6 – Visual Testing – kiedy warto?

SC Wro

W ubiegły czwartek odbyła się kolejna edycja meetupa Software Craftmanship events – SC Wro#6 poświęcona tym razem tematyce testów. Zostałem zaszczycony zaproszoniem do udziału w panelu dyskusyjnym za co dziękuję organizatorom 😉

Warto o tym wspomnieć, że panele dyskusyjne są stałym elementem na spotkaniach SC Wro i cieszą się powodzeniem. Sam mogłem się przekonać, że są ciekawą formą dyskusji która wyzwala dodatkową energię.

Visual testing

Opisy prezentacji znajdziecie na stronie wydarzenia. Obie były nagrywane wraz z panelem, więc jeżeli kogoś interesują szczegóły na pewno zajrzy na profil organizatora.Pomimo że obie prezentacje mówiły o automatyzacji wizualnej regresji to dotykały tematu w innym kontekście i inny sposób.

Ok, ale może od początku.

Czym są testy wizualne?

W tak szeroką nazwę wpada moim zdaniem wiele rodzajów testów. Prosta odpowiedź: są to testy interfejsu użytkownika. Trochę szersza odpowiedź: testy tego, czy interfejs wygląda poprawnie dla użytkowników. W tym momencie problem staje się złożony i pojawiają się pytania. Dla jakich użytkowników? Każdy przecież jest inny, ma inną percepcję tego co widzi, będzie inaczej używał naszej usługi, jeden woli klawiaturę, drugi myszkę, jeden lubi czekać, drugi nie, trzeci ma problem ze wzrokiem i potrzebuje większej czcionki, starszą osobę będą drażnić kolory tęczy a młodą ekskluzywne szarości, czwarty mieszka w Chinach, a piąty w strefie czasowej +3,30 UTC… itd. itp.
W zasadzie, jeżeli budujemy jakiś serwis publiczny to powinniśmy te aspekty uwzględniać prawda? Cóż … raczej uważałbym temat skazany na porażkę, aby zadowolić wszystkich 😉 Nie mniej, są obszary i zasady którym warto się przyjrzeć i przynajmniej wiedzieć których użytkowników zaspokoimy.

Z obszarów które według mnie wchodzą w worek „testów wizualnych” różniłbym kilka:

• Testy “dostępności” –  czyli testy które sprawdzają zgodność z ciągle rozwijającym się Web Content Accessibility Guidelines (WCAG). W przeszłości moim zdaniem kojarzone głównie z dostępnością do usług strony przez osoby niepełnosprawne, a dzisiaj szeroko definiując temat również z poziomu użyteczności a nawet i bezpieczeństwa. Temat bardzo szeroki i nadający się na osobnego posta. Jednak zachęcam do spojrzenia do kilku ciekawych porad, aby uświadomić sobie jak złożony jest to temat lub jak bardzo spełniamy/nie spełniamy kryteria np. Error prevention. Między czasie, jeżeli kogoś temat nagli, krótki artykuł opisujący kilka narzędzi wspomagających development oraz testy dostępności
• testy responsywności – innymi słowy – czy nasza strona wygląda tak samo na różnych urządzeniach i rozdzielczościach? czy elementy się skalują? czy pożądana funkcjonalność na danym urządzeniu jest dostępna?
• testy użyteczności z użytkownikami – poznanie swojego użytkownika i zobaczenia na żywo jak korzysta z aplikacji jest z reguły drogą do sukcesu. Nie znam się na metodach przeprowadzania takich testów, ale brałem niedawno udział jako beta użytkownik i było to bardzo ciekawe przeżycie. Musiałem mówić co czuję i nad czym się zastanawiam. Byłem obserwowany! Mogłem być szczery i bez ogródek dzielić się spostrzeżeniami i trudami użytkowania! 😉 Jestem pewny, że dzięki takim testom start up poświęci jeszcze trochę czasu, aby przygotować „zjadalną” wersję swojego pomysłu 😉
• testy A/B? – w wąskim zakresie, ale mimo wszystko powiedziałbym, że wpadają w ten worek. Jeżeli chcemy sprawdzić, czy danym użytkownikom podoba się A czy B to uznałbym to za „test wizualny”, jednak trzeba pamiętać, że testy A/B mają szerszy zakres
• testy lokalizacji (i18n, l10n) – i znowu, w jakimś zakresie może się zdarzyć, że zawartość naszej strony będzie inaczej wyświetlana w zależności od strefy czasowej, języka, praw obowiązujących w danym kraju itd.
• RODO? – sami pewnie zauważyliście, że stosowane są różnego rodzaju triki abyśmy nie tak łatwo zrezygnowali z akcpetacji udostępniania naszych danych … w każdym razie, mam tu na myśli wszelakie informacje prawne narzucone z góry. Prawo też jest różne w różnych krajach więc dochodzi globalizacja.
• Trzymanie się zaleceń grafików –  jeżeli mamy klienta lub sztab grafików którzy po prostu wiedzą jak ma wyglądać interfejs (albo budujemy coś dla znanej marki gdzie szata graficzna jest z góry znana i narzucona, są standardy), wyznaczyli nam reguły, zestawy kolorów szaty graficzne to musimy w jakiś sposób zweryfikować czy przestrzegane są te zasady w całej aplikacji np. czy na wszystkich stronach przycisk OK jest po prawej stronie, ma wielkość 50 × 80 i kolor niebieski
• … (miejsce na Twój komentarz ;))

Wizualne testy regresji

Zakładając, że nasz software jest rozwijany według powyżej wybranych kryteriów, ustaliliśmy sobie użytkowników i zawartość wyświetlaną w zależności od pory dnia, pogody itp. Kolejnym krokiem jest to, że chcielibyśmy zapewnić w procesie developmentu, że będziemy trzymali się tych zasad. Zostało ustalone co to znaczy “jakość” interfejsu dla naszych użytkowników.

Teraz chciałbym odwołać się do prezentacji, bo wprowadzają kontekst.

Pierwsza z nich prezentowana przez Łukasza mówiła w skrócie o tym w jaki sposób wybrali narzędzie Applitools (pomimo, że padł pomysł, aby napisać swoje, jednak taniej i szybciej jest wziąć coś gotowego) do wykrywaniu regresji w CMSie. Klient sam postawił wymaganie, aby testować interfejs użytkownika ponieważ irytowały go błędy na tym poziomie.

Updated: po napisaniu tego posta pojawił się pełniejszy artykuł który podesłał mi Łukasz.

Z kolei na drugiej prezentacji Mateusz mówił o tworzonym frameworku który mocno opierał się na operacjach wykonywanych na interfejsie użytkownika, ale też i interakcji z tym interfejsem. Kontekstem jednak jest tutaj deska rozdzielcza i oprogramowanie wbudowane w samochód.

Dyskusja

Te dwie różne prezentacje i sposoby testowania interfejsu stały się przyczynkiem do ciekawej dyskusji wsród panelistów 😉

Zgodnie z piramidą testów automatycznych (o której jeszcze nie raz napisze, bo zebrało się trochę chmur nad tym symbolem ;)) zgodziliśmy się na panelu dyskusyjnym wraz z Tomkiem Dubikowskim, że automatyczne testy regresji przez GUI to ZUO 😉 i oczywiście najlepiej ich nie robić za dużo albo w ogóle 😉 byliśmy w opozycji do Łukaszów i Mateusza.

Przypadek1

Biorąc kontekst pierwszego projektu i pierwszej prezentacji, gdzie budowany jest CMSa – trzeba byłoby się zastanowić jakie czekają nas konsekwencje tego, że kolory, przycisk, formatka nie będą idealne, pomimo tego, że funkcjonalnie będzie można wykonać operację biznesową?

Oczywiście sporo zależy od kolejnej warstwy kontekstu, tzn. co to za firma, jaką ma markę, jak ważna jest jakość dla tej firmy – trzeba byłoby umieć obliczyć stratę wizerunkową związaną z nieidealnym GUI. Kolejną minimalizacją ryzyka mógłby być dobry proces Continous Delivery a konkretniej szybkość wychodzenia na produkcję z poprawką po wykryciu takiego błędu.

Przypadek2

Oprogramowanie wbudowane w samochód. Deska rozdzielcza. Tutaj w większości produktem końcowym jest interfejs (zakładam, że w poprzednim produktem jest jednak logika biznesowa CMSa).

Jednocześnie odpowiedzialny za takie operacje jak płynność przewijania menu po dotyku, ale też prędkość, kontrolki alarmujące, czy klimatyzacja. Po niedługiej chwili zastanowienia 😉 czuję, że tutaj nasze GUI jest mega ważne. Patrzę na ryzyko, np. jakaś warstwa multimediów przykrywa mi kontrolkę poziomu oleju … hmm 😉 Z drugiej strony jest też potencjał na wykonanie „backdoora” – np. zatrzymuje nas policja a my pokazujemy deskę rozdzielczą i mówmy, że licznik zaczął pływać i dlatego przekroczyliśmy prędkość 😉

Dodając do tego czynnik, niekoniecznie płynnych deploymentów na produkcję, jeżeli chodzi o oprogramowanie embedded (w końcu nie każdy samochód to Tesla ;)) ryzyko nam wzrasta tak samo i jak i koszt potencjalnej naprawy.

Czy warto i jak warto?

Spora pokusa, aby powiedzieć „to zależy …”. Osobiście jestem przeciwnikiem testów które spowalniają proces. W podejściu pierwszego przypadku zabrakło mi konkretniejszego uzasadnienia biznesowego. Negocjowałbym z klientem czy na pewno potrzebuje takiej automatyzacji, a jeżeli tak, to próbowałbym wpleść zapewnianie testów regresji GUI w proces. Narzędzie Applitools wymaga stworzenia przez nas tzw. baseline czyli stanu początkowego który jest dla nas akceptowalny. Kolejno, testy to „inteligentne” porównanie z baseline. Nie spodobało mi się to, że dla każdej rozdzielczości i ustawienia, systemu, czy przeglądarki trzeba taki baseline osobno wygenerować. Bardzo dużo pracy. Z kolei w procesie developmentu mógłbym prosić programistów, aby uruchamiali test który sprawdza różnice z ostatnim GUI i aby ktoś akceptował zmiany go podobnie jak każdy inny kod w procesie Code Review. Brzmi utopijnie? ktoś już próbował.

W drugim przypadku powstał cały frawemork do testów (nie tylko GUI) a z racji technologii nie było na rynku takich narzędzi. Z kolei mnie przekonuje biznesowo wypełnienie takiej potrzeby. Gdyby tylko jeszcze takie testy były podpięcie w pipeline – życzę aby się to udało (aby mieć szybką odpowiedź zwrotną).

Na koniec

Oczywiście tych którzy się spodziewali, że omówię 20 narzędzi do testów wizualnych* bardzo przepraszam, nie to było celem, a szybkie googlowanie da Wam odpowiedź. Dla mnie ważniejsze tutaj jest zrozumienie, kiedy testowanie regresji wizualnie automatycznie ma sens, a kiedy nie. Przy okazji można pokłonić się nad WCAG … i klęknąć, bo implementacja tego jest wyzwaniem.

*myślę, że tutaj są najbardziej znane

A jak jest u Was? Tematy WCAG na pewno ciekawy, proszę o kontakt w komentarzach.

Kolejny post-blog będzie wynikiem próby rozbicia panelu dyskusyjnego pytaniem: „…a czy tester powinien umieć programować…?” 😉