Wymagania biznesowe wobec systemów sprzedaży internetowej często się zmieniają. Nowe zachowania konsumentów oraz okazje, które pojawiają się przed sprzedawcami, wymagają szybkich zmian. Konsekwencją rozwoju oprogramowania jest wzrost skomplikowania jego kodu oraz struktury. Zdarza się nawet, że modyfikacje takie jak nowe promocje i algorytmy naliczania cen, wymykają się spod kontroli programistów. Robimy zatem wszystko aby zapobiec negatywnym skutkom działania oprogramowania, które zawiera błędy.

Platforma sprzedażowa, która nie działa (jest niedostępna), przynosi wymierne straty. Jeśli strona sklepu wczytuje się zbyt wolno lub wyświetla komunikaty błędów, nie jest możliwe dodawanie produktów do koszyka i składanie zamówień. Nawet krótkotrwałe przerwy w działaniu mogą spowodować rezygnacje klientów i stracenie ich na korzyść konkurencji.

Jeśli strona działa,  ale ceny są źle wyliczone – klienci mogą wykorzystać tę lukę i złożyć zamówienia.  Takie sytuacje się  zdarzają i dotyczą nawet największych sklepów (np. awaria Empik.com w 2011r.). Konieczność dopłaty do realizacji zamówień, spadek zaufania i złe opinie klientów, a w skrajnych przypadkach postępowania sądowe to przykładowe efekty błędów w oprogramowaniu.

Osoby z długoletnim stażem w dziedzinie informatyki, powtarzają, że nie ma oprogramowania komputerowego bez błędów. W czasie tworzenia nowych funkcjonalności, nie da się przewidzieć wszystkich scenariuszy. Ale można i należy uczynić co tylko możliwe, aby temu zapobiec lub sprowadzić do absolutnego minimum.

Dobry projekt oraz stosowanie wzorców w czasie tworzenia kodu aplikacji to sprawdzone, ale niewystarczające, sposoby unikania problemów. Niezależnie od stosowanej metodyki prowadzenia projektu nie powinniśmy zapominać o testach.

Testowanie oprogramowania nie powinno być czynnością jednorazową. Praktyka pokazuje, że większość systemów jest dokładnie testowana w momencie zakończenia prac i odbioru przez zamawiających. Takie podejście – znajdujące analogię np. w branży budowlanej  – nie jest w świecie oprogramowania do końca prawidłowe.  Rozwój oprogramowania nie kończy się w momencie uruchomienia pierwszej wersji. Nowe funkcje pojawiają się w związku ze zmianami wymagań. Razem z nowymi funkcjami do systemu trafiają nowe błędy. Jakość oprogramowania, które w czasie rozwoju nie jest testowane, może podlegać degradacji.

Oprócz nowych funkcjonalności na zmianę sposobu działania systemu wpływają zmieniające się warunki pracy. Przyrost liczby użytkowników, zamówień, produktów w bazie danych , może spowodować wolniejsze działanie i spadek przepustowości. Aplikacja może inaczej zachowywać się w środowisku testowym (gdzie prowadzony był odbiór), a inaczej w środowisku produkcyjnym (na serwerach docelowych, do których dostęp mają użytkownicy).

Powinniśmy utrzymywać działającą wersję testową, która może być dobrym „poligonem doświadczalnym” dla zespołu. Środowisko pośrednie tzw. stage, który będzie odbiciem środowiska produkcyjnego.  Taką wersję można poddawać różnego rodzaju testom, bez  wywoływania negatywnych wrażeń u użytkowników.

Testom powinniśmy poddawać te elementy systemu, które zmieniają się i są kluczowe w jego pracy. Wszystkie testy, które będziemy przeprowadzać, wiążą się z kosztami i zaangażowaniem zespołu, dlatego konieczne jest zachowanie szczegółowości i kontroli w trakcie całego procesu.

Testy użyteczności interfejsu użytkownika (ang. UI Tests)

Testy interfejsu (testy użyteczności) przeprowadzane są z przyszłymi użytkownikami, na podstawie prototypów interfejsu (np. makiet funkcjonalnych). Warto wykonać je przed rozpoczęciem prac wdrożeniowych.  Dzięki temu wprowadzanie usprawnień i zmian w aplikacji nie wiąże się z dużymi kosztami.

Test polega na wydaniu osobom badanym konkretnych poleceń.  na przykład: „Dokonaj zakupu komputera osobistego”. Użytkownik poddawany takiemu badaniu wskazuje– korzystając z prototypu – sposób, w jaki odnajdzie komputer osobisty w sklepie. Później, z których przycisków i formularzy skorzysta, aby dokonać zakupu. Użytkowników obserwują badacze – najczęściej projektanci prototypu lub psychologowie. Ich celem jest wyłapanie momentów frustracji, zagubienia lub niezrozumienia. Czasami testy są nagrywane na wideo w celu późniejszej analizy.

Przeprowadzenie badań na grupie 3 – 5 osób pozwala zazwyczaj na wyłapanie ponad 80% błędów.

