Wyślij zapytanie Dołącz do Sii

Na potrzebę poniższego artykułu stworzymy sytuację, w której fabryka produkująca poduszkowce „Hovesea Sp. z o.o.” potrzebuje nowego oprogramowania do zarządzania produkcją. Fabryka znajduje się w Lęborku. Ich luksusowe poduszkowce są sławne na całym świecie.

Marszruta Poduszkowca hovesea Seahorse, wygenerowane przez DALL-E
Ryc. 1 Marszruta Poduszkowca hovesea Seahorse, wygenerowane przez DALL-E

Pani Agata, planistka produkcji, potrzebuje rozwiązania, które będzie brało pod uwagę możliwość zakupów z wyprzedzeniem oraz zarządzanie kilkoma procesami produkcyjnymi. Zwraca się do swojego działu IT z prośbą o pomoc. Po wstępnej analizie jeden z dostępnych systemów okazał się obiecujący. Nasza firma postanowiła wykonać razem z panią Agatą testy klienckie.

Przygotowanie testów klienckich, wygenerowane przez DALL-E
Ryc. 2 Przygotowanie testów klienckich, wygenerowane przez DALL-E

Testy klienckie: po co i dlaczego?

Często zastanawiamy się, czy w dobie powszechnej automatyzacji i sztucznej inteligencji jest jeszcze miejsce na testy manualne. Moim zdaniem, dopóki robimy oprogramowanie dla ludzi, to powinniśmy wykonywać pełne testy klienckie. Korzystanie ze sztucznej inteligencji na pewno może pomóc nam w pisaniu testów, automatyzacji, przygotowywaniu danych testowych, przygotowywaniu instrukcji, ale wciąż musimy sprawdzić, czy wytwarzane oprogramowanie jest użyteczne dla klienta. Czy spełnia jego potrzeby? Oczywiście pamiętając o tym, że testy manualne nie powinny dominować, ale powinny być ważne i kluczowe w procesie wytwarzania.

Jedną z faz wytwarzania oprogramowania są testy akceptacyjne, a szczególnym przypadkiem są testy wykonywane przez klienta. Celem takich testów jest:

  • sprawdzenie czy oprogramowanie jest zgodne z potrzebami klienta,
  • zweryfikowanie czy klient może osiągnąć swój cel za pomocą testowanego oprogramowania,
  • sprawdzenie czy oprogramowanie spełnia wcześniej określone kryteria,
  • zasięgnięcie opinii klienta,
  • sprawdzenie czy program/produkt odniesie sukces (testy beta),
  • ocena, kiedy należy dostosować konfigurację oprogramowania do potrzeb klienta (wdrożenie).

Reorganizacja testów klienckich i wytwarzanie oprogramowania

Testy klienckie najlepiej zreorganizować:

  • kiedy mamy wersje oprogramowania, w której są nowe funkcjonalności i jest ona gotowa do testów,
  • kiedy chcemy zbadać opinię klienta,
  • kiedy chcemy sprawdzić, czy system został odpowiednio skonfigurowany pod potrzeby klienta,
  • kiedy potrzebujemy wykonać testy na środowisku docelowym (klienckim).

Ważnym warunkiem rozpoczęcia testów akceptacyjnych jest stabilna wersja systemu bądź podsystemu/komponentu. Przez stabilność rozumiem, że klient, korzystając z systemu, może osiągnąć cele biznesowe (np. zaplanuje produkcję fabryki poduszkowców).

Przykładowy proces wytwarzania oprogramowania
Ryc. 3 Przykładowy proces wytwarzania oprogramowania

Testy klienckie mogą też być częścią procesu wytwarzania oprogramowania. Szerzej ten temat omówiłem przy okazji artykułu na temat persony: Persona – testowanie z wykorzystaniem technik z gier RPG. Weryfikacja zgodności wytwarzanego oprogramowania z oczekiwaniami klienta powinna mieć miejsce jak najszybciej.

