Testowanie oprogramowania: Co musisz wiedzieć?

Testowanie oprogramowania to nieodłączny proces w branży eCommerce i powinieneś być jak najlepiej przygotowany do tego etapu w Twoich projektach. Nie jest to prosta procedura i różni się w zależności od specyfikacji wdrożenia. Ma wpływ na sprawność przeprowadzania tworzenia stron i aplikacji eCommerce’owych. Efektywne testy mogą zdecydować o sukcesie Twojego projektu w dostarczaniu stabilnego i bezbłędnego User Experience.

Jednak zanim będziesz mógł się upewnić, że zespół testerów współpracujący przy tworzeniu Twojego sklepu internetowego wykonuje swoją pracę prawidłowo, musisz zrozumieć jak etap testowania oprogramowania wpisuje się w cały proces wdrożeń e-commerce. Jeśli zatem jesteś właścicielem sklepu internetowego lub testerem software house’u, powinieneś zapoznać się z tym artykułem. Powiemy Ci m.in: 

• jak powinna wyglądać komunikacja między software housem a klientem?
• jak wygląda charakterystyka testów przeprowadzanych w branży eCommerce?
• jakie są różnice w testowaniu odmiennych rodzajów aplikacji?
• czy gotowy sklep internetowy może zawierać błędy?

Testowanie oprogramowania eCommerce – komunikacja z klientem

Jednym z aspektów, które należy zaadresować jak najwcześniej, jest komunikacja z klientem w sprawie testów strony. Jak zwykle w kontaktach nie tyle biznesowych, ale po prostu ludzkich, dochodzi tu do różnic w opiniach i nieporozumień. Warto wiedzieć na jakie obszary klienci i testerzy patrzą ze swojej perspektywy, aby uniknąć niedokładnego planowania testów oprogramowania.

Ocena ważności testów

Jedną z największych różnic pomiędzy postrzeganiem zagadnienia testów między testerami, a klientem jest ta w priorytetyzowaniu zgłoszeń. Za krytyczny błąd co innego uzna tester, a co innego klient. Jest to oczywiście w pełni zrozumiałe, gdyż dla klienta najczęściej najważniejsze będą błędy w warstwie graficznej, która jest najbardziej widoczna. Z kolei tester posiadający wiedzę, której klientowi może brakować, wie, że taki błąd może zostać łatwo usunięty.

Z drugiej strony dużo poważniej potraktuje nieprawidłowości związane z funkcjonowaniem ścieżki zakupowej strony internetowej. Dla przykładu tester na pewno za krytyczne uznałby brak możliwości dodania produktu do koszyka, czy brak oferty produktowej (listingu). Takiego rodzaju błędy zagrażają całemu procesowi Customer Journey.

Bardzo ważnym jest zatem, abyś jako klient rozumiał rzeczywistą wagę pojawiających się błędów i był zapoznany z workflow projektowania aplikacji. Wtedy będzie on w stanie lepiej nadawać odpowiednie priorytety poszczególnym zadaniom. Będzie wiedział, czy ważniejszym jest np. dodanie nowej funkcjonalności do aplikacji, czy naprawienie pojawiającego się błędu. Dzięki temu procesy testowania oprogramowania i developmentu zostaną przeprowadzone w płynny sposób.

Ocena efektywności testowania oprogramowania

Do różnic w zdaniach i problemów w komunikacji dotyczących przeprowadzonych testów dochodzi także w kwestii ich efektywności. Jeżeli dany obszar aplikacji został sprawdzony przez testerów i nie znaleźli oni błędów, może to być spowodowane kilkoma rzeczami:

• rzeczywistym brakiem błędów,
• zbyt krótkim czasem poświęconym na testowanie,
• brakiem uwzględnienia oczekiwań klienta w specyfikacji technicznej.

Częstym problemem w pracy między klientem a zespołem testerów jest mylne założenie, iż brak zgłaszanych błędów oznacza brak wykonywania testów.