Błędy ergonomii w przypadku e-commerce wpływają bezpośrednio na obniżenie współczynnika konwersji (konwersja  określa, jaki procent odwiedzających sklep dokonuje zakupów). Obecnie wartość użyteczności jest powszechnie doceniana. Testy interfejsu użytkownika to podstawowe narzędzie do poprawiania wrażeń użytkownika.

Testy funkcjonalne, testy podstawowych scenariuszy i ścieżek

Obecnie Internet przeglądać można prawie na każdym urządzeniu wyposażonym w wyświetlacz. Od klasycznych komputerów stacjonarnych poprzez telefony komórkowe, aż po popularne ostatnio „inteligentne” zegarki.

Każde z takich urządzeń dysponuje innym oprogramowaniem (Windows, MAC OS, Android , Windows Phone, dedykowane oprogramowanie), rozdzielczością wyświetlacza czy typem i wersją przeglądarki internetowej.  Aby wiedzieć jak zachowuje się Nasza aplikacja na tych urządzeniach powinniśmy posiadać przynajmniej po jednym urządzeniu z danej klasy. Jednak utrzymanie i zakup takich urządzeń to spory koszt. Dlatego taniej i wygodniej jest używać emulatorów tych urządzeń. Dla innych systemów operacyjnych może być to pakiet do wirtualizacji (VM Player, Virtual Box), dla przeglądarek i ich różnych konfiguracji (wersja, typ, system operacyjny) browserstack.com a dla urządzeń mobilnych SDK dostarczone od producenta oprogramowania (np. Android SDK). Nie należy jednak zapominać o potrzebie testów na „prawdziwym” sprzęcie. Jeżeli nie na wszystkich kombinacjach to przynajmniej na reprezentatywnych dla danej grupy urządzeń egzemplarzach.

Po zakończeniu wdrożenia, na podstawie projektu aplikacji powinna zostać stworzona lista scenariuszy testowych.

Scenariusze obejmują wszystkie ścieżki funkcjonalne aplikacji, które może przejść użytkownik w czasie normalnego korzystania z systemu. Testy funkcjonalne to podstawowe narzędzie do sprawdzenia czy oprogramowanie działa prawidłowo. Ich wykonywanie polega na „przeklikiwaniu się” przez kolejne kroki scenariuszy.

Warto zainwestować w stworzenie odpowiednio szczegółowych scenariuszy testowych. Nie tylko ułatwią odbiór aplikacji – wskazując również, jakie zachowania systemu są prawidłowe a jakie nie. Scenariusze stworzone w ramach testów akceptacyjnych (testy przy odbiorze systemu), będą miały zastosowanie podczas całego cyklu utrzymania aplikacji.

Testy regresyjne i testy dymne (smoke tests)

Po wprowadzaniu nowych funkcjonalności, optymalizacji obecnych powinny zostać przeprowadzone przeprowadzane tzw. testy regresyjne. Ich wyniki wskazują, czy po zmianie wszystkie podstawowe funkcje nadal działają prawidłowo. Musimy wiedzieć, czy wprowadzane modyfikacje nie zakłóciły działania pozostałych elementów aplikacji. Testy regresyjne mogą być prowadzone na podstawie scenariuszy testowych wykorzystywanych do testów funkcjonalnych.

Korzystanie z testów powinno odbywać się przed wprowadzeniem zmian na serwer produkcyjny oraz zaraz po nim w celu dodatkowej weryfikacji. Dzięki usystematyzowaniu tego co jest testowane, mamy pewność, że nie pominęliśmy niczego ważnego.

Testy integracyjne

Integracje z systemami zewnętrznymi to ten element wdrożenia, który jest najbardziej narażony na błędy, trwa najdłużej i często jest też najtrudniejszy.

Oprócz wyzwań technologicznych, które często nie są przesadnie duże, dochodzą problemy komunikacyjne i konieczność współpracy firm odpowiedzialnych za integrowane składniki. W praktyce połączenia między systemami często podlegają awariom — chociażby sieciowym. W ramach testów funkcjonalnych  powinny zostać przetestowane wszystkie ścieżki komunikacji z systemami – np. z systemem ERP (z ang. Enterprise Resource Planning – system zarządzania przedsiębiorstwem).

W najprostszym wydaniu testy integracyjne polegają na sprawdzeniu czy po złożeniu zamówienia – trafia ono do programu księgowego, czy z systemu magazynowego przekazywane są poprawnie wartości stanów magazynowych itd.

W ramach monitoringu aplikacji, powinna być sprawdzana łączność z systemami. Warto wykonywać automatyczne testy integracji.

Najważniejsze to wykryć błąd przed użytkownikiem. Integracje są zazwyczaj opisane dokładnie w dokumencie analitycznym, który powstał w trakcie projektowania systemu. Dokument analityczny powinien być podstawą do napisania integracji.

Twoja strona wymaga testowania? Chętnie pomożemy! Napisz do nas.