blog.testowka.pl

Archiwum wiadomości z Maj, 2009

Siła usability – przycisk wart 300 milionów $

opublikowany przez 30, Maj, 2009, w kategoriach Inne

Czasami klienci pytają ile warte są badania usability? Oto odpowiedź – 300.000.000$ tylko na jednej stronie.

Historia jest zadziwiająca. Pewien sklep internetowy w USA chcąc zwiększyć swoje dochody zatrudnił specjalistów od usability. Specjaliści przeprowadzili proste badania, mianowicie obserwowali zachowanie użytkowników odwiedzających witrynę sklepu. Pierwszy wskaźnik na który zwrócono uwagę to ilość odrzuceń – ilość osób opuszczających stronę nie dokonawszy zakupu. Wskaźnik ten był duży, ale samo to nie oznaczało jeszcze nic konkretnego – mogło być spowodowane np. nieciekawą ofertą sklepu, lub wygórowanymi cenami etc. Badacze skupili się jednak na miejscu w którym klienci najczęściej rezygnują z zakupów. Jak się okazało bardzo duży ich odsetek rezygnował (opuszczał stronę) nie w trakcie przeglądania artykułów lecz już po dodaniu ich do koszyka. Co było tego przyczyną – dwa pola formularza i przycisk. Pola te to adres e-mail i hasło, a przycisk opatrzony był mistycznym napisem „Zaloguj”. Był to strzał w dziesiątkę. Pierwsi projektanci serwisu zapomnieli o jednej z podstawowych zasad użyteczności aplikacji – aplikacja ma służyć określonym celom, tak więc sklep internetowy nie jest portalem społecznościowym do którego trzeba się zapisać podając różne dane, sklep przede wszystkim służy do robienia zakupów, więc to ta czynność powinna być maksymalnie uproszczona. Opracowano więc najprostszy z możliwych algorytmów dokonywania zakupów: Wybór towaru -> dodanie do koszyka -> zapłata -> podanie adresu do wysyłki. Żadnego zbędnego logowania i rejestracji. W celach marketingowych  (a także, by ułatwić zakupy stałym klientom) nie zrezygnowano całkowicie z rejestracji użytkowników, ale stała się ona opcjonalna. Jedna mała zmiana napisu na przycisku z „Zaloguj” na „Dalej” wystarczyła by ilość pozytywnie zakończonych zakupów zwiększyła się  się o 45% co w efekcie w pierwszym miesiącu zwiększyło zyski sklepu o 15.000.000$. W pierwszym roku po zmianie zyski były większe w stosunku do roku poprzedniego w sumie o 300.000.000$ . Ile warte są badania usability? W tym wypadku 45% więcej zysków.

O powyższym przypadku było głośno ze względu na kwotę, którą udało się zarobić dzięki postawieniu na użyteczność aplikacji. Ale to nie wszystko – czytałem/słyszałem o wielu przypadkach gdzie za pomocą drobnych zmian w usability zwiększono zyski portali nawet kilkunastokrotnie.

Tak więc jeśli ktoś Was spyta ile warte jest usability śmiało możecie mówić że   300.000.000 dolarów.

Dodaj komentarz więcej...

46 Sesja kół naukowych AGH – Usability w praktyce

opublikowany przez 30, Maj, 2009, w kategoriach Inne

21 maja odbyła się pierwsza tura Sesji kół naukowych pionu hutniczego AGH w której brałem udział wygłaszając (bardzo krótki) referat o tym jak usability powinno wyglądać w praktyce. Chciałbym podziękować wszystkim słuchaczom za uwagę oraz Komisji, która moją prelekcję nagrodziła wyróżnieniem.

Niestety podczas regulaminowych piętnastu minut ciężko było powiedzieć cokolwiek szczegółowego o użyteczności oprogramowania, więc prelekcja miała charakter bardzo szybkiego mówienia o ogółach i krótkiego przedstawienia przykładów, przytoczenia pewnych anegdot.

