Menu

Testowanie ad hoc: jak znaleźć usterki bez formalnego procesu testowania

ad hoc testing how find defects without formal testing process

Samo określenie ad-hoc oznacza brak struktury lub coś, co nie jest metodyczne. Kiedy mówisz o testowanie ad hoc oznacza to, że jest to forma czarna skrzynka lub testy behawioralne przeprowadzone bez żadnego formalnego procesu.



Formalny proces oznacza tutaj posiadanie dokumentacji, takiej jak dokumenty wymagań, plany testów, przypadki testowe i właściwe planowanie testów pod kątem harmonogramu i kolejności wykonywanych testów. Ponadto żadne czynności wykonywane podczas testowania nie są zazwyczaj dokumentowane.



Testowanie ad hoc

Odbywa się to głównie w celu wykrycia defektów lub wad, których nie można uchwycić za pomocą tradycyjnych lub formalnych procesów realizowanych podczas cyklu testowania.



Jak już zrozumiano, istota tego testowania polega na braku formalnego lub zorganizowanego sposobu testowania. Kiedy przeprowadza się tego rodzaju losowe techniki testowania, jest to oczywiste testerzy wykonują to bez konkretnego przypadku użycia, mając na celu rozbicie systemu.

Stąd zdecydowanie bardziej oczywiste jest, że taka intuicyjna lub kreatywna metodologia testowania tego wymaga tester musi być wyjątkowo wykwalifikowanym, zdolnym i dogłębnym know-how systemu. Testowanie ad-hoc zapewnia, że ​​przeprowadzone testy są kompletne i jest szczególnie przydatne przy określaniu skuteczności wiadra testowego.

Rekomendowane lektury=> Testowanie eksploracyjne - jak wyjść poza tradycyjne granice testowania?



Czego się nauczysz:

Zacznijmy od przykładu testowania ad hoc

Oto przykład, jak możemy przeprowadzić te testy, jeśli chodzi o Kreatora interfejsu użytkownika.

Powiedzmy, że musisz utworzyć plan lub szablon dla jakiegoś zadania do wykonania za pomocą tego kreatora interfejsu użytkownika. Kreator to seria paneli, które zawierają dane wejściowe użytkownika, takie jak nazwa, opis itp.

W miarę postępów kreatora: powiedzmy na jednym z paneli, należy wprowadzić dane użytkownika, co oznacza, że ​​kreator interfejsu użytkownika wyrzuca kontekstowe okienko wyskakujące, które dodaje powiązane dane w celu ukończenia kreatora i wdrożenia / aktywacji kreatora.

Aby przetestować tego testera, wykonuje jego regularne testy, takie jak:

  • Wypełnij kreatora pomyślnie wszystkimi poprawnymi danymi i utwórz plan.
  • Anuluj kreatora w połowie.
  • Edytuj utworzony plan za pomocą kreatora.
  • Usuń utworzony plan i sprawdź, czy nie ma po nim pozostałości.
  • Wprowadź wartość ujemną w kreatorze i zobacz, czy są wyświetlane odpowiednie komunikaty o błędach.

Teraz do powyższego przykładu oto kilka przypadków testowych do testów ad hoc które można by wykonać aby odkryć jak najwięcej wad:

