7 Wskazówki dotyczące pisania przypadków testowych w celu poprawy procesu testowania oprogramowania ERP

przypadki testowe są bardzo ważne dla zapewnienia jakości w procesie testowania oprogramowania ERP. Są to pierwsze kroki w cyklu testowym i jeśli przypadki testowe nie są wystarczającej jakości, cały projekt zostanie “obciążony”. Pisanie “świetnych” przypadków testowych to umiejętność, która zyskuje formę po prostu robiąc to. Ale to bardzo przydatne, aby mieć pewne spostrzeżenia, które mogą Ci pomóc. W tym artykule chcę dotrzeć do Ciebie i dać sugestie, aby ułatwić, więcej zabawy i lepiej. Wskazówki, które zostaną podane, będą w szczególności odnosić się do przypadków testowych w testach akceptacyjnych systemów ERP.

co to są przypadki testowe?

w świecie testowania oprogramowania istnieje wiele definicji przypadków testowych. Z tego powodu ważne jest, aby nazwać naszą definicję. W naszej filozofii przypadki testowe są (na podstawie IEEE610): “zestaw wejść testowych, warunki wykonania i oczekiwane wyniki opracowane dla konkretnego celu.”Umiejętność pisania dobrych przypadków testowych jest niezwykle przydatna dla każdego, kto chce przetestować. Niezależnie od tego, czy jest to test funkcjonalny, test akceptacji użytkownika, testowanie aplikacji internetowej czy modułu systemu ERP. We wszystkich opisanych powyżej sytuacjach przypadki testowe określają, w jakim zakresie wyniki dają werdykt na wstępnie ustalone cele.

dlaczego pisanie spraw testowych jest takie trudne?

jak opisano w definicji, przypadki testowe pomagają testerom przejść przez sekwencję instrukcji testowych w celu ustalenia, czy oprogramowanie spełnia wstępnie zdefiniowane wymagania. Realizacja przypadków testowych pomaga nam gromadzić i odkrywać informacje, aby zrealizować ten konkretny cel lub cel. Pierwszym problemem, z którym bezpośrednio się spotykamy, jest różnorodność możliwych celów. A ponieważ istnieją różne typy testów i celów, istnieją różne typy odpowiadających im przypadków testowych.

drugi problem jest związany z treścią rzeczywistej instrukcji testowej lub kroków. Poziom tych instrukcji zależy od typu testera, który ma interpretować te informacje i wydawać opinię. Profesjonalny tester będzie potrzebował różnych instrukcji w przeciwieństwie do użytkownika końcowego, który jest zaangażowany w testowanie akceptacyjne systemu ERP

Wskazówka 1: Określ swój cel i to, co chcesz zgłosić

zastanów się, co chcesz zgłosić, aby określić swój cel Pochodny. Używając tego jako podstawy, masz zarys przypadku testowego w widoku. Istnieje wiele różnych celów, w których zawsze musimy zadać sobie pytanie, czego staramy się nauczyć lub osiągnąć, gdy zamierzamy przeprowadzić test. Oto kilka przykładów:

• wykrywanie wad: jest to klasyczny cel testowania. Badanie przeprowadza się w celu odsłonięcia wad.
• : Rozróżnienie pomiędzy “Maksymalizuj liczbę błędów” i “znajdowanie wad” polega na tym, że całkowita liczba błędów jest ważniejsza niż zasięg.
• Blokuj przedwczesne wydania produktu: celem tego testu jest przedwczesne wykrycie tak wielu poważnych wad (showstoppers), aby nikt nie przyjął produktu do produkcji.
• Wspieraj menedżerów decyzjami go / no-go: menedżerowie podejmują decyzje w oparciu o ryzyko. Wskazania ryzyka jako zakres badań, wpływ wykrytych problemów itp. Daj im lepsze tło, na którym mogą opierać swoje decyzje.
• Oceń zgodność zgodnie ze specyfikacją: domniemane specyfikacje są sprawdzane pod kątem ich działania. Wszystkie sprawy, które nie są związane ze specyfikacją, nie są brane pod uwagę.
• oceń jakość: jest to trudny cel, ponieważ jakość jest wielowymiarowa. Charakter jakości zależy od charakteru produktu. Aby ocenić jakość, należy opracować jasne kryteria, które są zdefiniowane w taki sposób, aby można było je rzeczywiście wymiernie określić.