Wszystkich zainteresowanych tematyką użytecznosci aplikacji zapraszm na najbliższe spotkanie Witajcie w Realu z Markiem Kasperskim (UI Design), które odbędzie się w środę 3 czerwca w Rotundzie.

Dodaj komentarz więcej...

Testowanie wymagań

opublikowany przez 18, Maj, 2009, w kategoriach Agile, Praca, Scrum, Testowanie, Zarządzanie

„Testowanie wymagań i chodzenie po wodzie jest łatwe pod warunkiem, że są zamrożone”

Planując testy akceptacyjne staram się oprzeć na wymaganiach, które według klienta powinny zostać spełnione by aplikacja była akceptowalna. To jest oczywiste. Jednak co zrobić, gdy wymagania zmieniają się wraz z rozwojem aplikacji, jak to często w projektach Agile’owych i nie tylko bywa? Standardowy model „V” nie nadaje się tutaj do  zastosowania, gdyż zakłada on planowanie testów akceptacyjnych, a co za tym idzie implementację tych testów w odpowiedniej, stosunkowo wczesnej fazie projektu. Przy takim rozwiązaniu gdy testy są wcześnie zaimplementowane a wymagania nie są do końca sprecyzowana (ulegają ciągłym zmianom) utrzymanie testów staje się zbyt kosztowne.

Testowanie zmieniających się wymagań nigdy nie będzie proste i nigdy nie będzie tanie, chociażby  nie wiem jak te testy były zaplanowane i napisane/zrealizowane. Najbardziej optymalnym rozwiązaniem w takiej sytuacji jest powrót do podstaw i rozbicie aplikacji na poszczególne podsystemy o określonych, zawężonych funkcjonalnościach, maksymalnie oddzielone od reszty aplikacji, po czym doprowadzenie kolejno jeden po drugim każdy z tych podsystemów do oczekiwanego akceptowalnego stanu. W innym wypadku wpadniemy w „Cowoboy Coding” z „Bug Huntingiem”, co obrazuje się w sposób następujący: testerzy znajdują błędy w różnych częściach aplikacji, developerzy je poprawiają, dodają nową funkcjonalność psując coś w innym miejscu, testerzy lub automatyczne testy znajdują te błędy, deweloperzy  znów poprawiają psując coś innego i tak w kółko. Nie da się ogarnąć projektu bez zaplanowanej metodologi działania. Wszelkie poprawki i zmiany powinny być z góry zaplanowane i w odpowiedni sposób przetestowane przed wysłaniem ich na serwer, gdzie następują testy integracyjne. Bardzo istotny jest obieg informacji – co, kto i dlaczego robi, oraz co jeszcze ktoś inny będzie musiał  z tym zrobić. W agile testowanie w dużym stopniu opiera się na testach poszczególnych funkcjonalności, które wykluczają większość błędów nie wynikających z problemów integracyjnych.

Słyszałem o aplikacjach powstających metodą „Wielkiego Wybuchu”, która polega na tym, że wszyscy nagle siadają i coś kodują, starając się nie wchodzić sobie w drogę. Zazwyczaj kończy się to wielkim bałaganem, który czasem nawet działa ale nikt nie jest z niego zadowolony. Najgorsze jednak w tym wszystkim jest to, że jeśli przyjdzie zrobić jakąś zmianę, albo poprawić jakieś błędy to nagle okazuje się, że wiele fragmentów kodu jest zduplikowanych, albo zależy od nich zbyt wiele innych części aplikacji.

Rozwiązaniem większości problemów jest skrupulatne planowanie oraz pozostawienie możliwości przyszłego rozwoju dla każdej części aplikacji w każdym możliwym kierunku. Ważnym jest też dobór odpowiedniej metodologii. Dzięki tym rozwiązaniom nawet najbardziej zmienne wymagania nie są nam straszne. Jeśli wymagania się zmieniają, wracamy do odpowiedniej części aplilkacji i ponownie pracujemy nad nią, aż nowe wymagania zostaną spełnione, nie ingerując w inne części projektu.

2 komentarze więcej...