Źródłem nieporozumień może być także sytuacja, gdy efektywność testów spadła przez nieodpowiednią ilość czasu dobraną do wykonania zadań. Jeśli po szybkich testach klient własnoręcznie odkryje niezgłoszony wcześniej błąd, nie musi to świadczyć koniecznie o braku kompetencji testerów. Jeśli niepoprawnie rozplanowany zostanie czas na testowanie oprogramowania, ucierpi na tym nie tylko jakość aplikacji, ale także budżet przeznaczony na proces developmentu. Zamiast poszukiwania winnych, warto upewnić się, że testerzy mają zapewnioną odpowiednią ilość godzin do sprawdzenia danych obszarów projektu.

Kardynalnym błędem w komunikacji na poziomie wstępnej analizy jest brak uwzględnienia wymagań klienta w specyfikacji. Bez jasno określonych funkcji, których klient oczekuje w ukończonej aplikacji, testerzy nie będą w stanie przeprowadzić efektywnych testów. Jeśli nie będą wiedzieli jak coś ma działać docelowo, nie będą mogli stwierdzić, że działa niepoprawnie.

Jak usunąć problemy w kontaktach z klientem omawiając proces testowania oprogramowania?

Najważniejszą rolą w ominięciu niezrozumień pomiędzy zespołem testerskim i klientem jest jasność w komunikacji i planowaniu procesów zapewnieniu jakości. Obie strony muszą określić:

• pełną listę funkcjonalności aplikacji,
• czas przeznaczony na wszystkie procesy developmentu (w szczególności okresów testowania),
• czas potrzebny do przetestowania obszarów projektu,
• zasoby dostępne do wykonania zadań testowych,
• liczbę regularnych spotkań catch-upowych,
• charakterystykę prac testowych,
• specyfikę technologii użytych do developmentu projektu (możliwości i ograniczenia technologiczne).

Jakiekolwiek zastrzeżenia lub odstępstwa od uzgodnionych norm również powinny być omówione i ujęte w planie pracy. Dzięki temu i ciągłej komunikacji, zarówno klient jak i zespół developerski będą wiedzieli czego dokładnie spodziewać się od projektu. Takie zabezpieczenia przygotowują również na sytuację pojawienia się komplikacji.

Podział testów

To jakie testy będą wykonywane, zależy w dużej mierze od poziomu umiejętności testerów i od charakterystyki rozwijanego projektu. Sam fakt istnienia wielu rodzajów i typów testowania oprogramowania w branży eCommerce nie oznacza, że każda strona lub aplikacja będzie wymagała użycia wszystkich odmian. Musisz również pamiętać, że nie można jednocześnie stwierdzić, iż jakieś testy są lepsze od innych – wszystko zależy od specyfiki działania projektów. Różne rodzaje testów się przenikają i nie można zrezygnować z jednego rodzaju, tylko dlatego, że wykonało się inny typ. Poniżej przedstawiliśmy podział typów testowania ze względu na rodzaj, poziom i typ.

Rodzaje testów

Najszerszym podziałem testów jest zróżnicowanie ich na testy ręczne (manualne) i automatyczne. Testy automatyczne są najbardziej opłacalne przy testach regresyjnych, czyli takich, gdzie testowane są wielokrotnie te same funkcje, a procedura testów nie ulega zmianom. Wtedy aby zaoszczędzić czas można po prostu napisać test automatyczny, który wykona te monotonne i powtarzalne działania za testera.

Skoro mamy możliwość napisania procedur testujących, które samodzielnie wykonywałyby pracę testowe, bez kosztów utrzymywania specjalistów, dlaczego nie miałbyś aplikować tego rodzaju testowania do wszystkich obszarów? Testy automatyczne nie są efektywne przy sprawdzaniu działania nowych funkcjonalności, przy których tester automatyzujący musi wykonać czynności manualne i poznać ich specyfikę. Dodatkowo nie jest wskazanym wykonywać testy automatyczne, gdy projektowany produkt nie jest jeszcze stabilny. Nie ma sensu w pośpiesznym wykonywaniu testów automatycznych, jeśli nasz projekt eCommerce nie posiada wszystkich zaplanowanych funkcji, które mają być sprawdzone. Zatem, do momentu finalizacji produkcji należy przeprowadzać testy manualne. 

Poziomowanie testowania

