Testowanie ad-hoc: How to Find Defects Without a Formal Testing Process

Samo określenie ad-hoc implikuje brak struktury lub coś, co nie jest metodyczne. Kiedy mówimy o testowaniu ad-hoc, oznacza to, że jest to forma czarnej skrzynki lub testowania behawioralnego wykonywanego bez żadnego formalnego procesu na miejscu.

Formalny proces oznacza tutaj posiadanie dokumentacji takiej jak dokumenty wymagań, Plany Testów, Przypadki Testowe i właściwe planowanie Testów pod względem ich harmonogramu i kolejności wykonywanych testów. Również, wszelkie działania wykonywane podczas testów nie są zazwyczaj dokumentowane.

Testowanie ad-hoc jest głównie wykonywane w celu wykrycia defektów lub wad, które nie mogą być uchwycone poprzez tradycyjne lub formalne procesy stosowane podczas cyklu testowego.

Jak już zrozumiano, istota tego testowania leży w tym, że nie ma formalnego lub ustrukturyzowanego sposobu testowania. Kiedy taki rodzaj przypadkowych technik testowania jest wykonywany, to jest oczywiste, że testerzy wykonują to bez żadnego konkretnego przypadku użycia w umyśle z zamiarem złamania systemu.

Stąd zdecydowanie jest jeszcze bardziej oczywiste, że taka intuicyjna lub kreatywna metodologia testowania wymaga, aby tester był niezwykle wykwalifikowany, zdolny i miał dogłębną wiedzę o systemie. Testowanie ad-hoc zapewnia, że wykonywane testy są kompletne i jest szczególnie bardzo użyteczne w określaniu skuteczności wiadra testowego.

Zalecana lektura => Testowanie Eksploracyjne – Jak Myśleć Poza Tradycyjnymi Granicami Testowania?

Zacznijmy od przykładu testowania ad-hoc

Oto przykład, jak możemy przeprowadzić takie testowanie, jeśli chodzi o Kreator UI.

Powiedzmy, że musisz stworzyć plan lub szablon dla jakiegoś zadania, które ma być wykonane przy użyciu tego Kreatora UI. Kreator jest serią paneli, które mają dane wejściowe użytkownika, takie jak nazwa, opis itp.

Jak kreator postępuje: powiedzmy na jednym z paneli, dane użytkownika mają być wprowadzone, co wiąże się z kreatorem UI, aby rzucić wyskakujące okienko kontekstowe, które dodaje powiązane dane do ukończenia kreatora i wdrożenia/aktywacji kreatora.

Aby to przetestować tester wykonuje swoje regularne testy takie jak:

• Pomyślne zakończenie pracy kreatora z wszystkimi poprawnymi danymi i utworzenie planu.
• Anulowanie kreatora w połowie drogi.
• Edytuj utworzony plan poprzez kreator.
• Usuń utworzony plan i zobacz, że nie ma po nim pozostałości.
• Wprowadź wartość ujemną w kreatorze i zobacz odpowiednie komunikaty o błędach.

Teraz, dla powyższego przykładu oto kilka przypadków testowych dla testów ad-hoc, które mogłyby zostać wykonane w celu odkrycia jak największej liczby defektów:

