Rzadko zdarza się, aby środowisko mówiło niemal jednym głosem. Zdaje się, że każda osoba zajmująca się na co dzień poprawianiem jakości produktów cyfrowych słyszała kiedyś żart o testowaniu na produkcji. Metoda ta jest powszechnie uważana za kontrowersyjną. Testerzy oprogramowania są zgodni, że aplikacje należy pokryć testami przed wprowadzeniem jej do produkcji. Po zakończeniu testów deweloperzy chcieliby mieć pewność, że oprogramowanie nie zawiera krytycznych błędów i będzie bezawaryjnie działać w środowisku produkcyjnym. Czy zatem testy wykonywane na środowisku, do którego dostęp mają również użytkownicy powinny zostać zastąpione innymi metodami?

 

Testowanie na produkcji – czym jest?

Zła sława testów na produkcji sprawia, że nie poświęca się im tak dużo uwagi na salach wykładowych i konferencjach, jak innym sposobom na poprawę jakości oprogramowania. Dlatego na początku warto odpowiedzieć na pytanie, czym jest testowanie na produkcji. Zdefiniowanie tej metody jest ważne, ponieważ nie brakuje osób, które postrzegają testowanie na produkcji jako nieodpowiedzialne wdrażanie zmian w oprogramowaniu. Takie podejście nie ma nic wspólnego z procesowym podejściem do podnoszenia jakości produktu.

Testowanie na produkcji jest to wykonywanie testów w środowisku, do którego dostęp ma również klient docelowy. W potocznym żargonie „produkcją” nazywamy aplikacje, z których korzystamy na co dzień. Zadaniem testera jest znaleźć błędy w testowanym oprogramowaniu przy wykorzystaniu tej samej platformy co zwykły użytkownik. Wykonywanie testów na ogólnodostępnym środowisku nie wiąże się jednak z zaniedbaniem wcześniejszych etapów testowania. Oznacza to, że testowanie na produkcji nie powinno zastępować wcześniejszych etapów udoskonalania oprogramowania. Takie podejście do testów „na żywym organizmie” sprawia, że działania wykonywane na produkcji są uzupełnieniem procesu podnoszenia jakości, a nie jedynym sposobem na wykrycie błędów.

Należy zatem pamiętać, że testowanie w środowisku produkcyjnym powinno polegać na ciągłym testowaniu aplikacji, z której korzystają użytkownicy. Nie zaś na chaotycznym wprowadzaniu zmian - z nadzieją, że zostaną one dobrze przyjęte przez użytkowników oraz nie wpłyną negatywnie na działanie aplikacji.

Rozdzielność środowisk testowych

Aplikacje do prawidłowego działania potrzebują stabilnego środowiska, które podlega stałej kontroli. Zapewnienie tego jest możliwe poprzez rozdzielenie operacji programistycznych i testowych oraz ograniczenie dostępu do środowisk operacyjnych dla pracowników zajmujących się tworzeniem kodu. Dzięki temu możliwe jest zmniejszenie ryzyka nieumyślnych i nieautoryzowanych modyfikacji, które mogą zagrozić integralności i dostępności systemu.

Standardy i normy testowania wyróżniają następujące środowiska:

  • Lokalne, czyli takie, które programiści mają skonfigurowane na swoim komputerze i gdzie sprawdzają swoje nowo napisane kawałki kodu, lub próbuję zreprodukować to co tester zgłosił.
  • Developerskie, czyli takie, gdzie wszystkie zmiany trafiają od developerów i mogą sprawdzać tam swoje zmiany w połączeniu z kodem pozostałych.
  • Testowe, czyli takie gdzie nowe rzeczy (zmiany, feature) oraz poprawki błędów testują testerzy, tutaj powinien trafiać kod, sprawdzony przez programistów.  Następnie weryfikuje się je przy użyciu testów.
  • Produkcyjne, czyli takie, z którego korzysta nasz klient i wykonuje swoją pracę dzięki naszej aplikacji. To jest środowisko, które powinno już przejść wszelkie testy i procesy zapewniania jakości.