Testy jednostkowe – wykonywane na najniższym poziomie aplikacji, czyli kodzie oprogramowania. Ten poziom testowania jest wykonywany przez samych programistów pracujących nad kodem aplikacji lub strony. Polegają na testowaniu poszczególnych metod funkcji i klas. Priorytetem jest tu jak największe procentowe pokrycie kodu źródłowego przez testy jednostkowe. Im większe jest ich pokrycie, tym wcześniej programiści mogą wykryć błędy. 

Testy integracyjne – podczas tych testów sprawdzane są zmiany wykonywane na dwóch różnych modułach aplikacji, które mogą działać zależnie lub niezależnie od siebie. Do zadań testera w tym sposobie testowania oprogramowania eCommerce należy sprawdzenie, czy zmiana w jednym module nie poniosła za sobą niepożądanych skutków w funkcjonowaniu drugiego. W skrócie, testy integracyjne sprawdzają funkcjonowanie aplikacji jako całości i testowaniu czy wprowadzenie zmian w jednym obszarze nie zaburzy działania w innych.

Testy end-to-end – testy te symulują zachowanie prawdziwego użytkownika i sprawdzają, czy przy działaniach użytkownika wszystkie funkcje pracują zgodnie ze specyfikacją projektową. Dobrym nawykiem przy wykonywaniu tego typu testów oprogramowania jest przygotowanie scenariuszy działań użytkownika pomagające kontrolować obszary które zostały już poddane sprawdzeniu, określać liczbę wymaganych poprawek, jak i również zaznaczać obszary jeszcze niesprawdzone.

Testy akceptacyjne – teoretycznie są to proste testy. Chodzi w nich o to, czy skończony produkt spełnia warunki podane w specyfikacji projektowej sporządzonej na początku planowania całego projektu. Można powiedzieć, że ten rodzaj testów wykonuje zespół deweloperów zespół z klientem, który sprawdza czy zostały spełnione jego oczekiwania techniczne i biznesowe.

Typy testowania oprogramowania

Testy funkcjonalne – są wykonywane w celu sprawdzenia, czy aplikacja spełnia biznesowe wymagania dotyczące kluczowych funkcji. Poprawnie przeprowadzony test funkcjonalny powinien zakończyć się uzyskaniem wartości z bazy danych określonej w specyfikacji projektowej. Podobnie jak testy integracyjne, odmiana funkcjonalna testuje wiele obszarów i modułów aplikacji. 

Testy wydajności – ich celem jest sprawdzenie jak wydajna jest aplikacja. Podczas tych testów testerzy określają stabilność i osiągi produktu, np. czas potrzebny do przetworzenia wysokiej liczby zapytań. Testy te przydatne są szczególnie wtedy, gdy po aktualizacji aplikacji potrzebne jest sprawdzenie możliwych spowolnień w działaniu.

Testy dymne – wykonywane są przy wdrożeniu aplikacje na nowe środowisko. Są szybkie w realizacji i za zadanie mają sprawdzenie działania podstawowych funkcji i poprawność działania aplikacji. Wykorzystuje się je przy wprowadzeniu kolejnych części kodu i przed przystąpieniem do bardziej zaawansowanych testów.

Testy eksploracyjne – są to testy manualne, których celem jest wykrycie błędów nieszablonowych, czyli takich, których wykrycie za pomocą testów zautomatyzowanych by się nie powiodło. Jej przebieg powinien być z góry określony, np. testerzy powinni poświęcić na ten typ testowania określoną ilość czasu i przetestować tylko jasno sprecyzowany zakres funkcji. 

Obszary największego zagrożenia

Ze względu na specyfikę i cel aplikacji eCommerce’owej, która ma umożliwić kupno produktu przez użytkownika, największe zagrożenie dla poprawnego funkcjonowania kryje się w ścieżce zakupowej. Dobrą praktyką dla testera będzie stworzenie listy funkcjonalności, których poprawne działanie jest krytyczne z punktu widzenia tego zadania. Składają się na nią takie funkcje jak: dodawanie przedmiotów do koszyka, wyświetlanie listingów i możliwość zapłaty. Ważnym jest, iż przy dodawaniu zmian, czy aktualizowaniu aplikacji w zupełnie innym obszarze trzeba też przeprowadzić testy integracyjne. Ich zadaniem jest sprawdzenie, czy zmiany te nie odbiły się na funkcjonalności ścieżki zakupowej.