Praktykuje się następujące podejścia:

  • zapraszanie klientów do projektowania wymagań (sesje design thinking, wspólny przegląd wymagań),
  • przeprowadzanie testów akceptacyjnych dla komponentów i systemu,
  • udział klienta w przeglądach (Sprint review).

Plan i przygotowanie testów

Podstawowe etapy Testów klienckich
Ryc. 4 Podstawowe etapy Testów klienckich

W ramach planowania testów potrzeby naszych klientów oraz zespołu wytwarzającego oprogramowanie muszą zostać właściwie nazwane i zaadresowane. Należy także ustalić pewien scenariusz postępowania i przygotować się na obsługę zgłoszeń, błędów, raportowania.

Testy klienckie Pani Agaty, która zdecydowała się sprawdzić aplikację do zarządzania produkcją, muszą zostać odpowiednio zaplanowane.

  • Obejmuje to wybranie czasu, w którym środowisko, programiści i analitycy po stronie wydawcy będą dostępni.
  • Należy przygotować właściwe środowisko testowe z danymi testowymi z odpowiednimi dostępami, również takie, które łatwo sprawdzić w przypadku wykrycia przez testera (klienta) defektu. Środowisko, na którym testuje klient, powinno być odizolowane od bieżącego rozwoju oprogramowania.
  • Dane testowe powinny być jak najbliżej zbliżone do tych, których będzie korzystał klient.
  • Zespół programistów/DevOPS powinni być powiadomieni o testach. Zapytania i błędy zgłaszane przez klienta powinny mieć wysoki priorytet. Warto zaplanować czas zespołu na obsługę zapytań klienta – może to oszczędzić przestojów w pracy i nieporozumień.
  • Podczas planowania testów należy ustalić plan komunikowania się, jakie informacje i kiedy powinny być dostępne. To ważny punkt w świetle polityki korporacji oraz samej relacji z klientem.
  • Warto przygotować listę rzeczy do sprawdzenia przed rozpoczęciem testów.
SprawdzenieOdpowiedzialny zespółKomentarz
Środowisko testowe przygotowaneZespół konfigurujący środowiska/DevOPSŚrodowisko powinno być gotowe i sprawdzone przed rozpoczęciem testów. Dobrą praktyką jest weryfikacja czy środowisko jest w pełni operacyjne
Dane testowe przygotowaneZespół konfigurujący środowiska/DevOPSDane testowe powinny być zbliżone do danych używanych przez klienta i nie powinny być danymi produkcyjnym żadnego z klientów
Dostęp do budynku/środowiska przyznanyDział HR/Dział ITNależy przygotować przepustkę, stację roboczą, podłączenie do wewnętrznej sieci
Zakres testów potwierdzonyManager testówCześć procesu planowania, zakres powinien być uzgodniony
Czas programistów/analityków zarezerwowanyDział wytwarzania oprogramowaniaSprawne zaadresowanie zgłoszeń klienta jest kluczowe. Chcemy, aby klient zaakceptował nasz system
Przypadki testoweTesterzy/KlientFaza przygotowania testów, przypadki testowe mogą być przygotowane wcześniej, może to być zestaw użyty podczas wcześniejszych faz wytwarzania oprogramowania
Tab. 1 Przykładowa lista sprawdzająca przygotowanie testów klienckich

Planując testy, należy uwzględnić kryteria rozpoczęcia i zakończenia testów.

Zakres, zakres, zakres

Pierwszym zadaniem będzie ustalenie zakresu testów oraz wskazanie, które funkcjonalności mają zostać przetestowane i kiedy. Zmiany w zakresie powinny być udokumentowane oraz zarządzane w celu uniknięcia komunikacyjnego zamieszania, testowania niewłaściwej funkcjonalności bądź wykonania testów w innej niż zamierzona kolejności (sekwencja testów klienckich powinna odwzorowywać przypadek użycia aplikacji).

Ważne, aby każdą ze zmian dotyczącą zakresu omówić z klientem, testerami i programistami.

Pełzający zakres, wygenerowane przez DALL-E
Ryc. 5 Pełzający zakres, wygenerowane przez DALL-E

