Menu

Testowanie eksploracyjne a testowanie skryptowe: kto wygrywa?

exploratory testing vs scripted testing

Prawdziwe korzyści płynące z testów eksploracyjnych:

Tradycyjnie testowanie oprogramowania było bardzo sztywną czynnością, ale w ostatnich latach nastąpiło odejście od testowania opartego na skryptach. Testowanie eksploracyjne , która jest bardziej zależna od kontekstu, wysunęła się na pierwszy plan. Dzieje się tak, ponieważ daje testerom większą swobodę w wykorzystywaniu ich umiejętności i wiedzy oraz czyni ich odpowiedzialnymi za optymalizację wartości własnej pracy.

Testowanie eksploracyjne a testowanie skryptowe

Nie każdemu sprzedaje się wartość testów eksploracyjnych. Dostrzegany brak formalności i nacisk na osobistą odpowiedzialność może wywołać alarm. Ale ta obawa jest w dużej mierze oparta na błędnej interpretacji testów eksploracyjnych. Nie chodzi o wyrzucanie reguł przez okno i testowanie losowo, w rzeczywistości jest to bardzo uporządkowane i systematyczne. Jest też bardzo skuteczny.

Sceptycy chcą konkretnego dowodu, że to coś więcej niż tylko poprawa morale testera. Dlatego zdecydowaliśmy się przeprowadzić badanie, w którym testy kontekstowe i eksploracyjne zostaną porównane bezpośrednio z podejściem opartym na skryptach. Wyniki były bardzo interesujące, o czym zaraz się przekonasz.

Czego się nauczysz:

Oparte na kontekście (testy eksploracyjne) a zespoły testowe oparte na skryptach

Dwie drużyny, dwa podejścia:

wejściowe pliki wyjściowe c ++

Zaczęliśmy od podzielenia testerów na dwie trzyosobowe drużyny. Testerzy w każdym zespole mieli taką samą porównywalną wiedzę na temat aplikacji. Te same definicje dla stopień wady (major, minor) zostały ustalone dla obu drużyn. Oba zespoły otrzymały tę samą kompilację aplikacji. Jeden zespół („skryptowy”) zastosowałby tradycyjne podejście do testowania opartego na skryptach, a drugi zespół („eksploracyjny”) zastosowałby podejście do testowania kontekstowego. Czynności testowe zostaną podzielone na dwie trzydniowe fazy każda.

Zespół oparty na skryptach zidentyfikował pięć biznesowych przepływów pracy do przetestowania i wygenerował 15 przypadków testowych. Przypadki testowe miały ograniczony zakres, więc testerzy nie mieli swobody eksploracji poza ograniczeniami skryptu.

Zespół badawczy stworzył dwa wizualne mapy myśli , jeden, który określa pokrycie testów i karty testów, a drugi obejmuje komponenty / moduły produktu. W wyniku tego procesu uzyskano łącznie 24 karty testowe. Zdefiniowane karty były wysokopoziomowe i pozwalały na interpretację kontekstową, rozszerzając zakres sesji testowej dla testerów.

Faza 1:

Zespołowi skryptowemu udało się ukończyć 6 przypadków testowych w wyznaczonych trzech dniach. Zgłosili w tym czasie 6 głównych usterek.

Zespołowi badawczemu udało się ukończyć 13 sesji testowych, trwających od 30 do 180 minut każda. Zgłosili 10 głównych usterek i 5 drobnych usterek.

testowanie skryptowe vs eksploracyjne 1

Co ciekawe, zespół badawczy zgłosił wszystkie usterki, które zgłosił zespół skryptowy.

Faza 2:

Zespołowi skryptowemu udało się ukończyć 9 przypadków testowych tym razem. Zgłosili się 10 głównych wad i 8 drobnych usterek .

Zespół badawczy zakończył 18 sesji. Zgłosili się 14 głównych wad i 5 drobnych usterek.

testowanie skryptowe vs eksploracyjne 2

W fazie 2 zespół skryptowy zgłosił 2 poważne i 1 pomniejsze usterki, których zespół eksploracyjny nie znalazł, ale zespół badawczy zgłosił 3 poważne i 1 pomniejsze usterki, których zespół skryptowy nie zgłosił.

Nie uwzględnia to względnej złożoności przepływów pracy, które mogły zostać wybrane przez testerów w ramach tych sesji i przypadków testowych, ale nadal możemy wyciągnąć interesujące wnioski.

Co to znaczy?

Wydawałoby się, że podejście eksploracyjne oraz odpowiedzialność i elastyczność, które z niego wynikają, skutkują bardziej efektywną formą testowania. Może być możliwe, aby objąć większy obszar, opracowując i dostosowując karty testów w miarę postępów sesji testowych, w oparciu o to, co ma sens w kontekście. Tej swobody brakuje w testowaniu opartym na skryptach i może ona zapobiegać wykrywaniu defektów.

Sztywne trzymanie się skryptów tworzy dobrze wytarte ścieżki i tylko zbaczając z nich zamierzamy odkryć wszystkie wady. Jak kilkakrotnie wspominali liderzy ze społeczności testowej: „Jeśli wyobrażasz sobie produkt jako pole min przeciwpiechotnych, a każda mina jest defektem, to jest całkiem jasne, że kroczenie tą samą ścieżką nie jest sposobem na ich znalezienie wszystko.'

Ostatecznie żadne podejście nie było doskonałe, ponieważ każdy zespół zgłaszał defekty, których drugi zespół nie zidentyfikował, nawet jeśli zespół badawczy zgłosił więcej, ogólnie.

Realistycznie może to oznaczać, że właściwe podejście, polegające na możliwie zbliżeniu się do „minimalnych” defektów, będzie połączeniem tych dwóch. Ale istnieje wiele korzyści z podejście kontekstowe które przemawiają na jego korzyść. Wymaga mniej czasu na przygotowanie, mniej dokumentacji, wcześniej identyfikuje problemy i stawia przed testerami wyzwanie korzystania z umiejętności analitycznych i wnioskowania dedukcyjnego. Zyskują głębsze i dokładniejsze zrozumienie produktu i naprawdę działają jako orędownicy dla użytkownika końcowego.

Wniosek

Wynik końcowy pokazuje, że testy eksploracyjne prowadzą do zgłaszania większej liczby defektów przed uruchomieniem, co skutkuje lepszym produktem dostarczonym przez zespół, a ostatecznie bardziej zadowolonych / spełnionych testerów które są pożądanymi wynikami, jakkolwiek na to spojrzysz.

o autorze

Mush Honda jest dyrektorem ds. Kontroli jakości w firmie Technologia KMS , dostawca usług IT w całym cyklu życia oprogramowania z biurami w Atlancie w stanie Georgia i Ho Chi Minh w Wietnamie. Wcześniej był testerem w Ernst & Young, Nexidia, Colibrium Partners i Connecture. Usługi KMS obejmują zarządzanie aplikacjami, testowanie, wsparcie, profesjonalne usługi i zwiększanie liczby pracowników.

Czy sie zgadzasz? Zapraszam do zamieszczania komentarzy, pytań poniżej.

pytania do wywiadu z analitykiem biznesowym w dziedzinie ubezpieczeń

POPRZEDNIA samouczek | NASTĘPNY samouczek nr 4: Testowanie eksploracyjne za pomocą HP Sprinter

rekomendowane lektury

^