blog.testowka.pl

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.

Jakość oprogramowania – pojęcie wszystkim znane, ale czy na pewno? Gdy patrzę na opublikowane w Sieci Strony/Serwisy WWW odnoszę wrażenie, że niewielu ich twórców zdaje sobie sprawę z tego, że to co tworzą oczywiście wnosi jakąś ściśle określoną funkcjonalność ale niestety dostęp do tej funkcjonalności jest bardzo ograniczony z wielu powodów.

Blog ten powstał po to by pokazać pewne “proste” rozwiązania, dzięki którym codzienne życie zwykłego, szarego użytkownika Internetu może stać się dużo łatwiejsze.

Jako inżynier jakości oprogramowania i inżynier testów moim obowiązkiem jest między innymi dbanie o to, by korzystanie z produktów naszej firmy było łatwe i przyjemne.

Obserwując zachowania “zwykłych” internautów dostrzegłem, że znaczna większość tych, którzy na co dzień używają internetu do bardzo wielu, zdawałoby się czasem prozaicznych rzeczy, jak np. sprawdzanie poczty, czytanie artykułów, przeglądanie Naszej-Klasy, czytanie tego bloga etc. tak na prawdę nie zdaje sobie sprawy z istnienia znacznej części funkcjonalności jakie witryny, które przeglądają każdego dnia im oferują.  Spowodowane jest to między innymi tym, że projektanci witryn nie poświęcili wystarczającej uwagi na to by poinformować w odpowiedni, wystarczająco czytelny sposób użytkownika o istnieniu takiej czy innej funkcjonalności.  Wynika to często z tego, że programiści, projektanci – ogólnie ludzie biorący udział w produkowaniu wszelkiego rodzaju oprogramowania, stron WWW etc. zapominają dla kogo dana aplikacja jest stworzona. Oczywistym jest, że ludzie z tzw. branży IT w środowisku komputera, Internetu poruszają się ze znacznie większą swobodą niż zwykły zjadacz chleba. Znając Sieć na wylot, korzystając z niej po kilka/kilkanaście godzin dziennie wszystko wydaje się na pozór bardzo proste – wynika to z tego, że po pewnym czasie wyrabiamy w sobie pewne nawyki szukania niektórych rzeczy w odpowiednich miejscach. Niestety zwykli śmiertelnicy spędzający góra 2-3 godziny na poszukiwaniu i przetwarzaniu informacji w Internecie  (najczęściej to właśnie tacy ludzie są najbardziej pożądanymi odbiorcami naszych produktów) nie posiadają wrodzonych ani nabytych nawyków nawigacji w sieci. Normalny świat ma 3 wymiary przestrzenne w Internecie nawigacja nie musi ograniczać się tylko do tych trzech wymiarów, poza tym “przestrzeń” Internetu czy oprogramowania komputera można rozpatrywać na bardzo wielu poziomach abstrakcji.

Pisząc tutaj chce zwrócić uwagę osób zajmujących się jak by nie było kreacją Internetu na to, że nie jest On tylko ich własnością, i pożądane jest by jego możliwości były dostępne i widoczne dla wszystkich jego użytkowników.

Kolejnym powodem, dla którego tutaj pisze jest czas – niezwykle dużo czasu, który niepotrzebnie marnujemy korzystając z dostępnych w Sieci narzędzi,  do wykonania różnych niezbędnych czynności.

Od czasów realnego rozwoju WEB 2.0 Internet stał się niezwykłym medium i narzędzie, które umożliwia komunikacje między ludźmi na duże odległości, co niesie ze sobą kolejne możliwości wykonywania z użyciem Sieci bardzo szybko rzeczy, które do tej pory zajmowały wiele czasu i nerwów – miedzy innymi zakupy, poczta, operacje bankowe, informacje, wszelkiego rodzaju multimedia etc. Niestety muszę z przykrością stwierdzić, że wiele z tych czynności pomimo tego, że przez Internet nadal zajmuje więcej czasu niż mogło by zajmować, zwłaszcza wspomnianym wcześniej “zwykłym” użytkownikom. Nie wynika to wyłącznie z niedostatecznej wiedzy użytkowników na temat Internetu. Nie uważam siebie za eksperta w dziedzinie serfowania po Sieci, wyszukiwania w Niej informacji, czy przeprowadzania z Jej użyciem różnych operacji, ale często zdarza mi się poświęcić zbyt wiele czasu na zrobienie czegoś tylko dlatego, że interfejs użytkownika danej strony nie jest na tyle czytelny i oczywisty, że nawet ja, który spędzam dużo czasu korzystając z Internetu muszę kilkukrotnie wklepywać dane do formularzy, klikać magiczny przycisk wstecz w przeglądarce (co często skutkuje błędami na stronie), czy marnować czas na zastanawianie się nad znaczeniem komunikatu, który mam przed oczami by zrozumieć co autor miał na myśli i co robię nie tak, oraz w jaki sposób to poprawić by wreszcie osiągnąć zamierzony cel.

To wszystko można podsumować jednym słowem USABILITY, oczwiście tylko podsumować, bo znaczenie tego słowa ma dużo szerszy zakres i to właśnie między innymi moje przemyślenie w tym temacie zamierzam zamieszczać w następnych postach. Będzie też pewnie wiele na temat Testowani Oprogramowania i Inżynierii Oprogramowania, którymi z pasja także się zajmuję na codzień.