Testowanie w Agile (Scrum)

opublikowany przez 01, Maj, 2009, w kategoriach Agile, Praca, Scrum, Testowanie

Przeczytałem kilka publikacji na temat testowania w metodologiach zwinnych, ale jak do tej pory żadna nie oddaje w pełni tego co ja doświadczyłem podczas pierwszego zetknięcia się z testowaniem w Scrum’ie ( o nim samym może innym razem). Jak ogólnie wiadomo Scrum zakłada iteracyjny model wytwarzania oprogramowania, czyli po każdym sprincie (w moim przypadku co dwa tygodnie) powinniśmy mieć przynajmniej jedną nową, w pełni działającą „funkcjonalność”.

Mądre książki podają, że podstawą takiego wytwarzania oprogramowania są automatyczne testy pisane przed rozpoczęciem implementacji właściwego kodu programu – nie zamierzam z tym polemizować, gdyż jest to działka raczej programisty nie testera. Kolejną rzeczą która powinna zostać zrobiona jest tworzenie i aktualizowanie na bieżąco automatycznych testów funkcjonalnych (Selenium, TestComplete, etc.) – słuszne podejście, moje ostatnie doświadczenia potwierdziły istotność takich testów, a konkretnie potwierdził to ich brak. Utrzymanie automatycznych testów funkcjonalnych jest jednak czasochłonne i kosztowne. Przejdźmy więc do testów manualnych. Jak testować w modelu iteracyjnym?

Działając zgodnie z procedurami opisanym tu i ówdzie testowałem każdą nową funkcjonalność z osobna (tutaj znów spostrzegłem potrzebę istnienia automatycznych testów, gdyż nie sposób było przetestować całą aplikację po każdej małej zmianie), przynosiło to dobre efekty, lecz jedynie na krótką metę, ponieważ jeśli chodzi o nowe, właśnie wprowadzone funkcjonalności mogliśmy z dużym prawdopodobieństwem stwierdzić, że działają poprawnie, lecz niestety aplikacja jako całość w zasadzie nigdy (aż do testów akceptacyjnych) nie została przetestowana. I tu pojawia się właśnie rola testów akceptacyjnych, które zostały zostawione na sam koniec. Czy to złe podejście? Moim zdaniem nie do końca, dzięki temu unikamy zbędnego powtarzania się (zakładając, że nie mamy do dyspozycji automatycznych testów funkcjonalnych), testy akceptacyjne w których z konieczności zawierają się także testy integracyjne, mogą zostać przeprowadzone w środowisku praktycznie identycznym z produkcyjnym. Liczba błędów, które udało mi się znaleźć podczas tych testów jest naprawdę znikoma, co ukazuje wyższość zwinnych testów  każdej poszczególnej funkcjonalności i poprawność odizolowania od siebie poszczególnych części kodu aplikacji (co też powinno być/jest niepisaną zasadą Scrum’a). Błędy które znalazłem wynikały głównie ze środowisk na których aplikacja została zainstalowana.

Lecz to jeszcze nie koniec  – jak wiadomo najlepszymi testerami są zwykli użytkownicy, dlatego głośno i stanowczo postuluje za tym, by wszystkie większe projekty agile’owe były wydawana najpierw w wersji BETA i dopiero po zatwierdzeniu przez grupę testowych użytkowników publikowane jako gotowe finalne wersje produktu. Myślę, że nawet koszty obniżenia ceny pierwszej wersji produktu zostaną zrównoważone jego jakością. Spójrzmy na najlepszych/największych Gmail od pięciu lat jest w wersji beta i pewnie jeszcze długo będzie, jest to typowy przykład projektu rozwijanego iteracyjnie w Agile, testowany przez klientów i cieszący się dużą popularnością oraz względną niezawodnością.

O kosztach testowania postaram się napisać innym razem. Konkluzja: pozostawienie integracyjnych testów na sam koniec wydaje się być w miarę rozsądne, oczywiście jeśli mamy na to czas.

3 komentarze więcej...