Nie zawsze firmy korzystają z wszystkich z wszystkich wyżej wymienionych środowisk. Powody takiego stanu rzeczy bywają różne.

  • Środowisko produkcyjne może nie istnieć, ponieważ aplikacje jest na wczesnym etapie cyklu życia, co sprawia, że jest projektowanie środowiska produkcyjnego zacznie się dużo później.
  • Czasem na skutek ograniczonego budżetu środowisko deweloperskie jest połączone z testowym.
  • Zdarza się, że  jest jedno środowisko pre-prod/uat, gdzie trafiają gotowe wersje do wgrania na produkcje, ale jeszcze przed ostateczną akceptacją klienta i weryfikacją kluczowych użytkowników.
    Kiedy testowanie na produkcji jest korzystne?

Naturalnie, oprogramowanie powinno zostać przetestowane przed wydaniem na produkcję, pozwoli to uniknąć wielu krytycznych błędów. Istnieją jednak sytuacje, w których nie można dokonać symulacji danego wariantu na środowisku testowym. Bywa też, że przeprowadzenie testów w środowisku produkcyjnym jest korzystniejsze.

Dzieje się tak między innymi wtedy, gdy:

  • Należy sprawdzić zgłoszony przez klienta problem. Czasem znacznie szybciej można coś zweryfikować na środowisku produkcyjnym niż konfigurując specjalnie w tym celu wersję testową. Szczególnie jeśli planowane testy są nieinwazyjne. Przykładem może być niedziałający przycisk lub odnośnik.
  • Planowane jest przeprowadzenie testów dymnych, czyli szybkie wykonanie ”end to end” w celu sprawdzenia czy środowisko działa stabilnie i wykonuje swoje podstawowe zadania. Przykład: sprawdzenie czy aplikacja wciąż działa po wdrożeniu nowej wersji.
  • Trzeba wykonać testy, których wykonanie w każdym innym środowisku jest niemożliwe lub ich wyniki nie będą miarodajne. Przykład: testy wydajności lub bezpieczeństwa.
  • W każdej z opisywanych sytuacji użycie wykonanie testów na produkcji jest uzasadnione. Nie oznacza to, że należy robić tak zawsze i w każdym przypadku. Powyższe sytuacje pokazują, że testowanie na produkcji nie jest nowością. Co więcej, często jest to element procesu, którego celem jest wydanie na rynek stabilnej i funkcjonalnej aplikacji. Należy jednak pamiętać, aby testy na produkcji były zaplanowanym, dopracowanym i odpowiednio wdrożonym działaniem. W ten sposób możliwe będzie nieinwazyjne przeprowadzenie testów.

Dobre praktyki testów na produkcji

