Przyszedł czas na mój kolejny artykuł. Tym razem przybliżę Wam ostatniego “reprezentanta” testów funkcjonalnych, które opisałem w tekście Najczęściej występujące rodzaje testów z perspektywy testera manualnego. Są to testy eksploracyjne, nazywane również testami ad hoc lub “testerską improwizacją”.

Wg słownika pojęć ISTQB, jest to nieformalna technika projektowania testów, w której tester projektuje testy w czasie, gdy są one wykonywane i wykorzystuje informacje zdobyte podczas testowania do projektowania nowych i lepszych testów.

Testy eksploracyjne wykorzystywane są często w przypadku braku dokumentacji lub niewystarczających zasobów, co uniemożliwia testerowi manualnemu przeprowadzenie innego rodzaju testowania. Mogą być wykonywane zarówno w początkowej, jak i końcowej fazie tworzenia produktu.

Co wpływa na sukces testów eksploracyjnych?

Czynnikami wpływającymi na powodzenie testów ad hoc są m.in.:

 

Wiedza

Mam na myśli zwłaszcza teorię, np. znajomość danych technologii, narzędzi etc. Na przykład: jak pisać zapytania SQL, dzięki czemu tester manualny jest w stanie w szybki sposób wyciągnąć dane potrzebne mu do testów z bazy danego produktu. Kolejny przykład: testujemy aplikację na bazie platformy CRM Salesforce, ale nie mamy znajomości relacji obiektów. W tej sytuacji nie wiedzielibyśmy, że – mając relację obiektów „master-detail” – gdy usuniemy rekord parent, czyli grupę „Samochody”, usuwamy również wszystkie rekordy typu child – wszystkie „Marki” wraz z „Modelami” do nich przypisanymi.

testy eksploracyjne=grafika 2

 

Doświadczenie

Wraz z upływem czasu zdobywamy coraz więcej praktyki, dzięki metodzie prób i błędów, pracy w różnych projektach i podejściach do ich realizacji. Ciężko byłoby początkującemu testerowi – bez dokumentacji do aplikacji – szybko ułożyć w głowie plan działania i określić priorytety obszarów do testowania.

Opiszę to na przykładzie: mamy aplikację mobilną dla kurierów do nadawania statusów przesyłkom. Aplikacja działa offline i przekazuje statusy do aplikacji webowej dla dyspozytorów. Warto pamiętać, że nie wszystkie apki zawsze działają online i dlatego w pierwszej kolejności należy sprawdzić, czy po wywołaniu synchronizacji dane z aplikacji mobilnej trafią do aplikacji webowej. Bez tego stan przesyłek w magazynie nie będzie zgodny z realną ich liczbą i dyspozytorzy nie będą wiedzieli, że kurier już zabrał z magazynu przesyłkę i dostarczył do klienta.
Pamiętajmy poza tym, że nasze doświadczenie życiowe z różnych obszarów też jest przydatne. Osobie, która kiedyś prowadziła sprzedaż internetową, będzie łatwiej przetestować platformy do zakładania sklepu internetowego, jak np.: “Shoper”, “PrestaShop” czy “Magento”, ponieważ  lepiej rozumie potrzeby biznesowe. Podobnie osoba, która wcześniej pracowała jako kurier, będzie miała podstawową wiedzę biznesową, pomocną w testowaniu aplikacji związanych z tą branżą.

 

Intuicja

Pomyślmy o pracy detektywa, który badając daną poszlakę, trafi na trop prowadzący do rozwiązania sprawy. Podobnie tester manualny: używając wybranej kombinacji danych, kroków znajdzie błąd. Pamiętam sytuację, gdy testowałem aplikację dla kurierów. Przy tworzeniu przesyłki do odbioru przez kuriera w jednominutowych odstępach czasowych dla gabarytów najmniejszych i największych aplikacja działała poprawnie, ale dla wymiarów niestandardowych formularz tworzenia zamykał się bez wyświetlania przesyłki na liście.

testy eksploracyjne

Obraz – czynniki wpływające na sukces testów eksploracyjnych

 

Poznanie aplikacji za pomocą testerskiej improwizacji

W idealnym świecie każdy produkt powinien mieć aktualną dokumentację, ale z doświadczenia wiem, że rzadko tak jest 😉 Jeśli pracujemy w projekcie od początku tworzenia aplikacji, jesteśmy na bieżąco i dokumentacja nie jest nam za bardzo potrzebna. Schody zaczynają się, gdy dostajemy do testowania aplikację, która była rozwijana przed naszym dołączeniem do projektu. Szczególnie w projektach migracyjnych, gdy firma sprzedaje daną aplikację innej firmie – wówczas nie ma co liczyć na aktualną dokumentację. Często po drodze są wykonywane zmiany, a czas ma ogromne znaczenie – wszystko odbywa się kosztem tworzenia dokumentacji, bo nowy właściciel chce jak najszybciej czerpać korzyści z danej inwestycji.