Różnice w podejściu do testowania odmiennych oprogramowań w branży eCommerce

Oprócz różnorodności metod testowania, proces sprawdzania jakości i usuwania błędów w branży eCommerce zależny jest też od tego w jakiej technologii ma być tworzona Twoja aplikacja. W handlu elektronicznym najczęstszymi odmianami są aplikacje natywne (stworzone z myślą o konkretnym systemie operacyjnym) i aplikacje progresywne (zwane też aplikacjami webowymi, które wykorzystują przeglądarki urządzeń w celu ominięcia różnic systemowych). Ze względu na inne przeznaczenie i odmienny proces developmentu wymagają one także różnego podejścia i technik w zakresie testowania oprogramowania.

Testowanie natywnych aplikacji

Pierwszą rzeczą, na jaką powinieneś zwrócić uwagę przy procesie testowania aplikacji natywnych jest podział urządzeń i platformy systemowe, na które są projektowane. Testowanie będzie przebiegało odmiennie na smartfonie, a inaczej na tablecie. Testowanie oprogramowania dla aplikacji natywnych powinno się opierać o weryfikację procesu ich instalacji. Oznacza to, że w ramach testów należy zainstalować projektowaną aplikację na dane urządzenie. Trzeba zadbać, aby testy odbyły się na każdej z docelowych platform. Wiążę się to z wymogiem posiadania jednostek testowych (smartfonów, tabletów, itp).

Alternatywą jest użycie emulatora testowego, który symuluje pracę mobilnego urządzenia. Jednak oszczędzanie środków w tym przypadku, może odnieść odwrotne wyniki, gdyż emulatory tego typu nie wykrywają wszystkich błędów. Zalecane jest testowanie oprogramowania na prawdziwych urządzeniach, ze względu na łatwość replikacji wykrytych błędów. Dodatkowymi zaletami testów na rzeczywistych platformach jest wyższa dokładność i uwzględnienie większej ilości zmiennych (rozładowującej się baterii, powiadomienia push, geolokalizacji).

Im więcej modeli urządzeń mobilnych masz dostępnych, tym dokładniejsze testy aplikacji jesteś w stanie przeprowadzić. Obowiązkowym minimum przy testowaniu aplikacji natywnych powinny być urządzenia z systemami Android i iOS. Tylko wtedy Ty i Twoi testerzy będziecie w stanie wykryć błędy dla obu platform systemowych.

Testowanie aplikacji PWA

Podstawowym podejściem do testowania oprogramowań progresywnych jest weryfikacja reguł, które dana aplikacja musi spełniać.

• responsywność,
• progresywność,
• działanie w trybie offline,
• „instalowalność’ i „linkowalność„

Jedną z takich zasad jest responsywność, która wymaga od testującego dopilnowania prawidłowego skalowania strony do rozdzielczości na różne urządzenia. Uruchomiona aplikacja powinna zachować elementy wymagane do prawidłowego funkcjonowania ścieżki zakupowej zarówno na mniejszych urządzeniach mobilnych, jak i na desktopowych.

Kolejną z reguł, która musi została spełniona przy testowaniu, jest progresywność. Testerzy muszą się upewnić, że niezależnie od tego, z jakiej przeglądarki i urządzenia korzystać będą użytkownicy, aplikacja nadal działa zgodnie z założeniami projektowymi. Dodatkowo należy sprawdzić, czy aplikacja będzie działała w trybie offline, czy będzie można ją „zainstalować” na urządzeniach mobilnych. Chodzi o możliwość dodania strony webowej w formie ikony aplikacji na ekran menu smartfona, czy tabletu. To samo dotyczy tzw. „linkowalności„, czyli możliwości udostępnienia treści za pomocą adresu URL. 

Pomocnym narzędziem przy testowaniu aplikacji PWA jest wtyczka Lighthouse, która oferuje analizę strony i debugging pod kątem progresywności.

Testowanie obszaru frontendowego

