W tym artykule odpowiem na pytanie: dlaczego wdrożenia realizowane przez agencje ecommerce często zawierają błędy, a klient czuje się jak tester pracujący bezpłatnie na rzecz agencji?
Dlaczego to co wdraża Ci agencja ecommerce ma bardzo dużo błędów?
Historia ecommerce’u z branży RTV&AGD
Symptomy tego, że coś jest nie tak z jakością pracy agencji ecommerce
Jakie są skutki współpracy z software house, który generuje ogromną ilość błędów w pracach kodowych?
Dlaczego prace realizowane przez software house mają masę błędów?
Jak powinien wyglądać poprawny proces testowania (Quality Assurance)?
Co to są procesy krytyczne?
Co powinno zadziać się po uruchomieniu produkcyjnym?
Na co zwrócić uwagę podczas rozmowy z software house’em lub agencją ecommerce?
Co zrobić w sytuacji gdy to co wdraża Ci agencja ecommerce ma masę błędów?
Podsumowanie
Dlaczego to co wdraża Ci agencja ecommerce ma bardzo dużo błędów?
Prawdopodobnie agencja ecommerce, z którą współpracujesz, nie ma wypracowanych procesów testowania. Pewnie nie zatrudnia testerów, a zadania związane ze sprawdzaniem funkcjonalności kodowanych przez programistów realizowane są przez koordynatora projektu.
Co zatem powinieneś zrobić w takiej sytuacji? Rozważ wymianę agencji ecommerce na taką, która ma wypracowane procesy testowania. Jest to rozwiązanie ostateczne, ale nie wyobrażam sobie, żebyś jako Klienta miał czekać na poprawę jakości współpracy do czasu wypracowania po stronie agencji odpowiednich procesów. Jeśli natomiast chodzi o Twój sklep internetowy, powinieneś przeprowadzić audyt i wykonać testy manualne wszystkich krytycznych procesów. Następnie agencja powinna napisać testy automatyczne dla tych procesów, aby móc szybko reagować, kiedy pojawi się jakiś duży błąd.
Historia ecommerce’u z branży RTV&AGD
Na jednym z ostatnich spotkań z dyrektorem ecommerce, z wyjątkowo konkurencyjnej branży RTV&AGD, przyznał, że ma poważne problemy z obecną agencją ecommerce.
Niezależnie od działania agencji, każde zrealizowane przez nią zadanie jest pełne błędów.
Postanowiłem zgłębić ten temat. Zadałem kilka dodatkowych pytań, aby lepiej zrozumieć problem.
Na samym początku zapytałem, jak wygląda podział godzin w raportach miesięcznych, które dostarcza mu agencja ecommerce. Ile godzin jest opisanych jako naprawa błędów, bug fixing, a ile godzin jest przeznaczanych na rozwój? Okazało się, że ecommerce przeznacza 160 godzin miesięcznie na prace programistyczne realizowane przez agencją ecommerce. Z tej puli, aż 90 godzin jest przeznaczana na naprawę błędów. Pozostałe 70 godzin jest wykorzystywana na tematy rozwojowe. Mamy tu więc nieco dziwny podział: 90 godzin na naprawianie błędów, 70 godzin na rozwój.
Podczas rozmowy zapytałem również o user stories (storki) i kryteria akceptacyjne. Na samym początku Rafał (dyrektor e-commerce) nie był pewien, co to jest, więc wyjaśniłem mu, że “storki” i kryteria akceptacyjne opisują daną funkcjonalność ecommerce’u. Zazwyczaj są one przygotowywane na etapie analizy przedwdrożeniowej (nazywanej także fazą discovery), która poprzedza kodowanie wykonywane przez programistów.
Chodzi o to żeby funkcjonalność nie była opisana w sposób ogólnikowy i żeby wszystkie strony wiedziały jak dokładnie to ma działać. Te wszystkie założenia powinny być opisane jako kryteria akceptacyjne. Kiedy wszyscy zaangażowani w projekt mają jasno określone wyobrażenie o funkcjonalności, proces jest znacznie prostszy. Dodatkowo bez wyraźnie określonych kryteriów akceptacyjnych, testowanie serwisu jest niemożliwe. Nie ma bowiem jasnych wytycznych, według których należy przetestować daną funkcjonalność. Przychodzi mi do głowy taki przykład, że ktoś mówi, że samochód “jedzie szybko”, dla jednego to będzie 50 km/h, a ktoś inny wyobraża sobie samochód pędzący 140 km/h. Chodzi właśnie o to, żeby opisując jak ma działać dana część systemu ecommerce nie posługiwać się takimi subiektywnymi kryteriami. Lepiej jest po prost opisać, samochód ma poruszać się szybko, a więc z prędkością nie mniejszą niż 120 km/h.
💡 Przeczytaj nasz artykuł o tym jak przeprowadzić skuteczną analizę biznesową przed wdrożeniem Magento!
Wróćmy do Rafała. Zapytałem go, ile czasu tygodniowo poświęca na testowanie i opisywanie błędów dla swojej agencji ecommerce. Byłem zaskoczony, gdy dowiedziałem się, że to od 8 do 12 godzin! Jest to od jednego do półtora dnia tygodniowo na testowanie zadań software house’u, opisywanie błędów i komunikację z zespołem tego partnera. Sporo.
Symptomy tego, że coś jest nie tak z jakością pracy agencji ecommerce
Zacznijmy od zrozumienia, jakie objawy w sytuacji Rafała wskazywały, że jakość pracy agencji ecommerce mogłaby być lepsza.
Duża ilość błędów
Software house dostarczał funkcjonalność, a po jej szybkim przetestowaniu okazywało się, że ta nie działa prawidłowo. Krótko i na temat.
Po poprawieniu jednego błędu, pojawia się nowy
Drugim symptomem było to, że jedna rzecz była poprawiona, a inna nagle przestawała działać. Przykładowo, po wdrożeniu możliwości składania zamówienia jako gość (bez konieczności rejestracji), nagle okazywało się, że nie można zalogować się do już utworzonego konta. Choć te dwie funkcje nie były ze sobą powiązane, w jakiś sposób wprowadzenie jednej wpływało na działanie drugiej.
Pojawiające się błędy po uruchomieniu produkcyjnym
Podczas wdrażania sklepu internetowego nie było dużo błędów. Problem zaczął się po uruchomieniu serwisu. Gdy strona została udostępniona klientom końcowym, pojawiło się mnóstwo błędów.
Więcej godzin zajmuje utrzymanie niż na rozwój
Kolejnym istotnym aspektem jest budżet przeznaczany na naprawę błędów. W przypadku Rafał grubo ponad 50% godzin pracy zajmuje naprawianie błędów i łatanie dziur.
Jakie są skutki współpracy z software house, który generuje ogromną ilość błędów w pracach kodowych?
Jeśli współpraca z agencją ecommerce wygląda w ten sposób, można spodziewać się kilku nieprzewidzianych konsekwencji.
Przede wszystkim, traci się dużo czasu. Od 8 do 12 godzin tygodniowo na sprawdzanie, dokumentowanie błędów, opisywanie i komunikację to naprawdę dużo. Za te godziny nie płacicie agencji ecommerce, ale są to koszty, które Twój zespół (albo Ty) ponosicie.
Druga kwestia to utrata przychodu. Jeśli kluczowa funkcjonalność ecommerce (przykładowo nie można wybrać formy dostawy) zawodzi w sposób przypadkowy, może to uniemożliwić niektórym klientom składanie zamówień.
Błędy wydłużają też czas wdrażania nowych funkcjonalności do ecommerce. Przykładowo, funkcjonalność nowego prezentowania obniżek (na której zależało nam przed Black Friday) agencja ecommerce przekazuje do testów 28/10. Po 5 minutach testowania wiecie już, że nie działa ona poprawnie. Teraz musicie dokładnie opisać błędy, wysłać wiadomość do agencji. Ta musi przeanalizować błąd, naprawić i ponownie oddać do Waszych testów. Pewnie okaże się, że nie wyrobicie się z tą funkcjonalnością na czas.
Dlaczego prace realizowane przez software house mają masę błędów?
Software house, z którym współpracujesz, dostarcza funkcjonalności zawierające wiele błędów z kilku głównych powodów.
Brak testera w zespole projektowym
Pierwszym powodem jest brak testera w projekcie lub zespole projektowym pracującym dla Ciebie po stronie agencji ecommerce (alternatywnie jest jeden tester na zespół 20 programistów). W wielu agencjach, tester jest często uważany za zbędną pozycję w budżecie. W końcu na etapie oferty jest to tylko linia kosztowa, która sprawia, że oferta danej agencji jest o kilkanaście / kilkadziesiąt procent droższa. Zamiast testera to koordynator projektu próbuje sprawdzać to, co programiści przekazują mu testowania.
Musi to zrobić pomiędzy zarządzaniem projektem, zarządzaniem zespołem projektowym i komunikacją z Tobą oraz innymi klientami. To jest niemożliwe do zrealizowania. Koordynator projektu często nie ma też kompetencji oraz procesów do testowania i nie zna narzędzi, które przyspieszają proces testowania.
Budżet przeznaczony na testowanie jest za mały
Drugi powód, dla którego twoje projekty mogą zawierać wiele błędów, to niewystarczający budżet przeznaczony na testowanie. Jeżeli na przykład zarezerwujesz 160 godzin pracy programisty na każdy miesiąc, powinieneś przeznaczyć co najmniej 20% tego czasu na testy.
20% to absolutne minimum. W ciągu tych 20% tester jest w stanie przetestować działanie funkcjonalności na jednej przeglądarce i na dwóch rozdzielczościach: mobile i desktop.
Jeżeli w Twoim budżecie albo ofercie widnieje, że na testowanie przeznaczasz miesięcznie około 5% czasu programisty lub agencja ecommerce w ogólnie nie przeznacza na to czasu, oznacza to, że przy Twoim projekcie nie pracuje tester.
Dodatkowo, jeśli chcesz pokryć większą liczbę technologii i rozdzielczości testami, powinieneś przeznaczyć na to więcej czasu. Jeżeli wydaje Ci się, że to dużo to warto zestawić to z kosztami: naprawiania błędów + koszt Twojego czas + utrata przychodu.
Brak user stories (storek) i kryteriów akceptacyjnych
Ostatni punkt dotyczy “źródła” błędów. Wiele z nich wynika z braku user stories (storek) i kryteriów akceptacyjnych opisujących funkcjonalności. Jeśli po fazie przedwdrożeniowej i analizie, nie otrzymałeś dokładnych storek i kryteriów akceptacyjnych, oznacza to, że w Twoim projekcie prawdopodobnie nie będzie testera. Tester nie ma bowiem kryteriów, według których powinien testować sklep internetowy lub daną funkcjonalność.
Jeżeli masz wątpliwości, czy dokumentacja, którą otrzymałeś po etapie przedwdrożeniowym jest wystarczają to po prostu napisz do nas i podpowiemy, czy to co masz jest wystarczające, żeby może było na tej postawie realizować prace programistyczne.
Jak powinien wyglądać poprawny proces testowania (Quality Assurance)?
W takim razie zastanówmy się jak powinno to wyglądać by wszystko działało poprawnie.
Code review, testy manualne, testy automatyczne
Na początek chciałbym wprowadzić 3 kluczowe pojęcia: code review, testy manualne i testy automatyczne.
Code review to sprawdzanie kodu napisanego przez jednego programistę przez bardziej doświadczonego programistę. Warto zwrócić uwagę, że code review nie sprawdza, czy dana funkcjonalność widoczna na sklepie internetowym działa zgodnie z pierwotnymi założeniami. Jest to jedynie sprawdzenie struktury kodu i sposobu, w jaki został on napisany.
Następnie mamy testy manualne. To proces, w którym tester manualnie sprawdza, czy kryteria akceptacyjne są spełnione przez stronę internetową. Na przykład, jeżeli jest napisane, że po kliknięciu powinna pojawić się określona strona, że podczas rejestracji powinny być określone pola do uzupełnienia, a walidacja ma działać w określony sposób, tester sprawdza, czy to wszystko tak właśnie działa. Jeżeli tak, to kryterium akceptacyjne jest spełnione. Jeżeli nie – nie jest spełnione. Zadanie musi zostać poprawione (zrealizowane jeszcze raz przez programistę).
Testy automatyczne to w uproszczeniu program / skrypt, który próbuje zrealizować określony proces na sklepie internetowym sprawdzając jego poprawność. Można go zaprogramować tak, aby na przykład dodawał produkt do koszyka, wybierał formę płatności, logował się na konto i dokonywał zakupu. Cały proces odbywa się automatycznie, wystarczy nacisnąć przycisk, aby przetestować cały proces. Największą zaletą jest możliwość napisania testów automatycznych dla najbardziej krytycznych procesów i sprawdzania ich poprawności przykładowo raz na dobę.
Tester w zespole projektowym
W procesie tworzenia projektu ecommerce, zaleca się zaangażowanie testera już na etapie analizy przedwdrożeniowej (fazy discovery). Może wydawać się to niepotrzebne, skoro sklep internetowy jeszcze nie istnieje, ale… usunięcie błędów, które wynikają z błędnych założeń, jest na tym etapie kilkanaście razy tańsze niż jakby to miało miejsce już po zakodowaniu.
Storki i kryteria akceptacyjne
Kiedy mamy już określone kryteria akceptacyjne, a dane zadanie zostało zakodowane przez programistę – na przykład, wyszukiwarka działa już na Waszym sklepie – tester może manualnie sprawdzić tę funkcjonalność.
Sprawdza, czy funkcjonalność działa zgodnie z opisem i czy spełnia kryteria akceptacyjne – to jest najważniejsze. Tester sprawdza to wszystko punkt po punkcie, na wszystkich rozdzielczościach (co najmniej mobile i desktop). Jeżeli coś nie działa poprawnie, funkcjonalność wraca do programisty do poprawienia.
Dopiero po otrzymaniu pozytywnej oceny od testera, funkcjonalność jest przekazywana do Ciebie. Otrzymujesz sprawdzoną, wytestowaną funkcjonalność, w której raczej nie znajdziesz błędów.
Co to są procesy krytyczne?
Około 2 miesiące przed uruchomieniem produkcji serwisu, powinny zostać napisane testy automatyczne do krytycznych procesów, czyli najważniejszych procesów w ecommerce.
Przykładowe 5 takich procesów: logowanie, rejestracja, dodanie produktu do koszyk, przeliczanie cen w koszyku i wartości całego zamówienia oraz złożenie zamówienia.
To są krytyczne procesy, które muszą działać poprawnie. Jeżeli nie będą one funkcjonowały bezbłędnie to poważnie utrudnimy użytkownikom korzystanie z naszej witryny. Warto, aby były do nich napisane testy automatyczne, które codziennie sprawdzałyby, czy wszystko działa poprawnie.
Co powinno zadziać się po uruchomieniu produkcyjnym?
Zbliżamy się do momentu uruchomienia twojego sklepu internetowego. Co dzieje się po tym, jak sklep jest już dostępny dla klientów?
Na tym etapie powinniśmy już posiadać napisane i działające testy automatyczne dla krytycznych procesów.
W przypadku rozwijania sklepu i pojawiania się nowych funkcjonalności, każda z nich powinna być przetestowana przez testera, zanim trafi do Ciebie. Przed przystąpieniem do testów powinny powstać storki oraz kryteria akceptacyjne, aby tester miał jasne wytyczne, jak przetestować daną funkcjonalność i mieć pewność, że spełnia ona Twoje wymagania.
Ważne jest również, aby agencja ecommerce stworzyła kokpit z najważniejszymi parametrami życiowymi strony internetowej. Powinny się tam znaleźć podstawowe metryki z Google Analytics, takie jak współczynnik odrzuceń, współczynnik konwersji, szybkość witryny i czas ładowania. Dzięki temu agencja ecommerce może ustawić ostrzeżenia, czyli tzw. alerty, jeżeli poziom tych metryk niebezpiecznie spada. Sygnalizuje to, że z witryną może dziać się coś niepokojącego.
Na co zwrócić uwagę podczas rozmowy z software house’em lub agencją ecommerce?
Oto jak powinno to wyglądać. Jeżeli prowadzicie rozmowy z agencją ecommerce lub software housem, zapytajcie o ich procesy testowania.
Opiszą one proces, który prawdopodobnie wygląda podobnie do tego, który przedstawiłem w tym artykule. Jeśli jednak ktoś twierdzi, że mają testerów, ale nie ma potrzeby tworzenia dokumentacji związanej z kryteriami akceptacyjnymi, to coś jest nie tak.
Jeżeli proces odbiega znacznie od tego, który opisałem albo osoba, z którą rozmawiacie nie potrafi opisać procesu to powinniście podchodzić do współpracy z dużą ostrożnością.
Co zrobić w sytuacji gdy to co wdraża Ci agencja ecommerce ma masę błędów?
Na koniec, chciałbym podzielić się z Wami planem działań, który wypracowałem Rafałowi (kim jest Rafał? Dyrektorem ecommerce, którego historię opisałem na samym początku).
Zarekomendowałem przeprowadzenie audytu przed rozpoczęciem jakiejkolwiek współpracy. Audyt pozwoli sprawdzić działanie backendu i frontendu, jakość kodu oraz sposób implementacji gotowych modułów.
W zakresie testowania, najważniejsze to przetestowanie manualnie kluczowych (krytycznych) procesów.
Następnie nasz plan zakładał napisanie testów automatycznych dla tych krytycznych procesów. Napisanie 5 testów do procesów krytycznych zajmie około 40-60 godzin.
Ostatni krok to przygotowanie kokpitu, który będzie monitorował kluczowe metryki i parametry witryny. Kokpit będzie również wysyłał automatyczne alerty, gdy coś zacznie działać nieprawidłowo. To pozwoli na szybką reakcję i rozwiązanie problemu, zanim zostanie on zauważony przez użytkowników witryny.
Podsumowując sytuację Rafała: czy możliwe jest usunięcie wszystkich błędów w serwisie, które powstały na etapie wdrożenia? Odpowiedź niestety brzmi NIE.
Błędy mogą być liczne i kosztowne w naprawie, dlatego z niektórymi z nich trzeba będzie żyć. Zaproponowany plan działań doprowadzi do tego, że najważniejsze i najpoważniejsze błędy zostaną usunięte oraz dodatkowo system testów i kokpitów będzie pozwalał na szybką reakcję, jeżeli błędy już się pojawią.
Podsumowanie
Dlaczego to co wdraża Ci agencja ecommerce ma masę błędów? Najczęstszym powodem takich sytuacji jest brak procesów testowania, które mają zapewnić jakość tworzonych przez agencję ecommerce funkcjonalności.
Jakie działania podjąć w takiej sytuacji? Choć może to wydawać się drastycznym rozwiązaniem, najczęściej najlepszym wyjściem jest zmiana agencji ecommerce. Trudno bowiem o konstruktywny i szybkie rozwiązanie problemu. To, od czasu że powiecie agencji “Hej, nie macie procesów testowania i testera. Zmieńcie to.” do faktycznych zmian minie co najmniej 6 miesięcy. Pytanie, czy chcesz tyle czekać.
Zabrzmi jak tania reklama, ale jeżeli w Twoim projekcie mierzysz się z dużą liczbą błędów, w funkcjonalnościach, które kodowane są przez agencję ecommerce to może warto porozmawiać? W trakcie rozmowy zbadalibyśmy na czym dokładnie polega problem i w efekcie wypracowalibyśmy koncepcje rozwiązujące Twoją sytuację.
Jeżeli zależy Ci na kolejnych porcjach wartościowej wiedzy – już teraz zapraszam Cię do śledzenia mojego profilu LinkedIn, na którym regularnie publikuje informacje ze świata Magento i ecommerce developmentu!