Pamiętam, gdy trafiłem do dużego projektu w momencie, kiedy produkt przechodził w ręce nowego właściciela. Dokumentacja była nieaktualna, filmiki instruktażowe nie pokazywały podstaw, tylko bardziej zaawansowane procesy. Do tego doszły terminy wyśrubowane do granic i codzienne spotkania statusowe, na których podkreślano oczekiwanie na jak najszybsze rezultaty. Byłem odpowiedzialny za tworzenie przypadków testowych dla jednego z obszarów aplikacji.

To była doskonała okazja do użycia testów eksploracyjnych. Zacząłem od sprawdzenia, w jakiej technologii jest zbudowana aplikacja i jaki jest cel jej działania. Kolejnym etapem było rozpisanie na bazie doświadczenia potencjalnych słów kluczowych, określających przypadki testowe, np. “utworzenie serwisanta”, ”utworzenie zlecenia pracy” etc. Później przystąpiłem do testowania na bazie powyższych słów kluczowych, stosując różne dane i kombinacje. Gdy miałem wątpliwości lub znalazłem potencjalny błąd, konsultowałem się z analitykiem biznesowym lub z osobą z biznesu, która u poprzedniego właściciela korzystała z tego obszaru aplikacji na co dzień. Z czasem, uzyskując odpowiedzi na moje pytania oraz wiedząc, co jest błędem, a co poprawnym działaniem, poznałem obszar aplikacji, za który byłem odpowiedzialny. W efekcie – w wyznaczonym terminie – utworzyłem przypadki testowe spełniające oczekiwania klienta.

 

Testy eksploracyjne – kiedy powiedzieć dość?

W przypadku testów ad hoc trzeba odpowiedzieć sobie na pytanie: Ile czasu możemy na takie testy poświęcić? Jeśli mamy aplikację, która nie jest skomplikowana, wystarczy już godzina,  żeby poznać obszar produktu i przystąpić do pisania przypadków testowych, bez tracenia czasu na przygotowanie dokumentacji.

A gdy w grę wchodzi duża aplikacja? Pamiętam, że w takiej sytuacji lider zespołu testerów ogłaszał dzień i przedział czasowy, w jakim mamy wykonać testy eksploracyjne. Na testy regresyjne wg przypadków testowych nie było czasu, a klient oczekiwał bardzo częstego sprawdzania, czy produkt nadal działa poprawnie. Dla przykładu: ja i pozostali testerzy mieliśmy  na takie testy 2 godziny, między 11:00-13:00, w poniedziałek i piątek. Każdy tester z zespołu w tym czasie przeprowadzał testy, a wszelkie błędy były zapisywane w excelu online. Po upływie wyznaczonego czasu, nawet gdy zostało jeszcze coś do przetestowania, musieliśmy przerwać pracę i wdzwonić się na spotkanie – omawialiśmy na nim błędy znalezione w wyznaczonym przedziale czasowym.

Testy eksploracyjne mogą być stosowane zarówno w małych, jak i dużych aplikacjach. Jest to jedna z metod na szybkie wdrożenie testera do projektu. Liczę, że ten ostatni artykuł, jak i poprzednie z mojej serii, opisującej przykłady testów funkcjonalnych, pozwolą Wam na lepsze ich zrozumienie i zastosowanie w praktyce podczas Waszej kariery testerskiej.

Autor
  • Mateusz Wydmański
  • Senior Software Tester
  • Tester związany z branżą Quality Assurance (QA) od ponad 5 lat, pracował w małych firmach oraz dużych korporacjach w sektorze healthcare, pharma, telecom i logistics. W pracy otwarty na nowe wyzwania, wykonuje je z pełnym zaangażowaniem dla osiągnięcia jak najlepszego rezultatu, jak również udoskonalania procesów. Prywatnie lubi poruszać się na siłowni lub spacerować na świeżym powietrzu.

Opracowanie redakcyjne:
Ania Sawicka
Opracowanie redakcyjne
Podobał Ci się mój artykuł?

Jeśli tak, zapraszam Cię do grona najlepiej poinformowanych czytelników bloga. Dołącz do naszego newslettera, a nie ominą Cię żadne nowości.