Testowanie aplikacji [internetowych]

http://www.junit.org/

Czy w firmie, w której pracujesz jest dział testerów? Jeżeli jesteś z Polski, to jest bardzo duże prawdopodobieństwo, że takiego działu nie masz. Co dziwniejsze jeszcze, że im większa i poważniejsza firma, tym mniejsze szanse na istnienie działu testerów! A to dziwne!

Poniżej prezentuję 5 najbardziej prawdopodobnych powodów, dla którego w firmie, w której pracujesz nie ma działu testerów, razem z komentarzem. Powody i uzasadnienia pochodzą w dużej mierze ze świetnego artykułu Joela Spolskyego (Top Five (Wrong) Reasons You Don’t Have Testers).

Więc zaczynamy.

1. Błedy w oprogramowaniu wynikają z lenistwa programistów.

“Zatrudnienie testerów w naszej firmie spowoduje, że programiści przestaną sami testować to co tworzą i w kodzie będzie więcej błędów” – Mogło by się wydawać… Błędy w oprogramowaniu (bugi) powstają w kodzie w związku z tym, że programista ich z jakiegoś powodu nie zauważył. Programista to też człowiek, a nie ma ludzi nieomylnych. Najczęściej wystarczy, aby druga osoba spojrzała na kod/produkt aby wyłapać większość błędów. Często zdarzają się sytuacje w których coś, działające na 100% u programisty nie działa u testera. Podczas konfrontacji okazuje się, że testerka podczas rejestracji w przykładowym systemie wybierała inną płeć niż programista co w efekcie implikowało różnice.

2. Moje oprogramowanie jest dostępne on-line. Mogę naprawiać błędy od ręki.

Mogłoby się wydawać… Prawdą jest, że wprowadzanie poprawek w systemach będących on-line jest z jednej strony nieco łatwiejsze niż w przypadku aplikacji desktopowych, jednak z drugiej jest znacznie trudniejsze, ponieważ działamy na żyjącym organizmie, w momencie kiedy wprowadzamy poprawki, użytkownicy korzystają z naszej aplikacji, używają naszego serwisu. Takie poprawki “na szybko”, najczęściej wykluczają przeprowadzenie testów regresywnych i bardzo często prowadzą do stworzenia kolejnych błędów. Błędy takie są widoczne od razu dla użytkowników, co zmniejsza ich satysfakcję i prowadzi do punktu następnego:

3. Użytkownicy przetestują mi oprogramowanie.

Nie powinno się tak nawet nikomu wydawać… Z takim podejściem nie wróżę sukcesu. Jeżeli coś użytkownikowi przestaje działać – idzie do konkurencji – to w najlepszym przypadku. W gorszym, idzie do konkurencji i zaczyna rozpowiadać o naszej firmie brzydkie rzeczy, co powoduje zmniejszenie przypływu nowych użytkowników, bądź utratę większej ilości aktualnych. W jeszcze gorszym przypadku, użytkownik podczas korzystania z naszej aplikacji traci swoje dane (jakąś swoją pracę), lub jego dane osobowe zostają np. przypadkowo wysłane mailem do 100000 innych użytkowników co prowadzi do sprawy w sądzie i innych kłopotów – a tego nie chcemy. Specjalnym przypadkiem są tutaj beta-użytkownicy – jednak jest to specjalnie wyselekcjonowana grupa użytkowników, którzy świadomie podejmują pracę na niefinalnej wersji oprogramowania.

4. Nikt z odpowiednimi kwalifikacjami nie chce pracować jako tester.

Nie jest to do końca prawdą. Z jednej strony trudno jest o dobrego testera. Z drugiej jednak testy funkcjonalne nie wymagają wysokich kwalifikacji. Najlepszymi testerami funkcjonalności, są ludzie nie związani bezpośrednio z IT, warto pomyśleć o zatrudnieniu studentów kierunków humanistycznych, którzy są w stanie znaleźć bardzo dużo problemów w tworzonym przez nas oprogramowaniu.

