
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 Bilgram diagram (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.
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Ä…?â ð