Testowanie aplikacji internetowych
Kilka dni temu odbyło się w Empathy spotkanie działu technologicznego poświęcone tematyce testowania aplikacji i serwisów internetowych. Celem takich spotkań jest wymiana wiedzy na temat różnorodnych zagadnień związanych z tworzeniem aplikacji internetowych. Każdy ma przecież trochę inne zainteresowania, specjalizuje się w czymś innym, a nikt nie jest w stanie ogarnąć wiedzy posiadanej przez resztę zespołu. Warto jednak wiedzieć jak najwięcej, także po to, aby lepiej zrozumieć pracę innych osób zaangażowanych w projekt i tym samym poprawiać współpracę.
Już na początku padło przykre stwierdzenie: w polskim Internecie można znaleźć stosunkowo niewiele informacji na temat testowania aplikacji internetowych. Co może oznaczać, że stosunkowo niewiele osób zajmuje się w Polsce tym zagadnieniem.
Skąd jednak w ogóle potrzeba testowania tworzonych aplikacji? Cóż, jak wszyscy ludzie, programiści są niedoskonali (wbrew temu, co niektórzy z nich mogą o sobie uważać). Niestety, bardzo często klienci nie rozumieją dlaczego w harmonogramie projektu pewna ilość czasu zostaje przeznaczona na testowanie. Dlaczego mają płacić za coś, co powinno zostać zrobione dobrze?!
„Widzę tutaj pole do optymalizacji!”
M.in. z tego powodu bywa to etap niedoceniany przez obie strony, zarówno zleceniodawców, jak i wykonawców. Prowadzi to do tego, że testowanie jest etapem, o który najchętniej skraca się harmonogram projektu. Cytując jednego z klientów (widzącego w harmonogramie kilka tygodni przeznaczone na testowanie): „Widzę tutaj pole do optymalizacji!”. Klienci często nie wiedzą, że testowanie jest niezbędne, a błędy są czymś normalnym w każdym procesie trwającym wiele miesięcy i obejmującym grupę ludzi. To nie dotyczy tylko programowania.
Czas przeznaczony na testowanie traktowany także bywa jako bufor w przypadku opóźnień w harmonogramie. Testy są skracane, albo w ogóle się z nich rezygnuje, żeby zmieścić się w ustalonych terminach. Kończy się to nie raz stwierdzeniem: wiemy o problemie, ale poprawimy go później. Znamy błąd, wiemy jak go naprawić, ale ze względu na brak czasu nie zostaje on poprawiony.
Metody testowania
Dlaczego nie jest wskazane, aby programiści testowali aplikacje, które współtworzą i dlaczego warto zatrudniać osoby specjalizujące się w testowaniu?
- Programista testuje aplikację na swój sposób. Wie zbyt wiele na temat tego, jak działa, jak będzie się zachowywać w pewnych sytuacjach itd. Pewne rzeczy może robić nawet podświadomie.
- „U mnie działa” – często słyszana odpowiedź. Nie raz bywa, że działa tylko u tego jednego jedynego programisty.
Najważniejsze metody testowania dzieli się na dwie kategorie: white box i black box.
White box
Wymagają znajomości języka oraz technik programowania, tester uzyskuje dostęp do kodu źródłowego aplikacji. Do tych metod zaliczamy m.in. testy jednostkowe (unit testing). Są one jednak czasochłonne (mogą powodować nawet dwukrotne zwiększenie czasu tworzenia aplikacji) i z tego powodu najczęściej wykorzystywane w najważniejszych, core’owych funkcjach systemu oraz w produktach pudełkowych, które trudniej aktualizować w przyszłości.
Black Box
Tester nie posiada dostępu do kodu, nie wie jak aplikacja została zrealizowana. Korzysta on z aplikacji tak, jak robiliby to przeciętni użytkownicy, z tym, że szuka głównie problemów. Do tych testów możemy zaliczyć:
Testy usability – testy użyteczności. To w ogóle osobny, bardzo rozbudowany temat, a samych metod testowania jest bardzo wiele. Ogólnie chodzi jednak o zbadanie ergonomii aplikacji, czy jej nawigacja jej intuicyjna, użytkownicy posiadają łatwy dostęp do potrzebnych informacji, a sama aplikacja komunikuje się z nim w zrozumiały sposób.
Testy ad-hoc (ciągle popularne) – korzystanie z jak największej ilości funkcjonalności aplikacji bez uprzedniego przygotowania. Często wykonywane przez testerów nie znających aplikacji, którym pomagają ją poznać i zweryfikować kompletność scenariuszy testowych.
Testy funkcjonalne – wykonywane przez osoby spoza zespołu projektowego. Sprawdzają zgodność aplikacji z wymaganiami funkcjonalnymi. Wykonywane w oparciu o scenariusze testowe, czyli zbiory przypadków testowych (informacja o tym jak sprawdzać dane wymaganie funkcjonalne, np. jak sprawdzić logowanie).
Testy akceptacyjne – opisane przez przypadki, plany i scenariusze testowe. Przeprowadzane przez przedstawicieli klienta. Potwierdzają, że aplikacja/serwis została właściwie wykonana.
Testy bezpieczeństwa – polegające na sprawdzaniu zabezpieczeń aplikacji, obejmujące także symulowanie ataków. To ważny element, ale niestety niedoceniany. Organizacją działającą na rzecz bezpieczeństwa aplikacji i serwisów internetowych jest OWASP. Prowadzi ona listę Top 10 najpoważniejszych zagrożeń dla aplikacji webowych. Polecamy się z nią zapoznać.
Testy wydajnościowe – sprawdzające skalowalność systemu, testy obciążeniowe, czas oczekiwania, odpowiedzi serwisu itp. Także testy przeciążeniowe oraz testy obciążeniowe mające sprawdzić, jak aplikacja działa przy różnym obciążeniu. Są one wykonywane poprzez symulacja warunków docelowych.
Testy regresywne – po wprowadzeniu zmian sprawdzamy, co przestało działać właściwie.
Alpha i beta testy – alpha testy są przeprowadzane wewnątrz firmy (wykonawcy, zamawiającego) na szerszej grupie użytkowników. Beta testy z kolei przeprowadza się pod koniec realizacji projektu jeszcze liczniejszej grupie użytkowników. Często są to wręcz otwarte testy. Jest to ostatnio popularna metoda, z niektórych serwisów znaczek „wersja beta” nie znika przez miesiące.
Na koniec testy można jeszcze podzielić na testy manualne i automatyczne. Manualne to po prostu korzystanie z aplikacji z poziomu różnych przeglądarek internetowych, tak jak będą robić to jej użytkownicy. Testy można jednak wykonywać także automatycznie. Np. przy pomocy aplikację Selenium. Jako narzędzia wspomagające można wykorzystać np. TestLink , FireBug lub Fiddler.
Idealny tester
Ze względu na specyfikę pracy testera, do jej wykonywania najlepsze są osoby o określonych predyspozycjach. Ważna jest dokładność i powtarzalność, cierpliwość i komunikatywność. Nie wystarczy przecież znaleźć błąd, trzeba także przekazać o nim dokładne informacje odpowiednim osobom.
Jak jest w Empathy?
W ramach naszych struktur od jakiegoś czasu funkcjonuje dział testerów, który odpowiada za sprawdzanie rozwiązań stworzonych w ramach projektowania i rozwoju aplikacji. Procedury systemu zarządzania jakością ISO, który jest wdrożony w naszej firmie zobowiązują nas do weryfikacji projektu pod kątem zgodności z wymaganiami specyfikacji przed jego przekazaniem Klientowi. Jakkolwiek zdajemy sobie sprawę, że optymalne efekty funkcjonowania takiej komórki osiągniemy dopiero za kilka miesięcy, to już teraz widzimy że znacząco wpłynęło to pozytywnie na liczbę i stopień ważności zgłaszanych przez Klientów błędów.
A jak to wygląda u Was?
Jesteśmy ciekawi, jak procesy testowania przebiegały w Waszym przypadku, niezależnie od tego, czy braliście w nim udział po stronie klienta, czy wykonawcy. Czy uważacie, że często przywiązuje się do nich zbyt małą wagę? Zachęcam do dyskusji.
Warto zajrzeć: www.testerzy.pl, www.owasp.org
Szymon SzymczykTagi: Aplikacje internetowe, Empathy od kuchni, Spotkania, Testowanie, Usability, współpraca z klientami
grudzień 16th, 2009 at 10:23
Fajnie, że poruszylilście ten temat.
Chciałem tylko od siebie dodać, że można trochę pozytywniej spojrzeć na unit testy i nie sprowadzać tematu testów automatycznych do selenium. To że “polski internet” milczy na temat testowania, nie zmienia faktu, że internet jako taki aż od tego huczy. Zwłaszcza wśród developerów frameworki z rodziny xUnit cieszą się bardzo dużym powodzeniem i obserwuje się częściej skrócenie czasu pracy przy wykorzystaniu unit testów, a nie jego “dwukrotne” wydłużenie (skąd te dane?).
Brak testów automatycznych rodzi chyba największe problemy przy testach regresji, gdy na pierwszym etapie (przed wdrożeniem) poświęca się dużo czasu na testy, które mogą nie mieć aż tak dużego znaczenia, gdy aplikacja ulegnie zmianie.
I jeszcze jedna rzecz o testach jednostkowych, zwróćcie uwagę jak dużo różnych idei powstaje jakby obok tematyki testów, a jednocześnie bardzo poprawia architekturę aplikacji – z najważniejszych wymienię choćby Inversion of Control.
W każdym razie życzę jak najwięcej powodzenia w Waszych testach
grudzień 16th, 2009 at 12:35
Dzięki za ciekawy komentarz!
W kwestii wydłużenia czasu pracy przy zastosowaniu unit testów – są to nasze wewnętrzne obserwacje. Porównywaliśmy czas tworzenia podobnych funkcji z unit testami i bez nich.
Bardzo prosto (szybko) jest zrobić proste unit testy, jednakże one nam wiele nie dają – ważne, żeby unit testy pokrywały odpowiednio zagadnienie, a to już jest dużo trudniejsze.
Są pewne narzędzia, które mogą wspomóc proces tworzenia unit testów – np. Pex:
http://research.microsoft.com/en-us/projects/Pex/
Niestety takie podejście trochę zaprzecza unit testom – które powinny być robione przed kodowaniem, ale rozwiązuje część problemów – np. przydaje się przy testach regresywnych.
grudzień 20th, 2009 at 17:15
Cześć.
Unit testy wcale nie muszą być tworzone przed kodowaniem. Jest to tylko jedna z dobrych praktyk. Pex także wcale nie musi powodować pisania testów po implementacji, zwłaszcza po wprowadzeniu Code Contracts w C# 4.
ale to wcale nie zmienia faktu, że z punktu widzenia developera nie powinno się do tego zmierzać. Wcale nie uważam, że z punktu widzenia firmy takie podejście jest dobre/złe, natomiast patrzę z pozycji developera.
Ale co na ten temat myśli google: http://gojko.net/2009/12/07/improving-testing-practices-at-google/
Unit testy powinny być proste i powinno się je szybko pisać. Jeżeli zaczyna być trudno tzn., że najprawdopodobniej architektura aplikacji na to nie pozwala. Jeżeli zagadnienie jest trudne i dodatkowo ciężko je przetestować to mamy dużą szansę na sporą ilość błędów. Natomiast, jeżeli zagadnienie jest trudne, ale uda się wprowadzić odpowiednią dekompozycję problemu to mamy lepszą architekturą, a dodatkowo możemy łatwo przetestować poszczególne fragmenty zagadnienia.
Ok, tak jest w idealnym świecie
Także uważam, że tworzenie architektury, która pozwala na automatyczne testowanie jest trudne, ale tak samo tworzenie dobrego oprogramowania jest trudniejsze niż tworzenie oprogramowania złego. Oprócz tego, tak samo jak istnieje dobre i złe oprogramowanie istnieją dobre i złe testy.
Podsumowując, pisanie testów jest trudne, nie dlatego, że jest trudne samo w sobie. Stworzenie testable design jest po prostu elementem, który stanowi o trudności. Oczywiście kluczowe w tym momencie jest pytanie czy testable design jest warte poświęconego czasu/pieniędzy? Moim zdaniem, jak najbardziej.
Strasznie skomplikowana jest ta kwestia
Pozdrawiam
Btw, w zamyśle imagine blog ma być bardziej techniczny czy bardziej na zasadzie bloga firmowego?
grudzień 21st, 2009 at 14:41
Odpowiadając niejednoznacznie na ostatnie pytanie.
ImagineBlog ma być bardziej blogiem firmowym, przy czym chcemy dużo pisać o kwestiach technicznych związanych ze specyfiką naszych realizacji, czyli aplikacjach internetowych.
Blog ruszył stosunkowo niedawno i jego ostateczna formuła jeszcze się krystalizuje;)
grudzień 23rd, 2009 at 04:18
dobry poczatek