Testowanie ad-hoc to rodzaj testowania oprogramowania, które deweloperzy i firmy programistyczne wdrażają podczas sprawdzania bieżącej iteracji oprogramowania. Ta forma testowania daje większy wgląd w program, lokalizując problemy, których konwencjonalne testy nie są w stanie uwypuklić.
Najważniejsze jest, aby zespoły testujące miały pełne zrozumienie procesu testowania ad hoc, aby wiedziały jak obejść jego wyzwania i upewnić się, że zespół może z powodzeniem wdrożyć tę technikę.
Wiedza o tym, jak dokładnie działa testowanie ad-hoc i jakie narzędzia mogą ułatwić jego realizację, pozwala firmie na ciągłe doskonalenie własnych procedur zapewniania jakości. Formalny proces testowania przebiega według bardzo konkretnych zasad, co może spowodować, że zespół przegapi pewne błędy – kontrole ad hoc mogą ominąć te ślepe miejsca i szybko przetestować każdą funkcję oprogramowania.
W tym artykule dokładnie przeanalizujemy testy ad-hoc i jak można je wykorzystać na swoją korzyść podczas tworzenia oprogramowania.
Testy Ad-Hoc znaczenie: Co to jest Testy Ad-Hoc.
Testowanie ad-hoc jest procesem zapewnienia jakości, który unika formalnych zasad i dokumentacji – pomaga testerom znaleźć błędy w aplikacji, których konwencjonalne podejścia nie są w stanie zidentyfikować. Zazwyczaj wymaga to kompleksowej wiedzy o oprogramowaniu przed rozpoczęciem testów – w tym zrozumienia wewnętrznego działania programu. Te doraźne kontrole mają na celu złamanie aplikacji w sposób, który odzwierciedla dane wprowadzone przez użytkownika, rozliczając się z różnych potencjalnych sytuacji, dzięki czemu programiści mogą naprawić wszelkie istniejące problemy.
Brak dokumentacji jest kluczowy dla tej techniki, która nie zawiera żadnej listy kontrolnej ani przypadków testowych, które prowadziłyby testerów przez funkcje aplikacji. Testowanie ad-hoc polega w całości na testowaniu oprogramowania w taki sposób, jaki zespół uzna za efektywny w danym momencie. Może to uwzględniać istniejące wcześniej testy formalne, ale może też po prostu obejmować przeprowadzenie jak największej liczby testów w (prawdopodobnie ograniczonym) czasie, który jest przeznaczony na tę technikę.
1. Kiedy i dlaczego należy wykonywać testy Ad-Hoc w testowaniu oprogramowania?
Głównym powodem, dla którego firmy przeprowadzają testy ad-hoc, jest ich zdolność do odkrywania błędów, których tradycyjne podejścia nie są w stanie znaleźć. Może to być spowodowane dowolną liczbą powodów, takich jak konwencjonalne przypadki testowe po szczególnie znormalizowanym procesie, który nie może uwzględnić idiosynkrazji aplikacji.
Każdy rodzaj testowania może zaoferować nowe perspektywy i ciekawe podejście do zapewnienia jakości – pokazuje to również problemy ze zwykłą strategią testowania. Na przykład, jeśli testowanie ad-hoc może zidentyfikować problem, którego nie uwzględniają przypadki testowe zespołu, sugeruje to, że mogliby oni skorzystać z rekalibracji swojej metodologii testowania.
Testerzy mogą przeprowadzać kontrole ad-hoc w dowolnym momencie procesu testowania. Zazwyczaj służy to jako uzupełnienie tradycyjnego (i bardziej formalnego) zapewnienia jakości i, mając to na uwadze, testerzy mogą wykonywać kontrole ad hoc, podczas gdy ich koledzy przeprowadzają bardziej formalne badania. Jednak zamiast tego mogą oni preferować zachowanie kontroli ad-hoc do czasu po formalnym procesie testowania jako kontynuację, która w sposób szczególny ukierunkowana jest na potencjalne ślepe punkty.
Testy ad-hoc mogą być również przydatne, gdy czas jest szczególnie ograniczony ze względu na brak dokumentacji – właściwy moment zależy od firmy i preferowanego przez nią podejścia.
2. Kiedy nie trzeba przeprowadzać testów Ad-Hoc
Jeśli nie ma wystarczającej ilości czasu na przeprowadzenie zarówno testów ad-hoc, jak i formalnych, ważne jest, aby zespół nadał priorytet tym drugim, ponieważ zapewniają one znaczne pokrycie testami – nawet jeśli nadal istnieją pewne luki.
Jeśli formalne testy zespołu znajdą błędy, które wymagają naprawy, generalnie lepiej jest poczekać, aż deweloperzy zakończą niezbędne zmiany, aby wprowadzić kontrole ad-hoc. W przeciwnym razie wyniki, które dostarczają, mogą wkrótce stać się nieaktualne, zwłaszcza jeśli testy dotyczą komponentu, w którym już występują błędy.
Oprócz tego przed etapem beta testów musi dojść do testów ad-hoc.
3. Kto bierze udział w testowaniu Ad-Hoc?
W procesie testowania Ad-Hoc bierze udział kilka kluczowych ról, w tym:
– Testerzy oprogramowania są głównymi członkami zespołu, którzy przeprowadzają kontrole ad hoc. Jeśli przeprowadzamy testowanie w parach, to kilku testerów będzie pracować razem nad tymi samymi komponentami.
– Programiści mogą niezależnie używać tych kontroli przed formalnym etapem zapewniania jakości, aby szybko sprawdzić własne oprogramowanie, choć jest to mniej dogłębne niż dedykowane testy ad-hoc.
– Liderzy zespołów lub działów autoryzują ogólną strategię testowania – pomagając testerom określić, kiedy rozpocząć testowanie ad-hoc i jak je przeprowadzić bez zakłócania innych kontroli.
Korzyści z testów ad hoc
Do zalet testów ad-hoc w testowaniu oprogramowania należą:
1. Szybkie uchwały
Ponieważ testy te nie wymagają częstej dokumentacji przed, w trakcie i po sprawdzeniu, zespoły mogą znacznie szybciej identyfikować problemy. Ta prostota daje ogromną swobodę testerom.
Na przykład, jeśli testują komponent i nie mogą zidentyfikować żadnych błędów, zespół może po prostu przejść do następnego testu bez odnotowania tego w dokumencie.
2. Uzupełnia inne rodzaje badań
Żadna strategia testowania nie jest idealna, a 100% pokrycie jest zwykle niemożliwe do osiągnięcia – nawet przy kompleksowym harmonogramie. W konwencjonalnych badaniach zawsze będą braki, dlatego ważne jest, aby firmy integrowały wiele podejść.
Testowanie ad-hoc ma na celu znalezienie problemów, których formalne testowanie nie może objąć – gwarantując szersze ogólne pokrycie testów.
3. Elastyczna realizacja
Testy ad-hoc mogą mieć miejsce w dowolnym momencie procesu zapewnienia jakości przed testami beta, pozwalając firmom i zespołom zdecydować, kiedy najlepiej wykonać te kontrole. Mogą zdecydować się na przeprowadzenie testów ad-hoc w parze z testami konwencjonalnymi lub mogą poczekać do późniejszego terminu – bez względu na to, zespół korzysta z wyborów, które ma do dyspozycji.
4. Większa współpraca
Deweloperzy są bardziej zaangażowani w ten proces niż w wiele innych form testowania – zwłaszcza jeśli firma używa testów kumpelskich i par.
W rezultacie deweloperzy uzyskują lepszy wgląd we własne aplikacje i mogą być w stanie zająć się błędami w wyższym standardzie. Pomaga to jeszcze bardziej poprawić ogólną jakość oprogramowania.
5. Różnorodne perspektywy
Testy ad-hoc mogą pokazać aplikację z nowych kątów, pomagając testerom zaangażować się w te funkcje na nowe sposoby. Dodatkowe perspektywy są krytyczne podczas testowania, ponieważ formalne kontrole często mają przynajmniej niewielkie luki.
Jeśli testerzy ad-hoc używają oprogramowania z konkretnym zamiarem złamania go, będą mogli łatwiej wskazać ograniczenia programu.
Wyzwania związane z testami ad hoc
Proces testowania ad hoc ma również kilka wyzwań, takich jak:
1. Trudności z raportowaniem
Brak dokumentacji sprawia, że testowanie ad-hoc jest znacznie szybsze, ale może również utrudnić raportowanie w przypadku czegokolwiek innego niż poważny problem.
Na przykład, jedna z wcześniej przeprowadzonych kontroli może stać się bardziej istotna w późniejszym terminie, mimo że początkowo nie przyniosła znaczących wyników. Bez wyczerpującej dokumentacji zespół może nie być w stanie wyjaśnić tych testów.
2. Mniejsza powtarzalność
Podobnie, testerzy mogą nie być w pełni świadomi dokładnych warunków niezbędnych do wywołania obserwowanych przez nich reakcji. Na przykład kontrola ad hoc, która zwraca błąd, może nie mieć wystarczających informacji dla zespołu, aby podjąć działania. Mogą być nieświadomi, jak powtórzyć ten test i uzyskać ten sam wynik.
3. Wymaga doświadczenia w zakresie oprogramowania
Ponieważ szybkość jest kluczowa w całym testowaniu ad-hoc i zwykle wiąże się z próbą złamania aplikacji, ważne jest, aby ci testerzy mieli intymne zrozumienie tego programu.
Wiedza o tym, jak działa, pozwala testerom na łamanie i manipulowanie oprogramowaniem na więcej sposobów, ale to może znacznie zwiększyć wymagania dotyczące umiejętności dla testów ad hoc.
4. Ograniczona odpowiedzialność
Brak dokumentacji może powodować więcej problemów niż tylko złe raportowanie; może również nieumyślnie wydłużyć proces testowania, wpływając na użyteczność szybkich indywidualnych testów ad-hoc.
Testerzy mogą mieć trudności ze śledzeniem swoich postępów bez wystarczającej dokumentacji na każdym etapie. Może to nawet doprowadzić do tego, że będą oni powtarzać kontrolę, którą inni testerzy już zakończyli.
5. Może nie odzwierciedlać doświadczenia użytkownika
Celem praktycznie każdego rodzaju testów jest uwzględnienie błędów, które w jakiś sposób wpływają na użytkowników końcowych. Testowanie ad-hoc polega przede wszystkim na tym, że doświadczony tester próbuje naśladować niedoświadczonego użytkownika i powinno to być spójne w każdym sprawdzaniu, aż do i włącznie z próbami złamania aplikacji.
Charakterystyka testów ad hoc
Do głównych cech udanych testów ad hoc należą:
1. Investigative
Głównym priorytetem testów ad-hoc jest identyfikacja błędów z aplikacją przy użyciu technik, których konwencjonalne kontrole nie uwzględniają. Badania ad hoc przeszukują to oprogramowanie w celu znalezienia dziur w procedurze testowania zespołu, w tym pokrycia ich przypadków testowych.
2. Nieustrukturyzowana
Kontrole ad hoc zazwyczaj nie mają ustalonego planu poza przeprowadzeniem jak największej liczby testów poza typowymi granicami formalnego zapewnienia jakości. Testerzy zazwyczaj grupują kontrole według komponentów dla wygody, ale nawet to nie jest konieczne – mogą nawet wymyślać kontrole podczas ich wykonywania.
3. Kierowanie się doświadczeniem
Testerzy ad hoc wykorzystują swoje wcześniejsze doświadczenie z oprogramowaniem, aby ocenić, które testy przyniosłyby największe korzyści i zająć się typowymi ślepymi punktami w testach formalnych.
Choć proces testowania jest nadal w pełni nieustrukturyzowany, to testerzy, decydując o swojej strategii, wykorzystują wiedzę m.in. z poprzednich kontroli ad hoc.
4. Szeroko pojęte
Nie ma dokładnych wytycznych co do tego, jakie kontrole powinien przeprowadzić zespół podczas testów ad-hoc, ale zazwyczaj obejmują one szereg komponentów – być może z większym naciskiem na bardziej wrażliwe aspekty aplikacji. Pomaga to testerom zagwarantować, że ich badania są w stanie w pełni uzupełnić formalne testy.
Co testujemy w ramach testów Ad-Hoc?
Zespoły zapewnienia jakości zwykle testują następujące elementy podczas testów ad hoc:
1. Jakość oprogramowania
Kontrole te mają na celu zidentyfikowanie błędów w aplikacji, których konwencjonalne testy nie są w stanie odkryć; oznacza to, że proces testuje głównie ogólny stan aplikacji.
Im więcej błędów, które testy ad-hoc mogą zlokalizować, tym więcej ulepszeń deweloperzy mogą wdrożyć przed terminem.
2. Przypadki testowe
Testy ad-hoc zazwyczaj nie implementują przypadków testowych – i to specjalnie po to, aby zespół mógł zbadać, jak efektywnie są one w stanie zapewnić szerokie pokrycie. Przypadki testowe są prawdopodobnie nieodpowiednie, jeśli kontrole ad hoc mogą znaleźć błędy, których konwencjonalne procesy testowania nie mogą.
3. Personel przeprowadzający badania
Celem może być również sprawdzenie umiejętności i wiedzy zespołu testującego, nawet jeśli przypadki testowe są odpowiednie. Na przykład, ich metodologia implementacji przypadków może być niewystarczająca, a testowanie ad-hoc może być krytyczne dla rozwiązania powstałych luk w pokryciu testowym.
4. Limity oprogramowania
Testy ad-hoc mają również na celu zrozumienie ograniczeń aplikacji – takich jak sposób, w jaki reaguje ona na nieoczekiwane wejścia lub duże obciążenia systemu. Testerzy mogliby konkretnie badać komunikaty o błędach programu i to, jak dobrze ta aplikacja radzi sobie pod znaczną presją.
Wyjaśnienie pewnych nieporozumień:
Testy ad hoc i testy eksploracyjne
Niektórzy uważają, że testy ad-hoc i eksploracyjne są synonimami, choć prawda jest bardziej skomplikowana.
1. Czym jest testowanie eksploracyjne?
Testowanie eksploracyjne odnosi się do procedur zapewnienia jakości, które badają oprogramowanie z holistycznego punktu widzenia i w szczególności łączą procesy odkrywania i testowania w jedną metodę. Jest to zazwyczaj środek pomiędzy w pełni ustrukturyzowanymi testami a całkowicie swobodnymi kontrolami ad-hoc.
Testy eksploracyjne sprawdzają się najlepiej w specyficznych scenariuszach, np. gdy potrzebna jest szybka informacja zwrotna lub gdy zespół musi zająć się przypadkami brzegowymi. Ten rodzaj testów zazwyczaj osiąga swój pełny potencjał, gdy zespół stosuje obok niego testy skryptowe.
2. Różnice między testami eksploracyjnymi
i badania ad hoc
Największą różnicą pomiędzy testami ad-hoc i eksploracyjnymi jest używanie przez te pierwsze dokumentacji do rejestrowania i ułatwiania sprawdzania, podczas gdy testy ad-hoc całkowicie tego unikają. Testy eksploracyjne kładą większy nacisk na swobodę testowania, ale nigdy do tego samego poziomu, co podejście ad-hoc, które jest całkowicie niestrukturalne.
Testy eksploracyjne polegają również na poznawaniu aplikacji i jej wewnętrznego działania podczas tych kontroli – testerzy ad hoc zamiast tego często posiadają kompleksową wiedzę na temat funkcjonalności oprogramowania przed rozpoczęciem pracy.
Rodzaje testów ad hoc
W testowaniu oprogramowania wyróżnia się trzy główne formy testów ad hoc, w tym:
1. Badanie na małpach
Być może najbardziej popularny rodzaj testów ad-hoc, małpie testy to te, które obejmują zespół losowo patrząc na różne komponenty.
Zazwyczaj odbywa się to podczas procesu testowania jednostkowego i wykonuje serię kontroli bez żadnych przypadków testowych. Testerzy niezależnie badają dane w całkowicie nieustrukturyzowany sposób, co pozwala im zbadać szerszy system i jego zdolność do oparcia się intensywnym obciążeniom wynikającym z danych wprowadzanych przez użytkowników.
Obserwowanie wyjścia tych nieopisanych technik pomaga zespołowi testującemu zidentyfikować błędy, które inne testy jednostkowe przeoczyły z powodu braków w konwencjonalnych metodach testowania.
2. Testy koleżeńskie
W kontekście ad-hoc, testy kumpelskie wykorzystują minimum dwóch pracowników – zazwyczaj testera i dewelopera – i przede wszystkim odbywają się po etapie testów jednostkowych. Kumple” pracują razem na tym samym module, aby wskazać błędy. Ich zróżnicowane zestawy umiejętności i wszechstronne doświadczenie sprawiają, że są bardziej efektywnym zespołem, co pomaga złagodzić wiele problemów, które pojawiają się z powodu braku dokumentacji.
Deweloper może nawet zasugerować kilka testów, pozwalając im zidentyfikować komponenty, które mogą wymagać większej uwagi.
3. Badanie parami
Testowanie w parach jest podobne w tym, że angażuje dwóch pracowników, ale jest to zazwyczaj dwóch oddzielnych testerów, z których jeden wykonuje rzeczywiste testy, podczas gdy drugi robi notatki.
Nawet bez formalnej dokumentacji, sporządzanie notatek może pozwolić zespołowi na nieformalne śledzenie poszczególnych kontroli ad hoc. Role testera i skryby mogą się zmieniać w zależności od testu lub para może zachować swoje przypisane role przez cały proces.
Tester, który ma większe doświadczenie, jest zazwyczaj tym, który przeprowadza faktyczne kontrole – choć zawsze dzielą się pracą między sobą.
Testy ręczne czy automatyczne Ad-Hoc?
Automatyzacja testów może pomóc zespołom zaoszczędzić jeszcze więcej czasu na etapie zapewniania jakości, co pozwala testerom zmieścić więcej kontroli w swoim harmonogramie. Nawet bez określonej struktury, istotne jest, aby testerzy pracowali nad maksymalizacją pokrycia, a automatyzacja zachęca do bardziej dogłębnych inspekcji tego oprogramowania.
Zautomatyzowane kontrole ad-hoc są zazwyczaj bardziej dokładne niż testy manualne ze względu na możliwość uniknięcia błędów ludzkich podczas wykonywania zadań rutynowych – jest to szczególnie pomocne w przypadku wykonywania tych samych testów na różnych iteracjach. Sukces tej procedury zależy zwykle od narzędzia do testów automatycznych, które zespół wybiera i jego funkcjonalności.
Testy automatyczne mają jednak pewne ograniczenia. Na przykład, główną siłą testów ad-hoc jest ich zdolność do emulowania danych wejściowych użytkownika i uchwalania losowych kontroli, gdy tester je wymyśli. Testy te mogą stracić swoją losowość, jeśli program testowy organizacji zmaga się ze złożonymi kontrolami.
Czas potrzebny na zautomatyzowanie tych wysoce specyficznych zadań może również ograniczyć typowe oszczędności czasu tego procesu. Ważne jest, aby zespoły dokładnie zbadały dostępne narzędzia do automatyzacji, aby znaleźć takie, które pasuje do projektu ich firmy.
Czego potrzebujesz, aby rozpocząć Ad-Hoc Testing?
Oto główne przesłanki testowania ad hoc:
1. Wykwalifikowany personel
Ponieważ testy ad-hoc są szybkimi, losowymi inspekcjami wewnętrznego działania oprogramowania, zazwyczaj pomocne jest posiadanie testerów, którzy mają doświadczenie z oprogramowaniem. Powinni również posiadać praktyczną wiedzę na temat kluczowych zasad testowania – to pozwala im łatwo zidentyfikować najbardziej efektywne kontrole.
2. Podejście niestrukturalne
Testerzy muszą być skłonni do porzucenia swoich zwykłych strategii testowania ad hoc; ten sposób myślenia jest równie krytyczny jak same kontrole jakości. Ta metoda może się udać tylko bez struktury i dokumentacji i ważne jest, aby testerzy pamiętali o tym na każdym etapie.
3. Oprogramowanie do automatyzacji
Chociaż testy ad-hoc polegają bardziej na testowaniu losowych wejść i warunków, automatyzacja jest nadal bardzo skuteczną techniką w każdym kontekście.
Z tego powodu kontrole ad hoc powinny nadal wdrażać narzędzia do automatycznego testowania w miarę możliwości, ponieważ odpowiednia aplikacja może znacznie usprawnić proces.
4. Inne formy badań
Testy ad-hoc działają najlepiej obok innych kontroli, które przyjmują bardziej formalne podejście – pomagając zespołowi zagwarantować znaczne pokrycie całego oprogramowania. Ważne jest, aby testerzy mieszali różne techniki, choć może to być przed, w trakcie lub po wykonaniu testów ad-hoc.
Proces testowania ad hoc
Zwykle kroki, które testerzy powinni wykonać, gdy wykonują testy ad hoc w testowaniu oprogramowania, to:
1. Definiowanie celów testów ad hoc
Ten etap jest ograniczony ze względu na brak dokumentacji i struktury, ale nadal najważniejsze jest, aby zespół miał jasno określony cel. Testerzy mogą zacząć dzielić się niejasnymi pomysłami na temat tego, które z nadchodzących testów należy przeprowadzić i jakie komponenty potraktować priorytetowo.
2. Wybór zespołu testującego ad hoc
Podczas gdy zespół tworzy burzę mózgów na temat wielu potencjalnych kontroli ad-hoc, zastanawia się również, którzy testerzy byliby najlepsi do tego typu testów. Zazwyczaj wybierają testerów, którzy dokładnie rozumieją aplikację i mogą również sparować ich z deweloperem.
3. Wykonywanie testów ad hoc
Po podjęciu decyzji, którzy testerzy są odpowiedni dla tego etapu, ci członkowie zespołu rozpoczynają swoje kontrole w uzgodnionym punkcie testów. Ich celem jest wykonanie jak największej ilości kontroli ad hoc – których testerzy mogą nie wymyślić do tego etapu.
4. Ocena wyników badań
Po zakończeniu testów (lub nawet pomiędzy poszczególnymi sprawdzeniami) testerzy oceniają wyniki, ale bez formalnego dokumentowania ich w przypadku testowym. Jeśli odkryją jakieś problemy z aplikacją, zapisują je nieformalnie i omawiają kolejne kroki zespołu.
5. Zgłaszanie wszelkich odkrytych błędów
Po ocenie wyników, testerzy muszą poinformować deweloperów o błędach obecnych w oprogramowaniu, aby mieli wystarczająco dużo czasu na ich naprawienie przed wydaniem.
Zespół testowy wykorzystuje również informacje do określenia, jak poprawić swoje formalne procesy testowe.
6. Ponowne badania w razie potrzeby
Zespół testujący prawdopodobnie powtórzy proces ad-hoc dla nowych iteracji aplikacji, aby sprawdzić, jak dobrze obsługuje aktualizacje. Ponieważ testerzy naprawili wiele z wcześniej zidentyfikowanych luk w swoich przypadkach testowych, przyszłe kontrole ad-hoc mogą wymagać innego podejścia.
Najlepsze praktyki w zakresie testów ad hoc
Istnieją pewne praktyki, które zespoły testujące powinny wdrożyć podczas testów ad-hoc, w tym:
1. Wykrycie potencjalnych braków w badaniach
Podczas gdy testowanie ad-hoc wiąże się ze znacznie mniejszym planowaniem niż inne rodzaje, zespół nadal ma na celu wyeliminowanie niedociągnięć w zapewnianiu jakości. Jeśli testerzy ad-hoc podejrzewają jakieś konkretne problemy z przypadkami testowymi zespołu, powinni nadać temu priorytet podczas przeprowadzania swoich kontroli.
2. Rozważ oprogramowanie do automatyzacji
Strategie automatyzacji, takie jak hiperautomatyzacja, mogą zaoferować wiele korzyści firmom chcącym przeprowadzać testy ad-hoc.
Sukces tego zależy od kilku kluczowych czynników, w tym od narzędzia, które wybiera firma, a także od ogólnej złożoności ich testów ad-hoc.
3. Rób wyczerpujące notatki
Brak dokumentacji w testach ad-hoc ma na celu głównie jeszcze większe usprawnienie tego procesu – zespół mógłby skorzystać z robienia nieformalnych notatek w miarę postępowania. Daje to testerom jasny zapis tych kontroli i ich wyników, zwiększając ich ogólną powtarzalność.
4. Ciągle udoskonalaj testy
Testerzy ad-hoc stale udoskonalają swoje podejście, aby uwzględnić zmiany w strategii testowania zespołu. Na przykład, gdy przyjrzą się nowszym wersjom oprogramowania firmy, mogą dostosować te kontrole w odpowiedzi na nowsze i bardziej integracyjne formalne przypadki testowe.
7 błędów i pułapek we wdrażaniu
Testy ad hoc
Jak w przypadku każdego procesu testowania, istnieje szeroki zakres potencjalnych błędów, nad którymi zespół powinien pracować, aby uniknąć, takich jak:
1. Niedoświadczeni testerzy
Aby utrzymać oczekiwane tempo testów ad hoc, lider zespołu musi przydzielić testerów na podstawie wiedzy i umiejętności, które posiadają. Podczas gdy wiele form testów może pomieścić personel zapewniający jakość na poziomie podstawowym, kontrole ad hoc wymagają członków zespołu, którzy w pełni rozumieją oprogramowanie; najlepiej z doświadczeniem w prowadzeniu tych testów.
2. Kontrole nieostre
Testowanie ad-hoc może znacznie poprawić pokrycie testów ze względu na jego szybsze tempo – zespół nie musi wypełniać obszernej dokumentacji przed i po każdym sprawdzeniu.
Jednak testerzy ad hoc muszą nadal utrzymywać silne skupienie; na przykład mogą zdecydować o nadaniu priorytetu pewnym komponentom o większym ryzyku awarii.
3. Brak planowania
Unikanie jakiegokolwiek planu może ograniczyć skuteczność testów ad hoc. Pomimo nieuporządkowanej natury tego podejścia, ważne jest, aby zespół miał przybliżone pojęcie o tym, które testy należy uruchomić przed rozpoczęciem.
Czas podczas tego procesu jest ograniczony, a wiedza o tym, jak postępować, może przynieść wiele korzyści.
4. Nadmierna struktura
Na przeciwnym końcu spektrum, to podejście zazwyczaj opiera się na braku planowania, ponieważ pomaga to testerom aktywnie wywrócić przypadki testowe i znaleźć ukryte błędy.
Testowanie ad hoc jest również znane jako testowanie losowe i wymuszanie na nim struktury może uniemożliwić tym kontrolom znalezienie błędów.
5. Brak długoterminowych zmian
Celem testów ad-hoc jest zidentyfikowanie wszelkich słabości w przypadkach testowych zespołu; bada to ich ogólną strategię tak samo jak samo oprogramowanie.
Oznacza to jednak, że testy ad-hoc są na ogół skuteczne tylko wtedy, gdy zespół wykorzystuje te informacje do udoskonalenia swoich formalnych kontroli w czasie.
6. Niezgodne zestawy danych
Praktycznie każda forma testowania wymaga jakiejś formy symulowanych danych, aby ocenić, jak aplikacja reaguje; niektóre narzędzia pozwalają testerom na automatyczne wypełnienie programu wyśmiewanymi danymi.
Może to jednak nie odzwierciedlać sposobu, w jaki użytkownik korzystałby z oprogramowania – kontrole ad hoc wymagają zestawów danych, z którymi oprogramowanie prawdopodobnie się spotka.
7. Silosy informacyjne
Istotne jest, aby testerzy i deweloperzy byli ze sobą w stałej komunikacji, nawet jeśli ten drugi nie jest częścią procesu testowania ad-hoc.
Pomaga to wszystkim zrozumieć, które testy zostały przeprowadzone – wskazując kolejne działania do podjęcia, a także zapobiegając niepotrzebnemu powtarzaniu pewnych kontroli przez testerów.
Rodzaje danych wyjściowych z testów ad hoc
Kontrole ad hoc dają kilka odrębnych wyników, w tym:
1. Wyniki badań
Poszczególne testy dają różne wyniki specyficzne dla danego komponentu i podejścia – może to przybrać wiele form.
Zazwyczaj to tester jest odpowiedzialny za określenie, czy wyniki stanowią błąd, chociaż brak dokumentacji utrudnia porównanie tego z ich oczekiwaniami. Zespół przekazuje te wyniki deweloperom, jeśli zauważy jakieś problemy.
2. Dzienniki badań
Samo oprogramowanie wykorzystuje skomplikowany system wewnętrznych dzienników, aby monitorować dane wprowadzane przez użytkownika i podkreślać szereg problemów z plikami lub bazami danych, które mogą się pojawić.
Może to wskazywać na wewnętrzny błąd, w tym konkretną część oprogramowania powodującą problem. Dzięki tym informacjom testerzy ad-hoc i programiści mogą znacznie łatwiej zająć się odkrytymi przez siebie problemami.
3. Komunikaty o błędach
Wiele kontroli ad-hoc ma na celu złamanie oprogramowania i ujawnienie jego ograniczeń, co oznacza, że komunikaty o błędach aplikacji są jednym z najczęstszych wyjść z tych testów.
Poprzez celowe wywoływanie komunikatów o błędach zespół może pokazać, co widzi przeciętny użytkownik końcowy, gdy podejmowane przez niego nieoczekiwane działania mają negatywny wpływ na działanie programu.
Przykłady testów Ad-Hoc
Oto trzy scenariusze testów ad-hoc, które pokazują, jak zespół może je wdrożyć dla różnych aplikacji:
1. Aplikacja internetowa e-commerce
Jeśli firma chce przetestować aplikację internetową opartą na handlu elektronicznym, może użyć testów ad-hoc – a konkretnie testów małp – aby sprawdzić, jak dobrze platforma radzi sobie z nieoczekiwanymi interakcjami użytkownika.
Celem testerów może być doprowadzenie każdej funkcji do granic możliwości, np. poprzez dodawanie przedmiotów do koszyka w nierealnych ilościach lub próby zakupu produktów, których nie ma w magazynie. Nie są oni ograniczeni przez przypadki testowe zespołu i istnieje niewiele ograniczeń co do kontroli, które mogą wykonać; testerzy mogą nawet próbować dokonać zakupów przy użyciu przestarzałych adresów URL.
2. Aplikacja desktopowa
Testerzy ad-hoc mogą również zaimplementować te techniki dla aplikacji desktopowych z ewentualnym skupieniem się na różnych maszynach i tym, jak dobrze każda z nich mieści program.
Członkowie zespołu mogą wykonywać te kontrole wielokrotnie, aby zobaczyć, jak zmiana ustawień sprzętu lub oprogramowania wpływa na ogólną wydajność aplikacji. Na przykład konkretna karta graficzna może mieć problemy z renderowaniem interfejsu.
Alternatywnie, ci testerzy mogliby po prostu dać swojemu programowi niemożliwe dane wejściowe i zobaczyć, jak reaguje, np. czy potrafi poprawnie wyświetlić komunikaty o błędach, które odpowiednio wyjaśniają problem użytkownikowi końcowemu.
3. Aplikacja mobilna
Jednym ze sposobów, w jaki testerzy ad-hoc mogliby zbadać aplikację mobilną, jest sprawdzenie jej protokołów bezpieczeństwa – mogliby na przykład spróbować uzyskać bezpośredni dostęp do narzędzi programistycznych aplikacji.
Zespół może spróbować sprawdzić, czy jest w stanie wykonać nieautoryzowane działania poprzez znalezienie wspólnych luk i exploitów; może specjalnie poprosić pracowników z doświadczeniem w bezpieczeństwie aplikacji, aby to ułatwić.
Może to również obejmować testowanie w parach z deweloperami ze względu na ich wgląd w projekt aplikacji, pozwalając testerowi złamać oprogramowanie i pokazać dokładnie, gdzie brakuje jego bezpieczeństwa.
Rodzaje wykrytych błędów i usterek
poprzez testy Ad-Hoc
Kontrole ad hoc mogą odkryć wiele problemów z programem, takich jak:
1. Błędy funkcjonalności
Użycie testów ad-hoc do zbadania podstawowych funkcji aplikacji może ujawnić poważne błędy, które wpływają na sposób, w jaki użytkownicy końcowi mogą się z nią związać.
Na przykład, małpka testująca opcje płatności w witrynie e-commerce zilustruje warunki, które uniemożliwiają transakcję.
2. Kwestie związane z wydajnością
Testerzy mogą specjalnie pracować nad stworzeniem problemów z wydajnością programu – na przykład poprzez wypełnienie bazy danych różnymi wejściami spamowymi.
Może się to objawiać znacznym opóźnieniem lub nawet ogólną niestabilnością oprogramowania, co prawdopodobnie doprowadzi do (potencjalnie ogólnosystemowej) awarii.
3. Problemy z użytecznością
Kontrole te mogą również ujawnić błędy w interfejsie i ogólnym doświadczeniu użytkownika. Na przykład interfejs aplikacji mobilnej może wyglądać inaczej w innym systemie operacyjnym lub rozdzielczości ekranu. Słaby interfejs może sprawić, że użytkownicy będą mieli problemy z obsługą tej aplikacji.
4. Wady bezpieczeństwa
Losowa natura testów ad-hoc pozwala na objęcie nimi szeregu powszechnych i rzadkich problemów bezpieczeństwa; tester może użyć tych kontroli do znalezienia administracyjnych backdoorów programu.
Ewentualnie ich kontrola może wykazać, że oprogramowanie nie posiada szyfrowania danych.
Wspólne metryki testów ad-hoc
Testy ad-hoc wykorzystują różne metryki ułatwiające uzyskanie wyników, w tym:
1. Skuteczność wykrywania wad
Ta metryka pokazuje, jak efektywny jest proces testowania w znajdowaniu defektów w każdej formie testowania, włączając w to testowanie ad-hoc. Skuteczność wykrywania defektów to procent wykrytych defektów podzielony przez całkowitą liczbę zagadnień – pokazujący jak skuteczne są testy.
2. Wskaźnik pokrycia badania
Pomocniczą funkcją testów ad-hoc jest zwiększenie pokrycia poprzez sprawdzenie komponentów w sposób, którego przypadki testowe nie uwzględniają. Oznacza to, że testerzy będą również dążyć do radykalnego zwiększenia pokrycia testowego w każdej kontroli, tak bardzo jak tylko mogą.
3. Całkowity czas trwania badania
Testowanie ad-hoc jest znacznie szybsze niż inne procesy zapewniania jakości – i konieczne jest, aby testerzy pracowali nad utrzymaniem tej przewagi. Metryki czasu trwania testów pokazują członkom zespołu, jak mogą zaoszczędzić czas i jeszcze bardziej potęgować zalety strategii ad hoc.
4. Wskaźnik wypadków
Testy te często mają na celu złamanie oprogramowania i spowodowanie awarii lub poważnego błędu – pozwalając im wyjść poza typowe strategie testowe i znaleźć nieoczekiwane problemy. W tym celu pomocna może być wiedza, jak często oprogramowanie ulega awarii i co powoduje te problemy.
5 najlepszych narzędzi do testów ad hoc
Istnieje wiele darmowych i płatnych narzędzi testowych dostępnych do testowania ad-hoc w testowaniu oprogramowania – najlepsza piątka jest następująca:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST to kompleksowy program do testowania oprogramowania, który zapewnia silny poziom funkcjonalności testów + RPA zarówno w wersji darmowej, jak i korporacyjnej.
Ta pełna automatyzacja oprogramowania + RPA Suite pozwala na pełne testowanie na różnych platformach desktopowych i mobilnych; technologia 1SCRIPT oprogramowania pozwala również użytkownikom na wielokrotne wykonywanie tych samych kontroli z łatwością. Ponadto narzędzie wykorzystuje najnowocześniejszą wizję komputerową, dzięki czemu ZAPTEST może przeprowadzać testy ad-hoc z perspektywy człowieka.
2. BrowserStack
BrowserStack to platforma chmurowa, która może ułatwić testowanie na ponad 3000 zróżnicowanych maszyn, z dodatkową funkcją automatyzacji skryptów Selenium. Chociaż zapewnia silne pokrycie dla projektów programistycznych, najlepiej sprawdza się w przypadku aplikacji przeglądarkowych i mobilnych.
Rozwiązania testowe BrowserStack obejmują również bezpłatną próbę ze 100 minutami automatycznych testów – choć może to mieć ograniczone zastosowanie.
Choć podejście oparte na chmurze może być pomocne, wpływa również negatywnie na czas reakcji platformy.
3. LambdaTest
LambdaTest podobnie korzysta z technologii opartej na chmurze i kładzie duży nacisk na testowanie w przeglądarce, co może ograniczać jego skuteczność w przypadku innych aplikacji – choć nadal dobrze zazębia się z programami na iOS i Androida. Jest to pomocna platforma, gdy skalowalność jest problemem i integruje się z wieloma innymi usługami hostingu testowego.
Jednak niektórzy użytkownicy mają mieszane reakcje na ceny aplikacji w różnych dostępnych opcjach nietestowych, co potencjalnie ogranicza dostępność dla mniejszych organizacji.
4. TestRail
TestRail jest ogólnie dość elastyczny dzięki temu, że działa całkowicie w przeglądarce i pomimo silnego nacisku na wydajne przypadki testowe, może również pochwalić się bezpośrednią funkcjonalnością ad-hoc. Analityka, którą dostarcza po każdym teście, może również pomóc zespołom, które aktywnie unikają tworzenia własnej, niezależnej dokumentacji, jednocześnie pozwalając im na walidację procesu testowania.
Większe zestawy mogą jednak zmagać się z formatem opartym na przeglądarce, co może znacznie ograniczyć oszczędność czasu testów ad-hoc.
5. Zefir
Zephyr to platforma zarządzania testami firmy SmartBear, która pomaga zespołom zapewnienia jakości poprawić widoczność testów, jednocześnie dobrze integrując się z innym oprogramowaniem do śledzenia błędów.
Funkcja ta jest jednak ograniczona do niektórych aplikacji, przy czym Confluence i Jira są tymi, które najbardziej korzystają z Zephyr – mogą to nie być najbardziej efektywne rozwiązania dla każdego biznesu. Pod marką Zephyr dostępnych jest kilka skalowalnych programów w różnych cenach.
Testy Ad-Hoc lista kontrolna, wskazówki i triki
Oto dodatkowe wskazówki dla zespołów, które należy uwzględnić podczas przeprowadzania testów ad hoc:
1. Ustalenie priorytetów dla elementów wrażliwych
Niektóre funkcje lub komponenty są naturalnie bardziej narażone na ryzyko błędu niż inne, zwłaszcza jeśli są ważne dla ogólnej funkcji programu.
Każde podejście do testowania powinno zidentyfikować części aplikacji, które mogą skorzystać z dokładniejszej uwagi. Jest to szczególnie pomocne, gdy ogólny czas na testy jest ograniczony.
2. Zbadanie różnych narzędzi testowych
Narzędzie, które organizacja wdraża w celu ułatwienia swoich testów, może wpłynąć na zasięg i wiarygodność tych kontroli.
Przy testach doraźnych warto przyjrzeć się jak największej liczbie programów, aby znaleźć takie, które odpowiadają jej aspektowi użytkowemu. Oprogramowanie wykorzystujące technologię wizji komputerowej, takie jak ZAPTEST, może podejść do testów ad-hoc stosując strategię podobną do ludzkiej.
3. Przyjmij mentalność ad hoc
Testowanie ad hoc oferuje ogromną swobodę na etapie zapewniania jakości, ale zespół musi się w nie zaangażować, aby uzyskać kluczowe korzyści z tej strategii.
Na przykład, testerzy ad-hoc powinni zrezygnować ze wszystkich swoich zwyczajowych dokumentów poza podstawowymi notatkami i muszą zbadać oprogramowanie z zupełnie nowej perspektywy.
4. Zaufaj instynktom badawczym
Doświadczenie w testach ad-hoc lub ogólnych kontrolach oprogramowania może pomóc w zwróceniu uwagi na wspólne punkty awarii, a to pomaga testerom określić, jak wykryć błędy wszystkich typów.
Istotne jest, aby testerzy ufali swoim instynktom i zawsze wykorzystywali tę wiedzę na swoją korzyść – mogą intuicyjnie określić, które kontrole ad-hoc byłyby najbardziej pomocne.
5. Pełne rejestrowanie odkrytych błędów
Chociaż testowanie ad-hoc nie ma formalnej dokumentacji i w większości opiera się na nieformalnych notatkach, to nadal istotne jest, aby zespół był w stanie zidentyfikować i przekazać przyczynę błędu w oprogramowaniu.
Muszą rejestrować wszelkie informacje, których dostarcza test, a które są istotne dla programistów, takie jak wszelkie potencjalne przyczyny tych problemów.
6. Zawsze rozliczaj się z użytkownikiem
Każda forma testowania zamierza w pewnym stopniu dostosować się do ogólnego doświadczenia użytkownika – i testowanie ad-hoc nie jest wyjątkiem. Choć często zagląda głębiej w wewnętrzne działanie aplikacji, a nawet jej wewnętrzny kod, testerzy ad-hoc powinni próbować złamać to oprogramowanie w sposób, w jaki teoretycznie mogliby to zrobić użytkownicy.
7. Ciągłe doskonalenie procesu
Zespoły testujące powinny dopracować swoje podejście do testowania ad-hoc pomiędzy wieloma iteracjami tego samego oprogramowania i z jednego projektu na drugi.
Mogą zebrać informacje zwrotne od deweloperów, aby zobaczyć, jak dobrze ich testy ad-hoc pomogły na etapie zapewniania jakości i czy byli w stanie znacząco zwiększyć pokrycie testowe.
Wniosek
Testowanie ad-hoc może pomóc organizacjom wszelkiego rodzaju uwierzytelnić ich strategię testowania oprogramowania, ale sposób, w jaki wdrażają tę technikę, może być znaczącym czynnikiem w jej skuteczności.
Zrównoważenie różnych typów testów jest kluczem do uzyskania jak największych korzyści z kontroli ad hoc – zwłaszcza, że ta forma testowania zamierza uzupełnić pozostałe, wypełniając strategiczną lukę.
Dzięki aplikacji takiej jak ZAPTEST, zespoły mogą przeprowadzać testy ad-hoc z większą pewnością lub elastycznością, zwłaszcza jeśli wdrożą automatyzację. Bez względu na konkretne podejście zespołu, jego zaangażowanie w testowanie ad hoc może zrewolucjonizować cały program lub projekt.