Odmiennym podejściem cechuje się również testowanie frontendu i backendu przygotowywanych aplikacji. Testując część frontową oprogramowania eCommerce, upewnij się, że testerzy są wyczuleni na błędy pojawiające się w warstwie wizualnej aplikacji. W jej skład wchodzi interfejs, wyświetlane elementy, zdjęcia, miniatury i tekst. Pomocnym w tym procesie jest próba wcielenia się w klienta końcowego, czyli po prostu odbiorcę naszej aplikacji. W ten sposób łatwiej będzie nam sprawdzić, czy jej funkcjonalność i dostępność jest zgodna ze specyfikacją projektową i personą użytkownika.

Raportowanie błędów frontendowych należy do prostszych procesów. Dzieje się tak przez charakterystykę testów i strefę ich przeprowadzania. Błędy frontendowe dotyczą części wizualnego interfejsu aplikacji. Dzięki temu w raportach testerzy mogą zawierać elementy o lokalizacji i charakterystyce błędów. Świetnie w tym spiszą się takie elementy jak screenshoty, czy filmiki ukazujące sytuację triggerujące błędy. 

Testowanie obszaru backendowego

Testowanie oprogramowania w sferze backendowej może być trudniejsze, ze względu na to, że błędy nie kryją się w widocznej części interfejsu graficznego. Podczas testowania backendu, testerzy sprawdzają część serwerową i przesyłają zapytań pomiędzy klientem i bazą danych. Bardzo wartościowymi umiejętnościami przy tym typie testowania oprogramowania jest znajomość kodów HTTP i sprawne poruszanie się w narzędziu Network. Dzięki tym dwóm, Ty i Twoi testerzy będziecie mieli wgląd w działanie backendu i mogli sprawnie określić pochodzenie błędów. Dodatkowym plusem jest znajomość SQl-a i wtyczki Postman API do testowania API. 

Czy opłaca się wypuszczać produkt z błędami?

Wielu klientów decyduje się na przedterminowe wypuszczenie projektu na produkcję nawet jeśli zawiera on niepoprawione błędy. Umowy typu SLA chronią sprzedawcę przed złym jakościowo produktem i umożliwiają zaplanowanie poprodukcyjne wprowadzanie nowych poprawionych wersji oprogramowania, np. co dwa tygodnie. Czemu warto zdecydować się na takie rozwiązanie?

Otóż, gdy zgłoszone nieprawidłowości nie mają priorytetu krytycznego, nie będą uniemożliwiać prawidłowego działania witalnych funkcji eCommerce’u. W ten sposób produkt może wcześniej zacząć przynosić pierwsze zyski, a testerzy nadal mogą wprowadzać poprawki.

Czy jednak wprowadzanie poprawek nie sprawi, że użytkownicy nie będą mogli korzystać normalnie z finalnego produktu? Ten problem najczęściej rozwiązuje się poprzez przeprowadzanie prac nad błędami w okresach najmniejszej aktywności, np. między 22 a 7 rano. Dzięki temu nie zakłócasz działania strony internetowej/aplikacji i nadal jesteś w stanie zadbać o usunięcie błędów.

Ale co jeżeli na produkcję wkrada nam się błąd krytyczny? W tym wypadku zespół deweloperski działa natychmiastowo i opracowuje rozwiązanie w postaci hotfixa, testuje się go i wprowadza do oprogramowania.

Jak widzisz procedura testowania oprogramowania eCommerce jest przesycona skomplikowanymi treściami, do których w każdym wdrożeniu należy podchodzić inaczej. Bardzo ważną kwestią jest przygotowanie planu procesu testowania, a także wymagań funkcjonalnych. Wszystkie potrzebne informacje powinny znaleźć się w specyfikacji projektowej, do której dostęp należy udostępnić zespołowi testerskiemu, deweloperom i klientowi. Powinieneś również zapoznać się wcześniej z ogólną charakterystyką procedur testowania dla Twojego rodzaju aplikacji. Zaplanuj również lub dowiedz się (jeśli jesteś testerem), czy plan projektu zakłada wypuszczenie aplikacji na produkcję w wersji MVP, czy później, gdy zespół usunie większość błędów. Uzbrojony w te informacje, będziesz lepiej przygotowany do pracy nad projektem eCommerce.