Testy klienckie powinny być zaprojektowane w taki sposób, aby były zbliżone do tego, jak klient używa systemu. Dlatego ważne jest, aby zaznajomić się z procesem produkcyjnym klienta.

Cel testów

Ustalenie z klientem oraz zarządem co stanowi przedmiot testów, jest kluczowe dla powodzenia całego przedsięwzięcia. Powodem, dla którego wykonujemy testy klienckie, może być zdobycie nowych użytkowników bądź dostosowanie istniejącego produktu do procesu klienta np. do zarządzania produkcją.

Głównym celem klienta jest sprawdzenie czy system działa zgodnie z jego wymaganiami i czy może osiągnąć swoje cele biznesowe. Przed rozpoczęciem testów dobrze jest uzgodnić, co klient chce osiągnąć i w jaki sposób.

Wykonanie testów

Przed rozpoczęciem testów należy sprawdzić, czy środowisko, na którym testy będą wykonywane działa, baza danych testowych jest wypełniona właściwymi danymi, a klient ma wszystkie dostępy i ustawienia niezbędne do rozpoczęcia pracy.

Zaleca się także zrobić spotkanie wprowadzające, na którym przedstawiamy:

  • cel testów wcześniej uzgodniony i zaakceptowany,
  • funkcjonalności i obszary systemu, które będą testowane,
  • funkcjonalności i obszary systemu, które nie będą poddane testom,
  • osoby kontaktowe – analitycy, testerzy programiści, którzy będą opiekować się klientem podczas testów,
  • kryteria zakończenia testów.

Podczas wykonywania testów klient najprawdopodobniej będzie miał zgłoszenia i uwagi. Cześć z nich może się okazać defektami wymagającymi naprawy, a inne – po wyjaśnieniu – błędnym użyciem systemu.

Po zakończeniu testów klienckich należy przeprowadzić analizę zebranych danych i wyników. Kluczowym jest zidentyfikowanie obszarów wymagających ulepszeń. Wykorzystaj te informacje do wprowadzenia odpowiednich zmian i dostosowania swojej oferty do potrzeb klientów.

Komunikacja

Testowanie oprogramowania to nie tylko techniczne umiejętności, ale też ustrukturyzowany sposób przekazywania informacji.

Komunikacja z klientem oraz z zespołem programistycznym jest kluczowa. Codzienne, 15-minutowe rozmowy będą ważne nie tylko z powodu przekazywania informacji dotyczącej defektów bądź wyjaśnienia sposobu użycia, ale też, aby zbudować relację z testerami i klientem końcowym.

Kluczowym zadaniem menadżera organizującego testy jest zapewnienie swobodnego przepływu informacji i adresowanie problemów w skuteczny sposób.

Po wykonaniu testów należy sporządzić raport oraz ustalić wraz z klientem następne kroki:

  • akceptacja systemu,
  • warunkowa akceptacja testowanego systemu (warunkiem może być naprawa defektów, dodanie jakiejś funkcjonalności),
  • przesunięcie wdrożenia z powodu znaczących/krytycznych defektów.

Testy klienckie to ważne źródło wiedzy dla zespołu wytwarzającego oprogramowanie, a dzięki uczestnictwu klienta możemy określić przyszłe wymagania niefunkcjonalne.

Pani Agata wykonała swoje testy, korzystając ze środowiska udostępnionego zdalnie. System, który testowała, pozwolił jej zaplanować produkcję poduszkowców na czwarty kwartał roku 2027. Podczas testów zgłosiła kilka uwag, które okazały się łatwe do wyjaśnienia i usunięcia poprzez zmiany konfiguracyjne. Po zakończonej fazie testowania zdecydowała się na zakup oprogramowania i wykupienie dodatkowej usługi wdrożenia oprogramowania.

Ryzyko związane z testami klienckimi

Ryzyko związane z testami klienckimi, wygenerowane przez DALL-E
Ryc. 6 Ryzyko związane z testami klienckimi, wygenerowane przez DALL-E