program szybkiego sortowania w C ++
  • Próbując dodać ujemne dane, dodaj pewne znaki specjalne, które nie są ograniczone, aby sprawdzić, czy są prawidłowo obsługiwane. Na przykład, czasami kreatorzy nie ograniczają {ani [nawiasów klamrowych], ale w pewnych sytuacjach może to kolidować z kodem w oparciu o język, w którym jest napisany, i powodować bardzo zawodne zachowanie.
  • Inny test dotyczy wyskakujących okienek. Użytkownik może spowodować uruchomienie wyskakującego okienka, a następnie spróbować nacisnąć przycisk Backspace na klawiaturze. Wiele razy zauważyłem, że w ten sposób kreator działający w tle całkowicie znika, a wszystkie dane użytkownika, które zostały wprowadzone do momentu uruchomienia wyskakującego okienka, zostają utracone!

Charakterystyka testów ad-hoc:

Jeśli zwrócisz uwagę na powyższe scenariusze, zobaczysz coś bardzo charakterystycznego dla tego typu testów.

Oni są:

  • Są zawsze zgodne z celem testu. Są to jednak pewne drastyczne testy przeprowadzone z zamiarem złamania systemu.
  • Tester musi mieć pełną wiedzę i świadomość na temat testowanego systemu. W wyniku tego testowania znajdują się błędy, które próbują ujawnić luki w procesie testowania.
  • Patrząc również na powyższe dwa testy, naturalną reakcją na to byłoby to, że - ten rodzaj testu można wykonać tylko raz, ponieważ nie można go przeprowadzić ponownie, chyba że jest powiązany z defektem.

Kiedy przeprowadzamy testy doraźne?

Naprawdę pytanie za milion dolarów!

Przez większość czasu zespoły testowe są zawsze obciążone zbyt wieloma funkcjami, aby przetestować je w ograniczonych ramach czasowych. W tym ograniczonym przedziale czasowym istnieje wiele czynności testowych wywodzących się z formalnego procesu, który również musi zostać zakończony. W takich sytuacjach testy ad-hoc, które trafiają do testów, są niewielkie.

Jednak z mojego doświadczenia wynika, że ​​jedna runda testów ad hoc może zdziałać cuda dla jakości produktu i wywołać wiele pytań projektowych.

Ponieważ testowanie ad-hoc jest bardziej techniką testowania „dzikiego dziecka”, która nie musi mieć struktury, ogólne zalecenie jest takie, że należy je wykonać po wykonaniu bieżącego przedziału testowego. Innym punktem widzenia jest to, że można to zrobić, gdy nie można przeprowadzić szczegółowych testów ze względu na krótszy czas.

Moim zdaniem powiedziałbym, że Testy ad-hoc można przeprowadzić prawie w dowolnym momencie - na początku, w środku i na końcu! Po prostu znajduje swoje miejsce w dowolnym momencie. Jednak gdy konieczne jest przeprowadzenie testów ad-hoc w celu uzyskania maksymalnej wartości, najlepiej jest ocenić doświadczony tester, który ma dogłębną wiedzę na temat testowanego systemu.

Kiedy nie wykonywać?

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

Chociaż ustaliliśmy, jak skuteczne i owocne mogą być testy ad hoc, jako wykwalifikowani i zdolni testerzy musimy również rozszyfrować, kiedy nie inwestować w tego typu testy. Chociaż jest to w gestii testera, tutaj są kilka zaleceń / przykładów, kiedy może to nie być konieczne.

  • Unikaj tego testowania, gdy istnieje przypadek testowy, dla którego istnieje defekt. W takiej sytuacji zachodzi potrzeba udokumentowania punktu awarii przypadku testowego, a następnie zweryfikowania / ponownego przetestowania defektu po jego naprawieniu. Dlatego nie będzie to miało zastosowania tutaj.
  • Mogą również istnieć pewne scenariusze, do których można zaprosić klientów lub klientów przetestuj wersję beta oprogramowania . W takich przypadkach nie należy przeprowadzać tego testu.
  • Innym scenariuszem jest dodanie bardzo prostego ekranu interfejsu użytkownika. Tradycyjne testy pozytywne i negatywne powinny tutaj wystarczyć, aby wydobyć maksymalne defekty.

Rodzaje testów ad hoc

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

# 1) Testowanie znajomych

W tej formie testowania będzie członek testowy i członek programistyczny, którzy zostaną wybrani do pracy nad tym samym modułem. Zaraz po programista kończy testy jednostkowe , the tester i programista siedzą razem i pracuj nad modułem. Ten rodzaj testowania umożliwia obejrzenie funkcji w szerszym zakresie dla obu stron.

Deweloper zyska perspektywę wszystkich różnych testów przeprowadzanych przez testera, a tester uzyska perspektywę tego, jaki jest nieodłączny projekt, który pomoże mu uniknąć projektowania nieprawidłowych scenariuszy, zapobiegając tym samym nieprawidłowym defektom. Pomoże to jednemu myśleć podobnie jak myśleć drugiemu.

# 2) Testowanie par

W tym teście dwóch testerów pracuje razem nad modułem z tą samą konfiguracją testową, która jest między nimi współdzielona. Pomysł stojący za tą formą testowania polegający na tym, aby dwaj testerzy przeprowadzili burzę mózgów nad pomysłami i metodami mającymi wiele defektów. Obaj mogą dzielić się pracą związaną z testowaniem i sporządzać niezbędną dokumentację wszystkich dokonanych obserwacji.

# 3) Testowanie na małpach

Testowanie to jest wykonywane głównie na poziomie testów jednostkowych. Tester analizuje dane lub testy w całkowicie losowy sposób, aby upewnić się, że system jest w stanie wytrzymać wszelkie awarie. Testy te można dalej podzielić na dwie kategorie:

Korzyści z testów ad hoc

Testowanie gwarantuje testerowi dużą moc bycia tak kreatywnym, jak to konieczne.

Selenium Webdriver pytania i odpowiedzi do wywiadu dla doświadczonych plików PDF

Zwiększa to jakość i wydajność testowania, jak poniżej:

  • Największą zaletą, która się wyróżnia, jest to, że tester może znaleźć liczbę defektów niż w tradycyjnym testowaniu ze względu na różne innowacyjne metody, które może zastosować do testowania oprogramowania.
  • Ta forma testowania może być zastosowana w dowolnym miejscu w SDLC; nie ogranicza się tylko do zespołu testującego. Programiści mogą również przeprowadzić te testy, które pomogłyby im lepiej kodować, a także przewidzieć, jakie problemy mogą wystąpić.
  • Można go połączyć z innym testem, aby uzyskać najlepsze wyniki, co czasami może skrócić czas potrzebny na regularne testy. Umożliwiłoby to generowanie przypadków testowych lepszej jakości i ogólnie lepszą jakość produktu.
  • Nie wymaga tworzenia żadnej dokumentacji, co zapobiega dodatkowemu obciążeniu testera. Tester może skoncentrować się na zrozumieniu podstawowej architektury.
  • W przypadkach, gdy nie ma dużo czasu na testowanie, może to okazać się bardzo cenne pod względem pokrycia testów i jakości.

Wady testowania ad hoc

Testowanie ad hoc ma również kilka wad. Rzućmy okiem na niektóre z wady, które są wyraźne:

Ponieważ nie jest bardzo zorganizowany i nie ma wymaganej dokumentacji, najbardziej oczywistym problemem jest to, że tester musi zapamiętać i przypomnieć sobie wszystkie szczegóły scenariuszy ad-hoc w pamięci. Może to być jeszcze trudniejsze, zwłaszcza w scenariuszach, w których występuje dużo interakcji między różnymi komponentami.

  • Wynikając z pierwszego punktu, spowodowałoby to również brak możliwości odtworzenia defektów w kolejnych próbach, jeśli zostaną poproszeni o informacje.
  • Innym bardzo ważnym pytaniem, które to ujawnia, jest odpowiedzialność za wysiłek. Ponieważ nie jest to zaplanowane / zorganizowane, nie ma sposobu, aby uwzględnić czas i wysiłek włożony w tego rodzaju testy.
  • Testowanie ad hoc musi być wykonywane tylko przez bardzo kompetentnego i wykwalifikowanego testera w zespole, ponieważ wymaga proaktywności i intuicji w zakresie przewidywania potencjalnych obszarów dotkniętych defektami.

Sprawdzone metody zwiększania skuteczności testów

Omówiliśmy szczegółowo mocne i słabe strony związane z tym testowaniem.

Idealnie byłoby, gdyby testowanie ad-hoc znalazło swoje miejsce w SDLC, jednak jeśli nie podejdzie się do niego w odpowiedni sposób, może się okazać kosztowne i stratą cennego czasu na testowanie. Poniżej przedstawiono kilka wskazówek, które sprawią, że testowanie ad hoc będzie skuteczne:

# 1) Zidentyfikuj obszary podatne na defekty:

Kiedy masz dobrą kontrolę nad testowaniem określonego oprogramowania, zgodzisz się, że istnieją pewne funkcje, które są bardziej podatne na błędy niż inne. Jeśli jesteś nowy w systemie, to śmiało sprawdź, jakie wady funkcji v / s są dla nich otwarte.

Liczba defektów w określonej funkcji pokaże, że jest ona wrażliwa i należy precyzyjnie wybrać ten obszar do przeprowadzenia testów ad hoc. Okazuje się, że jest to bardzo efektywny czasowo sposób na wyeksponowanie niektórych poważnych usterek.

# 2) Ekspertyza budowlana:

Niewątpliwie tester, który ma większe doświadczenie, jest bardziej intuicyjny i może odgadnąć, gdzie mogą być błędy, w porównaniu z kimś, kto nie ma dużego doświadczenia. Powiedziałbym, że z doświadczeniem czy nie, to od osoby zależy, czy zdecyduje się na zanurzenie się i zdobędzie wiedzę na temat testowanego systemu.

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

# 3) Utwórz kategorie testów:

Gdy znasz już listę funkcji do przetestowania, poświęć kilka minut na podjęcie decyzji, jak skategoryzować te funkcje i przetestować. Na przykład, powinieneś zdecydować się przetestować funkcje, które są najbardziej widoczne i najczęściej używane przez użytkownika, zanim cokolwiek innego, ponieważ wydaje się, że mają one kluczowe znaczenie dla sukcesu oprogramowania.

Następnie możesz sklasyfikować je pod względem funkcjonalności / priorytetów i przetestować je segment po segmencie.

Innym przykładem, w którym jest to szczególnie ważne, jest integracja między komponentami lub modułami. W takich przypadkach może wystąpić wiele nieprawidłowości. Kategoryzacja pomogłaby przynajmniej raz lub dwa razy dotknąć tego rodzaju testu.

# 4) Przygotuj zgrubny plan:

Tak, tak, ten punkt może Cię trochę zmylić, ponieważ opisaliśmy testowanie ad hoc jako testowanie, które nie powinno mieć planowania ani dokumentacji. Pomysł polega na tym, aby trzymać się istoty testów ad hoc, ale mimo to zapisać kilka ogólnych wskazówek dotyczących tego, 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ć. Tak więc zanotowanie ich zapewni, że niczego nie przegapisz.

# 5) Narzędzia:

Weźmy przykład, z którym bardzo często stykamy się wszyscy. Wiele razy, jeśli zaobserwujesz, testowanie samej funkcjonalności kończy się pomyślnie, bez zgłaszanych rozbieżności w jej działaniu. Jednak dzienniki za kulisami mogą zgłaszać pewne zauważone wyjątki, które testerzy mogliby przeoczyć, ponieważ w żaden sposób nie utrudniają realizacji celu testu.

Mogą być nawet bardzo dotkliwe. Dlatego bardzo ważne jest, abyśmy się nauczyli i narzędzi, które pomogą nam to natychmiast określić.

# 6) Dokument dla większej liczby defektów:

Znowu rozumiem, że to może znowu unieść brwi. Dokumentacja nie musi być szczegółowa, ale wystarczy krótka notatka dla własnego odniesienia na temat wszystkich różnych uwzględnionych scenariuszy, odchyleń w zaangażowanych krokach i odnotowanie tych defektów dla określonej kategorii funkcji testowych.

Pomoże ci to również ulepszyć ogólny przedział testowy, dzięki czemu możesz zdecydować, jak zaimprowizować istniejące przypadki testowe lub dodać więcej, jeśli to konieczne.

Wniosek

Omówiliśmy szczegółowo techniki testowania ad hoc - ich mocne i słabe strony oraz sytuacje, w których byłoby to lub nie byłoby korzystne.

Jest to jedna z technik testowania, która gwarantuje maksymalne zaspokojenie i zaspokojenie kreatywności testera. W całym moim kariera testowa , Największą satysfakcję dają mi testy ad-hoc, ponieważ nie ma ograniczeń co do wprowadzania innowacji, a w efekcie zyskujesz większą wiedzę.

Powiedziawszy to, najważniejszą rzeczą do cofnięcia ze wszystkich powyższych informacji byłoby określić, jak wykorzystać mocne strony testów ad hoc i zwiększyć wartość całego procesu testowania i jakości produktu.

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

Czy wykonujesz testy ad hoc w swoim projekcie? Jakie masz sugestie, aby testy ad hoc zakończyły się sukcesem?

rekomendowane lektury

^