wyniki testu uzyskane na podstawie przypadków testowych dostarczają bezpośrednich istotnych informacji na temat celu.

Wskazówka 2: zarezerwuj wystarczający czas projektowania

zarezerwuj wystarczająco dużo czasu na zaprojektowanie przypadków testowych, aby pasowały do Twoich celów. Słabe przypadki testowe będą cię prześladować przez cały proces testowy. Porównywanie wyników testów, raportowanie z kilku rund testowych itp. Są zasadniczo określone przez jakość przypadków testowych.

jeśli kończy ci się czas na projektowanie, ale nadal chcesz rozpocząć testowanie, upewnij się, że przynajmniej zdefiniowałeś główne zagrożenia. Jeśli 10 testerów musi przejrzeć 5 przypadków testowych z 1 etapem testowym, spowoduje to uzyskanie 50 wyników testu. Bez względu na to, co te wyniki 50 dać więcej informacji na temat jakości, a następnie nic nie robi. Prawdopodobnie nie będzie to wyczerpujące, ale to pierwszy krok. Od tego momentu można określić poziom szczegółowości niektórych części.

wolimy, abyś z dużym wyprzedzeniem pomyślał o tym, jak powinien być zaprojektowany test, a wyniki testu dają rzeczywistą odpowiedź na cel. Ale w rzeczywistości jest to czasami niesforne.

Wskazówka 3: Nazwa przypadku testowego

Nazywanie przypadków testowych jest ważne. W przeciętnym teście ERP z łatwością masz ponad 500 przypadków testowych. Zrozumiesz, że logiczna struktura nazw zwiększa wykrywalność. W literaturze często określana jest jako kompletna, jak to możliwe nazwa, w której badany jest proces, moduł, obiekt itp. Wszystkie są zawarte w nazwie. Można sobie wyobrazić, że dostarczenie 500 przypadków testowych z tak kompletnym tytułem daje chaotyczną administrację. Dzięki prostemu arkuszowi Excel łatwo stracisz przegląd. Narzędzia do zarządzania testami zapewniają strukturę, do której można powiązać przypadki testowe z obiektami wielokrotnego użytku, bez ich “zanieczyszczania” nazwy. Masz również narzędzia do rejestracji testowej, które organizują te relacje w inny sposób.

na przykład w TestMonitor wymyśliliśmy inne rozwiązanie. W narzędziu można zdefiniować etykiety lub znaczniki, które następnie można połączyć do przypadków testowych. W TestMonitor przypadki testowe są powiązane z jedną lub wieloma etykietami procesów biznesowych, ryzyka, wymagań lub aplikacji. Pozwala to na grupowanie przypadków testowych i pobieranie ich z różnych perspektyw.

dla nazwy przypadku testowego w TestMonitor wystarczy jasny opis celu przypadku testowego. Aby to uprościć, opisujesz działanie z ukrytym oczekiwaniem.

przykładowa nazwa przypadku testowego:
“rozwiązanie umowy najmu – niezależny dom”
” Utwórz klienta “”tymczasowe potwierdzenie rezerwacji”
itp.

przykład przypadku testowego “tymczasowe potwierdzenie rezerwacji”, które jest powiązane z kilkoma etykietami:

• proces biznesowy “przyjmowanie towarów”
• wymóg “wymóg umowy”
• ryzyko “Ryzyko operacyjne”
• zastosowanie “ERP’

ważne jest, aby opisać oczekiwany wynik dla każdego przypadku testowego. Następnie tester wie, w którym kierunku powinna być “odpowiedź” i bezpośrednio otrzymuje jawny framework testowy.

Wskazówka 4: Krok testowy opis

jak opisano w definicji przypadki testowe są zbiorem instrukcji testowych, które pomagają nam odkryć informacje, aby osiągnąć określony cel.

przypadek testowy musi mieć wyraźny początek i koniec, aby określić, czy przypadek testowy przeszedł, czy nie. Ponadto przypadek testowy składa się z jednej lub więcej instrukcji lub kroków testowych, w których istnieje wiele ścieżek możliwych do osiągnięcia pożądanego rezultatu. Tylko testowanie ścieżki sukcesu jest często niewystarczające. W pewnych sytuacjach podążanie ścieżkami bez sukcesu może po prostu zrobić różnicę.