Ryzyko związane z zakresem testów

Tak zwany „pełzający zakres” (dodawanie wciąż nowych zadań) jest nadal często występującym problemem, który przekłada się na porażkę lub chaos informacyjny. Każda zmiana w zakresie wykonywanego zadania musi zostać rozpatrzona pod względem potencjalnego wpływu na czas wykonania oraz dodatkowego nakładu związanego z ewentualnymi szkoleniami. Oczywiście zachowanie pewnej elastyczności w rozszerzaniu zakresu nie jest błędem.

Ryzyko związane z wizerunkiem

Testy klienckie wymagają otwartości ze strony organizacji. Testy należy zaplanować w taki sposób, aby uniknąć wizerunkowych problemów:

  • przygotować system do testów,
  • zabezpieczyć system przed wyciekiem wrażliwych danych,
  • zabezpieczyć dane innych klientów,
  • zabezpieczyć dane pracowników,
  • wykazać profesjonalną i pomocną postawę.

Ryzyko związane z klientem

Klient bądź tester reprezentujący klienta może nie mieć właściwych kompetencji dotyczących procesu biznesowego lub testowania. Planując testy, należy uwzględnić czas na przygotowanie klienta: odpowiednie wprowadzenie do systemu i procesu testowania.

Ryzyko związane z czasem wykonania testów

Czas trwania testów może się wydłużyć z wielu powodów tj. niedostępności środowiska testowego, krytycznych defektów czy też niskiego priorytetu testów po stronie klienta. Warto zarezerwować dodatkowy czas, który uwzględni nieoczekiwane przesunięcia.

Ryzyko związane z defektami

Defekty, które znajdą klienci podczas testów, powinny zostać jak najszybciej naprawione. Jeżeli naprawa defektu wiąże się z dużą czasochłonnością (wykraczającą poza okres testów), należy określić krytyczność defektu i określić maksymalny czas na to działanie. Krytyczne defekty mogą być przyczyną opóźnienia wdrożenia naszego systemu u klienta. W skrajnych przypadkach klient może zrezygnować z korzystania z systemu. Dlatego ważne jest zaadresowanie wszystkich uwag klienta i odpowiedzenie na jego pytania.

Podsumowanie

Testy klienckie są ważnym etapem wytwarzania oprogramowania. Jest to też okazja dla naszej organizacji, żeby lepiej poznać wymagania klienta oraz zbudować z nim relacje. Ważne jest uprzednie przygotowanie i monitorowanie postępu testów. Wiedza pozyskana podczas wspólnych testów klienckich pomoże przy rozwoju kolejnych funkcjonalności oraz do ulepszenia samego produktu.

5/5 ( głosy: 3)
Ocena:
5/5 ( głosy: 3)
Autor
Avatar
Michał Kozłowski

Test Manager w Sii Polska. Pracuje w testach od 2009 roku. Karierę w IT zaczął jako producent gier na telefony komórkowe w czasach przed pierwszym iPhonem. Od 2011 roku zajmuje się zarządzaniem testami. Pracował dla dużych klientów z obszaru lotnictwa i telekomunikacji. Od 2013 roku prowadzi szkolenia dla testerów. Szkoli w Software Development Academy i wykłada testowanie oprogramowania w WSB Merito w Gdańsku. Prywatnie jest ojcem czteroletniej dziewczynki oraz miłośnikiem gier RPG.

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Może Cię również zainteresować

Pokaż więcej artykułów

Bądź na bieżąco

Zasubskrybuj naszego bloga i otrzymuj informacje o najnowszych wpisach.

Otrzymaj ofertę

Jeśli chcesz dowiedzieć się więcej na temat oferty Sii, skontaktuj się z nami.

Wyślij zapytanie Wyślij zapytanie

Natalia Competency Center Director

Get an offer

Dołącz do Sii

Znajdź idealną pracę – zapoznaj się z naszą ofertą rekrutacyjną i aplikuj.

Aplikuj Aplikuj

Paweł Process Owner

Join Sii

ZATWIERDŹ

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?