Jest prawdą natomiast, że trudno o pracowników potrafiących uruchamiać i przeprowadzać testy jednostkowe oraz inne testy wymagające znajomości specjalistycznego oprogramowania, platform i języków skryptowych. Z drugiej strony jednak sam znam kilku dobrych testerów, którzy bardzo chętnie będą kontynuować swoją karierę jako testerzy.

Ostatni z powodów, najpopularniejszy i najbardziej bzdurny:

5. Nie stać mnie na testerów.

I jednocześnie najłatwiejszy do obalenia. Testerami w firmie mogą być praktykanci, studenci odbywający praktyki oraz np. uczniowie szkół ponadpodstawowych za niewielkie pieniądze. Ile testerzy by nie kosztowali – zawsze są tańsi niż programiści (mówimy o testerach funkcjonalności, a nie np. specjalistów od przeprowadzania testów użyteczności). Nie opłaca się, aby programiści poświęcali swój czas na testowanie, skoro w tym czasie mogą poprawiać błędy, oraz rozwijać oprogramowanie.

W początkowym stadium “zespołu testowego” warto prowadzić rekrutację, mimo kompletu testerów, i szybko wymieniać tych, którzy nie nadają się na testerów. Poza tym średnio tester pracuje na swoim stanowisku ok. 3-4 miesięcy, więc rotacja w takim zespole jest spora.

Nie warto jednak proponować swoim przyszłym programistom stanowisko testera na czas “wdrożenia”, ponieważ mogą znudzić się zadaniami testowymi i możemy stracić dobrego programistę.

Dodatkową opcją są agencje pracy tymczasowej i pracy dla młodzieży (np. http://www.timework.pl), gdzie za niewielkie pieniądze można zatrudnić młodych ludzi do prostych prac.

O testach korytarzowych. Jak, z kim, po co?

I nie chodzi o polityczny test korytarzowy: http://rafalziemkiewicz.salon24.pl/7857,index.html

Silverback (strona domowa Silverback) – Na początku wakacji miała miejsce premiera aplikacji na Mac OS, ułatawiająca przeprowadzanie testów aplikacji z użytkownkiem. Jest to jedna z aplikacji dla których warto mieć Maka. Dzięki Silverback nasz komputer zamienia się w mini laboratorium do badania aplikacji (desktopowych, lub internetowych) z użytkownikiem.

Autorem aplikacji Silverback jest firma Clearleft mogąca pochwalić się portfolio składającym się z bardzo profesjonalnych projektów internetowych. Sami korzystają z Silverback, więc daje nam to w dużej mierze gwarancję, że to dobre oprogramowanie.

O samej aplikacji – Prosty w obsłudze program daje nam możliwość:

• założenia projektu (testowana aplikacja/strona internetowa)
• założenia sesji w ramach projektu (testy z kolejnymi użytkownikami, poszczególne zadania)
• dodanie notatek do sesji
• nagranie sesji
• eksport sesji do pliku .mov

Nagrywanie sesji – Nagrywanie sesji polega na nagraniu tego co się dzieje na pulpicie, twarzy (popiersia) użytkownika, który pomaga nam testować aplikację oraz dźwięku. Nagrywanie można przerwać na chwilę – gdyby była taka potrzeba (obsługiwany jest pilot).

Eksport sesji – Silverback eksportując sesję do pliku video daje nam możliwość umieszczenia filmu z użytkownikiem w rogu filmu z wydarzeń na pulpicie, możemy wybrać rozmiar tej wstawki, oraz to czy ma być półprzezroczysta. Kliknięcia, które wykonał użytkownik podczas testu są zaznaczone na filmie promieniście rozchodzącym się kołem koloru pomarańczowego. Dodatkowo, jeżeli użytkownik korzystał z klawiszy funkcyjnych (command, control, option) będzie to zaznaczone na filmie.

Podsumowanie – Program jest bardzo prosty w obsłudze, a korzystanie z niego daje sporą satysfakcję. Na podstawie kilkunastu testów przeprowadzonych dzięki Silverback mogę powiedzieć, że przeprowadzanie testów użyteczności stało się przyjemniejsze i łatwiej je wykonywać w warunkach polowych : )