Jeśli już musimy coś przetestować na produkcji pamiętajmy o kilku rzeczach:

  • Ostrożność - bardzo ważne jest to by każda z naszych operacji była dobrze przemyślana pod kątem tego co chcemy osiągnąć jak i również potencjalnych konsekwencji. Czasem z pozoru prosta operacja może wywołać ciąg nieoczekiwanych zdarzeń, które mogą wpłynąć na użytkownika lub będą nieodwracalne w 100%.
  • Maksymalne skupienie, tak aby wykonać odpowiednie operacje w odpowiednich miejscach. Nie raz słyszałam o tym, a nawet i mi się zdarzyło pomylić środowisko produkcyjne z testowym i odwrotnie. Dlatego też może warto, jeśli chcemy pracować tylko na produkcji i chcemy mieć pewność, warto wyłączyć wszystkie inne środowiska, by przez przypadek nie odczytywać danych z innego miejsca.
  • Wcześniejsze przygotowanie planu i danych - testy na produkcji powinny odbywać się w jak najkrótszym czasie. W związku z tym warto przygotować wcześniej plan oraz dane, jakie potrzebujemy. To pozwoli nam maksymalnie skrócić czas używania produkcji do testów, jak również pozwoli nam zwizualizować potencjalne niedociągnięcia w naszym planie.
  • Jeśli testy są lub mogą być inwazyjne dla klienta, warto zaplanować je w czasie, kiedy klient nie korzysta z aplikacji/systemu. Zależy nam na tym, aby nasza praca nie ingerowała w codzienne użytkowanie przez użytkownika. Oczywiście zdarzają się takie testy, które trzeba wykonać od razu nie czekając, aż klienta skończy pracę, wtedy zalecana jest podwójna ostrożność, dobry plan oraz komunikacja z użytkownikiem.
  • Starajmy się jak najmniej ingerować w dane. Przykładowo, jeśli konieczne jest stworzenie nowego zamówienia w sklepie internetowym na potrzebny testów, to warto później takie zamówienie usunąć lub anulować, tak abyśmy też nie zaburzali naszymi testami statystyk sprzedażowych lub innych w zależności od aplikacji, nad którą pracujemy.
  • Warto się zastanowić czy nie jest to dobry moment na tzw. pair testing, czyli dwóch testerów będzie testować na jednym komputerze. Pozwala to w przetestowaniu planu działania, wzmaga ostrożność i skupienie. Na pewno wpłynie to pozytywnie na redukcję błędów.
  • Należy informować klienta o naszych działaniach. Nie zawsze jest to możliwe przed testami, natomiast warto przekazać taką informację zaraz po ich wykonaniu. Dlaczego? Jeśli nasze kroki mogą być inwazyjne, klient będzie wiedział, że anomalie mogą być związane z naszymi działaniami. Ponadto budujemy relacje z klientem, pokazując transparentnie jak wyglądają procesy pracy nad aplikacją. Czasem może się okazać, że coś, co wydaje nam się błahe z naszego punktu widzenia może być bardzo istotne dla użytkownika.

Dlaczego firmy testują na produkcji?

Testowanie w środowisku produkcyjnym jest ważną częścią procesu testowego. Użytkownicy mają dostęp do oprogramowania z wielu różnych urządzeń, przeglądarek, wersji przeglądarek i systemów operacyjnych. Często niemożliwe jest przewidzenie i rozwiązanie wszystkich błędów bez rzeczywistego doświadczenia użytkownika, dlatego wykorzystuje się środowisko produkcyjne.

Testowanie na produkcji zapewnia również korzyści deweloperom, pozwalając programistom na lepsze przygotowanie się do radzenia sobie z anomaliami. Gotowość do reagowania na błędy przekłada się zaś na lepsze doświadczenia użytkowników. Z tego powodu wykonywanie testów na produkcji jest istotnym elementem dbania o jakość cyfrowego produktu.

Testowanie na produkcji jest korzystne dla małych firm, dla których stworzenie środowiska testowego będzie niemożliwe ze względu na ograniczone zasoby. Skorzystają na nim również duże marki, które nie są w stanie pokryć wszystkich błędów na innych etapach, bo ich aplikacja jest rozbudowana. Przykładem wielkich brandów, które wykonują testy na produkcji jest między innymi Netlix.

Czasami pojawiają się błędy

Nie brakuje też jednak sytuacji, w których testowanie na produkcji wiązało się z negatywnymi skutkami. Jednym z takich przykładów jest case mBanku. Klienci tego banku dostali enigmatyczne wiadomości ‘push’. Użytkownicy aplikacji otrzymywali wiadomości o treści: ‘test wiadomości push’ lub ‘Życzymy miłego dnia’ czy też ‘ęśąćż’. Wyglądały one tak:

mbank-powiadomienia.png

mbank-twitter.png

/fot. Bartłomiej Godziszewski/Bankier.pl