• Podczas próby dodania danych ujemnych, dodaj pewne znaki specjalne, które nie są ograniczone, aby sprawdzić, czy są one obsługiwane prawidłowo. Na przykład, czasami kreatory nie ograniczają {lub [ nawiasów klamrowych, ale w pewnych sytuacjach może to być sprzeczne z kodem opartym na języku, w którym jest napisany, i spowodować bardzo niewiarygodne zachowanie.
• Inny test jest szczególnie w odniesieniu do wyskakujących okienek. Użytkownik może spowodować uruchomienie wyskakującego okienka, a następnie spróbować nacisnąć przycisk backspace na klawiaturze. Wielokrotnie zaobserwowałem, że zrobienie tego powoduje całkowite zniknięcie kreatora tła i utratę wszystkich danych użytkownika, które zostały wprowadzone do momentu uruchomienia wyskakującego okienka!

Charakterystyka testowania ad hoc:

Jeśli zwrócisz uwagę na powyższe scenariusze, zobaczysz coś bardzo wyraźnego charakterystycznego dla tego typu testowania.

Są to:

• Są one zawsze zgodne z celem testu. Są to jednak pewne drastyczne testy wykonywane z zamiarem złamania systemu.
• Tester musi mieć pełną wiedzę i świadomość na temat testowanego systemu. Rezultatem tego testowania jest znalezienie błędów, które próbują uwypuklić luki w procesie testowania.
• Patrząc również na powyższe dwa testy, naturalną reakcją na nie byłoby, że – ten rodzaj testu może być wykonany tylko raz, ponieważ nie jest wykonalne ponowne testowanie, chyba, że wiąże się to z defektem.

Kiedy robimy testy ad-hoc?

Pytanie za milion dolarów!

Większość zespołów testowych jest zawsze obciążona zbyt dużą ilością funkcji do przetestowania w ograniczonym czasie. W tym ograniczonym przedziale czasowym, jest wiele czynności testowych, które są pochodną formalnego procesu, który również musi być zakończony. W takich sytuacjach testowanie ad-hoc, które znajduje swoją drogę do testowania jest szczupłe.

Jednakże, z mojego doświadczenia, jedna runda testowania ad-hoc może zdziałać cuda dla jakości produktu i podnieść wiele pytań projektowych.

Ponieważ testowanie ad-hoc jest bardziej techniką testowania „dzikiego dziecka”, która nie musi być ustrukturyzowana, ogólnym zaleceniem jest to, że musi być wykonane po wykonaniu bieżącego wiadra testowego. Inny punkt widzenia jest taki, że może to być zrobione kiedy szczegółowe testowanie nie może być wykonane z powodu mniejszej ilości czasu.

Moim zdaniem, powiedziałbym, że testowanie ad-hoc może być wykonane prawie w każdym czasie – na początku, w środku i na końcu! Po prostu znajduje swoje miejsce w danym czasie. Jednakże, kiedy testowanie ad-hoc musi być wykonane, aby przynieść maksymalną wartość, jest najlepiej oceniane przez doświadczonego testera, który ma głęboką wiedzę na temat testowanego systemu.

Kiedy nie wykonywać?

Jeśli poprzednie pytanie było warte milion dolarów, to to powinno być warte miliard!

Ponieważ ustaliliśmy jak skuteczne i owocne mogą być testy ad-hoc, jako wykwalifikowany i zdolny tester musimy również rozszyfrować kiedy nie inwestować w ten typ testów. Chociaż jest to zależne od uznania testera, oto kilka zaleceń/przykładów, kiedy może to nie być konieczne.

• Unikaj tego testowania, gdy istnieje przypadek testowy, dla którego istnieje wada. W takiej sytuacji istnieje potrzeba udokumentowania punktu awarii przypadku testowego, a następnie zweryfikowania/przetestowania wady, gdy zostanie ona naprawiona. Stąd nie będzie to miało tutaj zastosowania.
• Mogą również istnieć pewne scenariusze, w których klienci mogą być zaproszeni do testowania wersji beta oprogramowania. W takich przypadkach, to testowanie nie powinno być prowadzone.
• Innym scenariuszem jest, gdy jest bardzo prosty ekran UI, który jest dodawany. Tradycyjne testy pozytywne i negatywne powinny tutaj wystarczyć, aby wydobyć maksimum defektów.

Types Of Ad-hoc Testing

Testy ad-hoc można podzielić na trzy kategorie poniżej:

#1) Buddy Testing

W tej formie testowania, będzie jeden członek testujący i jeden członek rozwijający, który zostanie wybrany do pracy nad tym samym modułem. Zaraz po tym, jak deweloper zakończy testy jednostkowe, tester i deweloper siedzą razem i pracują nad modułem. Ten rodzaj testowania pozwala funkcji być postrzegane w szerszym zakresie dla obu stron.

Deweloper zyska perspektywę wszystkich różnych testów, które tester prowadzi, a tester zyska perspektywę, jak nieodłączny projekt jest, który pomoże mu uniknąć projektowania nieważnych scenariuszy, zapobiegając w ten sposób nieważnych wad. Pomoże to jednemu myśleć jak drugi.

#2) Testowanie w parach

W tym testowaniu, dwóch testerów pracuje razem nad modułem z tą samą konfiguracją testową dzieloną pomiędzy nich. Idea stojąca za tą formą testowania polega na tym, że dwaj testerzy robią burzę mózgów, pomysły i metody, aby mieć pewną liczbę defektów. Obaj mogą dzielić się pracą nad testowaniem i sporządzić niezbędną dokumentację wszystkich poczynionych obserwacji.

#3) Testowanie małp

Testowanie to jest głównie wykonywane na poziomie testów jednostkowych. Tester parsuje dane lub testy w całkowicie przypadkowy sposób, aby upewnić się, że system jest w stanie wytrzymać wszelkie awarie. To testowanie może być dalej sklasyfikowane w dwóch kategoriach:

Testowanie ad hoc Korzyści

Testowanie to gwarantuje testerowi dużo mocy, aby być tak kreatywnym, jak to konieczne.

To zwiększa jakość testowania i efektywność jak poniżej:

• Największą zaletą, która się wyróżnia jest to, że tester może znaleźć więcej defektów niż w tradycyjnym testowaniu z powodu różnych innowacyjnych metod, które może zastosować do testowania oprogramowania.
• Ta forma testowania może być zastosowana gdziekolwiek w SDLC; nie jest ograniczona tylko do zespołu testującego. Deweloperzy mogą również przeprowadzać te testy, co pomoże im lepiej kodować, a także przewidywać, jakie problemy mogą się pojawić.
• Może być połączony z innymi testami, aby uzyskać najlepsze wyniki, które czasami mogą skrócić czas potrzebny na regularne testowanie. To umożliwiłoby wygenerowanie lepszej jakości przypadków testowych i lepszą jakość produktu w ogóle.
• Nie wymaga żadnej dokumentacji do zrobienia, co zapobiega dodatkowemu obciążeniu testera. Tester może skoncentrować się na zrozumieniu architektury produktu.
• W przypadkach, gdy nie ma zbyt wiele czasu na testowanie, może to okazać się bardzo wartościowe pod względem pokrycia testowego i jakości.

Wady testowania ad-hoc

Testowanie ad-hoc ma również kilka wad. Przyjrzyjmy się niektórym z tych wad, które są widoczne:

Ponieważ nie jest ono zbyt zorganizowane i nie ma obowiązkowej dokumentacji, najbardziej oczywistym problemem jest to, że tester musi pamiętać i przywoływać w pamięci wszystkie szczegóły scenariuszy ad-hoc. Może to być jeszcze większym wyzwaniem, zwłaszcza w scenariuszach, w których występuje wiele interakcji pomiędzy różnymi komponentami.

• W nawiązaniu do pierwszego punktu, może to również spowodować, że nie będzie w stanie odtworzyć defektów w kolejnych próbach, jeśli zostanie poproszony o informacje.
• Kolejną bardzo ważną kwestią, którą to ujawnia, jest odpowiedzialność za wysiłek. Ponieważ nie jest to planowane/strukturalne, nie ma sposobu na rozliczenie czasu i wysiłku zainwestowanego w ten rodzaj testowania.
• Testy ad hoc muszą być wykonywane tylko przez bardzo kompetentnego i wykwalifikowanego testera w zespole, ponieważ wymagają bycia proaktywnym i intuicyjnym w zakresie przewidywania potencjalnych obszarów obfitujących w defekty.

Najlepsze praktyki, aby uczynić to testowanie bardziej efektywnym

Dokładnie omówiliśmy mocne i słabe strony związane z tym testowaniem.

Oczywiście, testowanie ad-hoc powinno znaleźć swoje miejsce w SDLC, jednakże, jeżeli nie podejdzie się do niego w odpowiedni sposób, może okazać się kosztowne i być stratą cennego czasu testowania. Tak więc poniżej jest kilka wskazówek, aby testowanie ad-hoc było skuteczne:

#1) Zidentyfikuj obszary podatne na błędy:

Gdy masz dobrą władzę nad testowaniem konkretnego kawałka oprogramowania, zgodzisz się, że będą pewne cechy, które są bardziej podatne na błędy niż inne. Jeśli jesteś nowy w systemie, a następnie przejść do przodu i sprawdzić cechy v / v defekty otwarte przeciwko nim.

Liczba wad w danej funkcji jest pokaże Ci, że jest wrażliwy i należy dokładnie wybrać, że bardzo obszar do wykonywania testów ad hoc. To okazuje się być bardzo wydajnym sposobem na ujawnienie poważnych defektów.

#2) Budowanie ekspertyzy:

Niewątpliwie tester, który ma większe doświadczenie jest bardziej intuicyjny i może zgadnąć, gdzie mogą być błędy, w porównaniu do kogoś, kto nie ma dużego doświadczenia. Powiedziałbym, że doświadczony czy nie, to zależy od osoby, która podejmie wyzwanie i zbuduje wiedzę na temat systemu, który jest testowany.

Tak, doświadczeni testerzy mają przewagę, ponieważ ich umiejętności zbudowane przez lata są przydatne, ale nowi testerzy powinni wykorzystać to jako platformę do zdobycia jak największej wiedzy, aby zaprojektować lepsze scenariusze ad-hoc.

#3) Stwórz kategorie testowe:

Gdy już znasz listę funkcji do przetestowania, poświęć kilka minut, aby zdecydować, jak skategoryzujesz te funkcje i przetestujesz. For Example, you should decide to test features that are most visible and most commonly used by the user before anything else, as these would seem critical to the software’s success.

Then you could categorize them functionality/ priority wise and test them segment by segment.

Another example where this is particularly very important is if there is integration between components or modules. W tych przypadkach, może być wiele nieprawidłowości, które mogą wystąpić. Użycie kategoryzacji pomogłoby dotknąć tego rodzaju testu przynajmniej raz lub dwa razy.

#4) Miej przybliżony plan:

Tak, tak ten punkt może cię trochę zmylić, ponieważ opisaliśmy testowanie ad-hoc jako testowanie, które nie powinno mieć żadnego planowania lub dokumentacji. Chodzi o to, aby trzymać się istoty testowania ad-hoc, ale nadal, mieć kilka zgrubnych wskazówek, jak planujesz testować.

Bardzo podstawowym przykładem jest to, że czasami możesz po prostu nie być w stanie zapamiętać wszystkich testów, które zamierzasz wykonać. Więc zapisanie ich zapewni, że nie przegapisz niczego.

#5) Narzędzia:

Przyjmijmy przykład, z którym każdy z nas ma do czynienia bardzo często. Wiele razy, jeśli obserwować, testowanie funkcjonalności w sobie jest udany z żadnych rozbieżności zgłoszonych w jego zachowaniu. Jednakże, logi za kulisami mogą zgłaszać pewne wyjątki, które mogą być przeoczone przez testerów, ponieważ nie utrudniają one w żaden sposób realizacji celu testu. Stąd bardzo ważne jest, abyśmy nauczyli się i poznali narzędzia, które pomogą nam to natychmiast zidentyfikować.

#6) Dokumentacja dla większej ilości defektów:

Again, rozumiem, że to może ponownie wywołać pewne brwi. Dokumentacja nie musi być szczegółowa, ale wystarczy mała notatka dla własnego odniesienia do wszystkich różnych scenariuszy objętych, odchylenia w krokach zaangażowanych i nagrać te wady dla danej kategorii funkcji testowej.

To pomoże Ci poprawić ogólne wiadro testowe, jak również, dzięki czemu można zdecydować, jak poprawić istniejące przypadki testowe lub dodać więcej, jeśli to konieczne.

Wniosek

Szczegółowo omówiliśmy techniki testowania ad-hoc – ich mocne i słabe strony, sytuacje, w których byłyby i nie byłyby korzystne.

Jest to jedna technika testowania, która gwarantuje zaspokojenie kreatywności testera do maksimum. W całej mojej karierze testerskiej, zyskuję największą satysfakcję z testowania ad hoc, ponieważ nie ma żadnych ograniczeń w byciu innowacyjnym, a ty tylko kończysz będąc bardziej kompetentnym.

Powiedziawszy to, główną rzeczą, którą należy wziąć z powrotem z wszystkich powyższych informacji, byłoby określenie, jak wykorzystać mocne strony testowania ad hoc i sprawić, że doda ono wartość do ogólnego procesu testowania i jakości produktu.

O autorze: To jest artykuł gościnny autorstwa Sneha Nadig. Pracuje jako Test lead z ponad 7-letnim doświadczeniem w projektach testowania manualnego i automatycznego.

Czy przeprowadzasz testy ad-hoc w swoim projekcie? Jakie są Twoje sugestie, aby testy ad-hoc zakończyły się sukcesem?