Inżynieria oprogramowania to dziedzina inżynierii systemów zajmująca się wszelkimi aspektami produkcji oprogramowania: od analizy i określenia wymagań, przez projektowanie i wdrożenie, aż do ewolucji gotowego oprogramowania. Podczas gdy informatyka zajmuje się teoretycznymi aspektami produkcji oprogramowania, inżynieria oprogramowania koncentruje się na stronie praktycznej.

Automatyzacja testowania

http://www.zenspider.com/ZSS/Products/ZenTest/

Standardowe przeglądarki są wyznaczane oczywiście przez użytkowników. Od kilku lat w czołówce są Firefox i Internet Explorer, mocno za nimi Opera, i później kolejne, niszowe. Ostatnio swoje 5 minut miał Chrome, o którym pisałem tutaj, jednak aktualnie spadł poza pierwszą piątkę.

Za “standardowe” warto uznać przeglądarki, których używa ponad 1% użytkowników (w Polsce, lub na świecie, w zależności od grupy docelowej naszej strony). Dane takie można uzyskać na stronie Ranking.pl, która oferuje również dużo innych wartościowych statystyk.

Także na chwilę obecną (staram się aktualizować aktualną stronę przynajmniej raz na miesiąc…), standardowymi przeglądarkami są:

• Firefox 3.x
• MSIE 6.x
• MSIE 7.x
• Firefox 2.x
• Opera 9.x

Generalnie, od dłuższego czasu są to zawsze dwie najnowsze wersje (major) przeglądarek Firefox i Internet Explorer, oraz najnowsza wersja Opery. Na świecie do tej grupy dołącza jeszcze najnowsza wersja Safari, używana głównie na komputerach Apple.

Przeglądarki w grudniu 2008 - dane z Ranking.pl (aktualizowane 2008-12-09)

Nie znaczy to jednak, że nie należy dbać o pozostałe przeglądarki. Dobrze jest, aby w pozostałych, o których mamy wiedzę, że użytkownicy naszej aplikacji mogą korzystać (np. Flock w przypadku osób czynnie korzystających z serwisów blogowych i społecznościowych) strona przede wszystkim działała – ale także wyglądała w zadowalający sposób.

Jeżeli chcesz się upewnić, że Twoja strona nie zniechęci częsci użytkowników przy pierwszy zetknięciu, sprawdź, czy spełniasz wszystkie punkty z checklisty!

http://www.xdebug.org/

The Xdebug extension helps you debugging your script by providing a lot of valuable debug information. The debug information that Xdebug can provide includes the following:

* stack traces and function traces in error messages with:
o full parameter display for user defined functions
o function name, file name and line indications
o support for member functions
* memory allocation
* protection for infinite recursions

Wincachegrid: dla platformy Windows

http://www.google.pl/search?hl=pl&lr=&safe=off&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=wincachegrid&spell=1

http://simpletest.org SimpleTest
The SimpleTest PHP unit tester

Testy jednostkowe

http://blog.dywicki.pl/2007/04/22/testy-jednostkowe/

http://pl.wikipedia.org/wiki/Test_jednostkowy

http://groups.google.com/group/warszawa-jug/msg/e884a94ed899bfa3?pli=1

http://aplikacja.info/Piekielne_Testy_Jednostkowe.html

http://www.javaranch.com/journal/200603/EvilUnitTests.html

http://dzbanyit.pl/2008/04/01/testy-jednostkowe-lekarstwem-na-twoje-problemy/

http://4programmers.net/Java/Testy_jednostkowe

http://www.symfony.pl/dokumentacja/testowanie_jednostkowe_i_funkcjonalne

http://www.junit.org/