Zaniepokojeni klienci masowo zaczęli logować się na swoje konta, co doprowadziło do wzmożonego ruchu, przez co z kolei przeciążone serwery przestały odpowiadać. To oczywiście przyczyniło się do jeszcze większej paniki ze strony klientów. Na szczęście bank wyszedł z tej sytuacji obronną ręką – natychmiast poinformował klientów o omyłkowych wiadomościach oraz wystosował prośbę o nielogowanie się do aplikacji. Długo nie trzeba było czekać, aby mbank na swoich kontach społecznościowych dał znać, że sprawa wróciła do normalności. Oczywiście, internet zawrzał od memów na ten temat. I tutaj również bank stanął na wysokości zadania! Nie dość, że od razu przyznał się do błędu, to dodatkowo poinstruował klientów co robić, a na koniec skwitował humorystycznie całą akcje, jak widać na poniższym screenie:

Zaistniała sytuacja jest na pewno tematem na retrospektywę, natomiast sam sposób poradzenia sobie z pomyłką jest rewelacyjny. Otwartość, komunikacja, a do tego nutka humoru.

Pan tu nie stał - błędy w systemie szczepień

Inny sposób radzenia sobie z błędami na produkcji mogliśmy zaobserwować 1 kwietnia 2021, kiedy to ruszyły masowo e-skierowania na szczepienie przeciw Covid-19 dla 40-latków, mimo że według planu jeszcze nie był to czas dla tej grupy. Rano tego dnia rząd zapewniał, że tak dobrze idzie nam proces szczepienia, że zapisy zostały uruchomione wcześniej. Kiedy Polacy masowo ruszyli do zapisywania się na terminy, okazało się, że tak samo, jak w przypadku mBanku system nie wytrzymał obciążenia i serwery po prostu przestały odpowiadać. Logowanie nie było możliwe, przez co nie było szans na zapisanie się na szczepienie. Dodatkowo portal e-pacjenta przestał działał, ale również inne systemy rządowe były niedostępne, choćby serwis służący do spisu powszechnego. Kilka godzin po tym, jak usłyszeliśmy dobre nowiny, że tempo szczepionek przyśpiesza, dostaliśmy informację, że jednak to był błąd i będzie on ‘odkręcany’. Ponadto osoby czekające w miejscach szczepień nie mogły odbyć swoich zaplanowanych wizyt, ponieważ system przestał działać. Można uznać, że to był dzień pełen emocji, frustracji, złości i zawodów. Zawiódł kluczowy element w postaci komunikacji, w wyniku czego powstał chaos.

Jakie zagrożenia wiążą się z testowaniem na produkcji?

Jeśli testujemy na produkcji zamierzenie to przede wszystkim upewniamy się, że coś działa lub, że nie działa i umiemy to powtórzyć czyli obniżamy ryzyko i budujemy zaufanie.

Jeśli mówimy o negatywach to na pewno:

  • utrata wizerunkowa,
  • zniechęcenie użytkowników do korzystania,
  • zwiększone koszty,
  • stres pracowników,
  • utrata pieniędzy.

Testowanie na produkcji - wartościowa, ale niebezpieczna metoda na podniesienie jakości oprogramowania

Testowanie na produkcji to proces, który wymaga zorganizowania oraz skupienia. Zaniedbania i brak przestrzegania dobrych praktyk mogą skutkować błędami, których skutki są poważne. W ciągu ostatnich miesięcy mieliśmy do czynienia z kilkoma kryzysami, których echo sięgało daleko poza środowisko branżowe. Źle przeprowadzone testy na produkcji mogą prowadzić do strat wizerunkowych, obniżenia zaufania klientów, a także konsekwencji biznesowych i prawnych.

Czy to oznacza, że nie warto testować na produkcji? Z całą pewnością warto pokryć testami aplikacje na wcześniejszych etapach jej rozwoju. Jednak istnieją przypadki, w których testowanie na produkcji jest konieczne i dobrze przeprowadzone może stać się nawet jedną z przewag na rynku.