ważne jest, aby zdefiniować etapy testu tak jasno, jak to możliwe, aby użytkownik końcowy do testu akceptacji użytkownika dokładnie wiedział, co musi zrobić. Oczywiście istnieją warunki wstępne, które należy wymyślić, takie jak tester poziomu funkcjonalnego, znajomość nowego systemu, znajomość możliwych dostosowanych procesów biznesowych itp. Ale w istocie każdy powinien zrozumieć wszystkie etapy testu.

Załóżmy, że dalej opisujemy przypadek testowy “wypowiedzenie dzierżawy-niezależny dom” dla prostej ścieżki sukcesu:

1. Wybierz jednostkę i rozpocznij wypowiedzenie umowy najmu. Kontrola, czy istnieją przesłanki, wśród których wypowiedzenie umowy najmu może/nie może zostać zaakceptowane i utwórz zapis tego.
3. wypełnij dane na ekranie wypowiedzenie umowy najmu. Sprawdź dokładnie dane najemcy w karcie wypowiedzenia umowy najmu.
4. Zarejestruj wypowiedzenie umowy najmu i wyślij list potwierdzający. Sprawdź, czy list potwierdzający dotarł do Archiwum Cyfrowego.
5. sprawdź w rejestrze umów z jednostki, że bieżąca umowa została rozwiązana, że rozwiązana umowa jest związana z wypowiedzeniem umowy najmu i że istnieje nowo utworzona umowa najmu.
6. sprawdź nową (wakat)umowę na podstawie polityki najmu i szablonów elementów.

co zauważyłeś?

• każdy krok testowy zaczyna się od czasownika
• , po którym następuje temat
• kończąc szczegółowymi i ewentualnie kontrolnymi pytaniami. Możesz zdecydować się na umieszczenie pytań kontrolnych w oddzielnych krokach testowych, ale praktyka pokazuje, że pytanie kontrolne jest udoskonaleniem działania, a następnie, logicznie, zostanie zapisane jako krok testowy.

w powyższym przykładzie zakłada się, że specjalista z danej dziedziny oceni etap badania. A ponieważ jest specjalistą, nie są podane żadne warunki wejściowe ani wyraźne oczekiwania, ponieważ specjalista nadal ma w zanadrzu własne studia przypadków i jego oczekiwania są krystalicznie jasne.

Jeśli obecnie nie masz specjalisty, możesz rozszerzyć kroki testowe o warunki wejściowe i wyraźne oczekiwania.

na przykład krok testowy 1 w przypadku testowym “rozwiązanie umowy najmu-niezależny dom” z więcej szczegółów.

1. Wybierz jednostkę “Fleet street 677” i rozpocznij wypowiedzenie umowy najmu. Warunki gwarantują, że jednostka ta nie może zostać rozwiązana przed uregulowaniem zaległości.
2. itd.

: Nie więcej niż 10 instrukcji testowych w 1 przypadku testowym

regularnie spotykamy się z projektami testowymi, w których >50 kroków testowych jest przypisanych do jednego przypadku testowego. To za dużo z kilku powodów:

• wszystkie kroki testowe muszą być podjęte oddzielnie (lub wyraźnie zaliczone), zanim sprawa testowa otrzyma werdykt.
• ostateczna ocena przypadku testowego zależy od “najgorszego” wyniku. Może więc być tak, że 49 kroków testowych zostanie ocenionych jako” dobre”, a jeden jako” złe”, co skutkuje” złym ” przypadkiem testowym. Pomiar etapów badania powinien być podobny. Mam przez to na myśli, że praktycznie każdy etap testu musi być równy efektowi oceny. Jeśli masz 10 kroków testowych, które musisz wykonać, w tym 2 małe kroki testowe, które są nieproporcjonalne do pozostałych 8 kroków testowych, musisz je zmienić. To samo dotyczy na odwrót z trudnym krokiem testowym.
• tester szybko gubi się przy zbyt wielu krokach testowych w przypadku testowym. Nie przeprowadziliśmy badań naukowych na ten temat, ale praktyka pokazuje, że przypadek testowy nie powinien zawierać więcej niż 10 kroków testowych. Można myśleć o wielu wyjątkach (Kontrola konwersji, itp), ale w praktyce dla testu akceptacji użytkownika systemu ERP to działa najlepiej.
• deweloperom trudno jest odtworzyć znaleziony błąd. Przy wielu krokach testowych deweloper straci dużo czasu, próbując odtworzyć sytuację.
• powtórki lub powtórzenie dużych przypadków testowych zajmuje zbyt dużo czasu. Gdy błąd zostanie wykryty przez testera, odpowiedni przypadek testowy będzie musiał zostać ponownie przetestowany. Ponowny test wymaga, że sam krok zostanie ponownie oceniony, chcesz oczywiście zapobiec błędom regresji. Wykonując zbyt wiele kroków testowych, najprawdopodobniej testujesz zbyt wiele. W ten sposób proces testowania trwa dłużej i może ostatecznie przeciążać testerów.

oprócz tego masz również narzędzia do rejestracji testów, które mogą prezentować testerowi przypadki testowe w różnych formach. Na przykład TestMonitor ma dwa różne widoki. TestMonitor ma wyświetlacz, który pokazuje wszystkie kroki testu osobno na stronie i wyświetlacz, w którym przypadki testowe są prezentowane na stronie, w tym wszystkie kroki testu.Zaletą pierwszego wyświetlacza jest to, że każdy tester może uzyskać więcej informacji dla każdego etapu testu. Wadą w przypadku, gdy tester jest bardziej doświadczony, musi kliknąć “Dalej” za każdym razem, gdy chce przejść do następnego kroku testowego. W drugim widoku dla każdego przypadku testowego zalety i wady są odwrotnie.

Wskazówka 6: Recenzja przez nie-projektanta / dostawcę

w praktyce regularnie widzimy skrypty testowe przygotowane przez programistów dostawcy oprogramowania. Podczas przeglądania tych skryptów testowych przez potencjalnych testerów, zwykle jest więcej pytań niż odpowiedzi. Odwrotnie, działa to tak samo w przypadku skryptów testowych przygotowanych przez własnych pracowników. Daje to realną wartość dodaną, przeglądając je przez dostawcę oprogramowania. Patrzą na ukończone skrypty testowe różnymi oczami i zawsze wymyślają znaczące dodatki lub modyfikacje.

przy odrobinie burzy mózgów ze specjalistami od dostawców oprogramowania i organizacją klienta szybko skupiasz się na istocie tego, co należy przetestować. Następnie poświęć czas na rozważenie przypadków testowych, scenariuszy bez powodzenia, a zobaczysz, że twój model testowy szybko staje się bardziej obszerny i szczegółowy. Poza tym otrzymasz więcej informacji na temat jakości, którą uznałeś za możliwą.

Wskazówka 7: TestMonitor

poza tym skorzystaj z profesjonalnej platformy testowej i spraw, aby jakość była naprawdę wnikliwa. Zamów bezpłatną wersję próbną TestMonitor już dziś i przekonaj się o różnicy.

jeśli jesteś nowicjuszem w świecie testowania, łatwo stajesz się przytłoczony całą terminologią testowania. W tym artykule postaramy się wyjaśnić niektóre z żargonu, który możesz napotkać w codziennym życiu testowym, aby wszystko było nieco bardziej zrozumiałe.

rozpocznij testowanie z TestMonitor

nie jesteś jeszcze użytkownikiem TestMonitor? Dobre i łatwe testowanie jest kluczowym priorytetem dla menedżerów ds. zapewnienia jakości, testmanagerów, menedżerów IT, menedżerów testów i menedżerów wydań. TestMonitor sprawia, że testowanie jest łatwe i przyjemne również dla użytkowników testów.

więc zaczynajmy. Zachęcamy do zapoznania się z naszym filmem lub pobrania ulotki produktu. Ale oczywiście, dzięki bezpłatnej wersji próbnej możesz naprawdę doświadczyć łatwości korzystania z TestMonitor.

będziemy w kontakcie? Śledź TestMonitor na Twitterze i LinkedIn.