7 principles software testing
Siedem zasad testowania oprogramowania: w tym więcej szczegółów na temat grupowania defektów, zasady Pareto i paradoksu pestycydów.
Jestem pewien, że wszyscy są świadomi „ Siedem zasad testowania oprogramowania ”.
Te podstawowe zasady testowania pomagają zespołom testującym wykorzystać ich czas i wysiłek, aby proces testowania był skuteczny. W tym artykule szczegółowo poznamy dwie zasady, tj. Grupowanie defektów, zasada Pareto i paradoks pestycydów .
Czego się nauczysz:
- Siedem zasad testowania oprogramowania
Siedem zasad testowania oprogramowania
Zanim dogłębnie przyjrzymy się tym dwóm zasadom, przyjrzyjmy się pokrótce siedmiu zasadom testowania oprogramowania.
Odkryjmy!!
1) Testowanie wskazuje na obecność defektów
Każda aplikacja lub produkt trafia do produkcji po wystarczającej liczbie testów przeprowadzonych przez różne zespoły lub przechodzi przez różne fazy, takie jak testy integracji systemu, testy akceptacji użytkowników, testy beta itp.
Więc czy kiedykolwiek widziałeś lub słyszałeś od któregokolwiek z zespołów testujących, że w pełni przetestowali oprogramowanie i nie ma w nim usterki ? Zamiast tego każdy zespół testujący potwierdza, że oprogramowanie spełnia wszystkie wymagania biznesowe i działa zgodnie z potrzebami użytkownika końcowego.
W branży testowania oprogramowania nikt nie powie, że tak Brak wad w oprogramowaniu, co jest całkiem prawdziwe, ponieważ testowanie nie może udowodnić, że oprogramowanie jest wolne od błędów lub defektów.
Jednak celem testowania jest znajdowanie coraz większej liczby ukrytych defektów przy użyciu różnych technik i metod. Testowanie może ujawnić nieodkryte defekty, a jeśli nie zostaną znalezione żadne defekty, nie oznacza to, że oprogramowanie jest wolne od defektów.
Przykład 1 :
Rozważ aplikację bankową, ta aplikacja jest dokładnie testowana i przechodzi różne fazy testowania, takie jak SIT, UAT itp., A obecnie nie są identyfikowane żadne usterki w systemie.
Może się jednak zdarzyć, że w środowisku produkcyjnym rzeczywisty klient spróbuje rzadko używanej w systemie bankowym funkcjonalności, a testerzy przeoczyli tę funkcjonalność, stąd do dnia dzisiejszego nie znaleziono żadnej usterki lub kod nigdy nie został dotknięty przez programistów. .
Przykład 2:
W telewizji widzieliśmy kilka reklam mydeł, past do zębów, płynów do mycia rąk lub środków dezynfekujących itp.
Rozważ reklamę dotyczącą prania ręcznego, która mówi w telewizji, że 99% zarazków może zostać usuniętych, jeśli zostanie użyty ten konkretny środek do mycia rąk. To wyraźnie dowodzi, że produkt nie jest w 100% wolny od zarazków. Dlatego w naszej koncepcji testowania możemy powiedzieć, że żadne oprogramowanie nie jest wolne od defektów.
# 2) Wczesne testy
Testerzy muszą zaangażować się na wczesnym etapie cyklu życia oprogramowania (SDLC). W ten sposób można zidentyfikować defekty występujące na etapie analizy wymagań lub wszelkie wady dokumentacji. Koszt naprawy takich defektów jest znacznie niższy w porównaniu z kosztami wykrytymi na późniejszych etapach testowania.
Zwróć uwagę na poniższy obrazek, który pokazuje, jak koszt naprawy defektów rośnie, gdy testy zmierzają w kierunku produkcji na żywo.
(wizerunek źródło )
Powyższy obraz pokazuje, że koszt potrzebny do naprawy usterki wykrytej podczas analizy wymagań jest mniejszy i rośnie wraz z przejściem do fazy testowania lub konserwacji.
Teraz pytanie brzmi jak wcześnie powinno się rozpocząć testowanie ?
Po sfinalizowaniu wymagań testerzy muszą zaangażować się do testowania. Testowanie powinno być przeprowadzane na dokumentach wymagań, specyfikacji lub innym typie dokumentu, tak aby w przypadku nieprawidłowego zdefiniowania wymagań można je było natychmiast naprawić, zamiast naprawiać je w fazie rozwoju.
# 3) Wyczerpujące testy nie są możliwe
Nie jest możliwe przetestowanie wszystkich funkcji ze wszystkimi poprawnymi i nieprawidłowymi kombinacjami danych wejściowych podczas rzeczywistego testowania. Zamiast tego podejścia rozważa się testowanie kilku kombinacji w oparciu o priorytety przy użyciu różnych technik.
Wyczerpujące testy będą wymagały nieograniczonych wysiłków, a większość z nich jest nieskuteczna. Ponadto ramy czasowe projektu nie pozwolą na testowanie tak wielu kombinacji. W związku z tym zaleca się testowanie danych wejściowych przy użyciu różnych metod, takich jak podział równoważności i analiza wartości brzegowych.
Na przykład ,Jeśli załóżmy, że mamy pole wejściowe, które akceptuje tylko litery, znaki specjalne i liczby od 0 do 1000. Wyobraź sobie, ile kombinacji pojawiłoby się do testowania, nie jest możliwe przetestowanie wszystkich kombinacji dla każdego typu danych wejściowych.
Wysiłki testowe wymagane do przetestowania będą ogromne i wpłyną również na harmonogram projektu i koszty. Dlatego zawsze mówi się, że wyczerpujące testy są praktycznie niemożliwe.
4. Testowanie zależy od kontekstu
Na rynku dostępnych jest kilka domen, takich jak bankowość, ubezpieczenia, medycyna, podróże, reklama itp., A każda domena ma wiele zastosowań. Również dla każdej domeny ich aplikacje mają różne wymagania, funkcje, inny cel testowania, ryzyko, techniki itp.
Różne domeny są testowane w różny sposób, dlatego testowanie opiera się wyłącznie na kontekście domeny lub aplikacji.
Na przykład ,testowanie aplikacji bankowej różni się od testowania dowolnej aplikacji e-commerce lub reklamowej. Ryzyko związane z każdym typem aplikacji jest inne, dlatego stosowanie tej samej metody, techniki i typu testowania do testowania wszystkich typów aplikacji nie jest skuteczne.
# 5) Grupowanie defektów
Podczas testowania może się zdarzyć, że większość znalezionych defektów dotyczy niewielkiej liczby modułów. Może być tego wiele przyczyn, np. Moduły mogą być złożone, kodowanie związane z takimi modułami może być skomplikowane itp.
Jest to zasada Pareto testowania oprogramowania, w której 80% problemów występuje w 20% modułów. Dowiemy się więcej o klastrowaniu defektów i zasadzie Pareto w dalszej części tego artykułu.
# 6) Paradoks pestycydów
Zasada paradoksu pestycydów mówi, że jeśli ten sam zestaw przypadków testowych jest wykonywany wielokrotnie przez pewien okres czasu, to te zestawy testów nie są w stanie zidentyfikować nowych defektów w systemie.
Aby przezwyciężyć ten „paradoks pestycydów”, zestaw przypadków testowych musi być regularnie przeglądany i korygowany. W razie potrzeby można dodać nowy zestaw przypadków testowych, a istniejące przypadki testowe można usunąć, jeśli nie są w stanie znaleźć więcej błędów w systemie.
# 7) Brak błędu
Jeśli oprogramowanie zostało w pełni przetestowane i nie znaleziono żadnych błędów przed wydaniem, możemy powiedzieć, że oprogramowanie jest w 99% wolne od wad. Ale co, jeśli to oprogramowanie jest testowane pod kątem niewłaściwych wymagań? W takich przypadkach nawet znalezienie usterek i ich naprawa na czas nie pomoże, ponieważ testy są przeprowadzane na niewłaściwych wymaganiach, które nie odpowiadają potrzebom użytkownika końcowego.
Na przykład, załóżmy, że aplikacja jest powiązana z witryną e-commerce i wymaganiami dotyczącymi funkcji „Koszyk lub Koszyk”, która jest błędnie zinterpretowana i przetestowana. Tutaj nawet znalezienie większej liczby usterek nie pomaga przenieść aplikacji do kolejnej fazy lub środowiska produkcyjnego.
Oto siedem zasad testowania oprogramowania.
Teraz zbadajmy Grupowanie defektów, zasada Pareto i paradoks pestycydów w Szczegół .
Grupowanie defektów
Podczas testowania dowolnego oprogramowania testerzy najczęściej spotykają się z sytuacją, w której większość znalezionych defektów jest związana z określoną funkcjonalnością, a pozostałe funkcjonalności będą miały mniejszą liczbę defektów.
Grupowanie defektów oznacza niewielką liczbę modułów zawierających większość defektów. Zasadniczo defekty nie są rozmieszczone równomiernie w całej aplikacji, raczej są skoncentrowane lub scentralizowane w dwóch lub trzech funkcjach.
Czasami jest to możliwe ze względu na złożoność aplikacji, kodowanie może być złożone lub skomplikowane, programista może popełnić błąd, który może mieć wpływ tylko na określoną funkcjonalność lub moduł.
Grupowanie defektów opiera się na „ Zasada Pareto ”, Który jest również znany jako Zasada 80-20 . Oznacza to, że 80% wykrytych defektów wynika z 20% modułów w aplikacji. Pojęcie zasady Pareto zostało początkowo zdefiniowane przez włoskiego ekonomistę - Vilfrodo Pareto .
Jeśli testerzy przyjrzą się 100 defektom, nie będzie jasne, czy istnieje jakiekolwiek ukryte znaczenie tych 100 defektów. Ale jeśli te 100 defektów zostanie skategoryzowanych według określonych kryteriów, testerzy mogą zrozumieć, że duża liczba defektów dotyczy tylko kilku określonych modułów.
Na przykład ,rozważmy poniższy obrazek, który jest testowany dla jednej z aplikacji bankowych i pokazuje, że większość usterek jest związana z funkcją „Debet”. Pozostałe funkcje, takie jak podsumowanie konta, przelew środków, zlecenie stałe itp., Mają ograniczoną liczbę błędów.
(wizerunek źródło )
Z powyższego rysunku wynika, że wokół funkcjonalności Limitu w koncie jest 18 usterek z łącznej liczby 32 usterek, co oznacza, że 60% usterek znajduje się w module „Debet”.
Dlatego testerzy koncentrują się głównie na tym obszarze podczas wykonywania, aby znaleźć coraz więcej błędów. Zaleca się, aby testerzy podczas testowania podobnie skupiali się na innych modułach.
Gdy ten sam kod lub moduł jest wielokrotnie testowany przy użyciu zestawu przypadków testowych niż podczas początkowych iteracji, liczba defektów jest wysoka, jednak po kilku iteracjach liczba defektów znacznie się zmniejszy. Grupowanie defektów wskazuje, że obszar podatny na defekty ma zostać dokładnie przetestowany podczas testów regresji.
Paradoks pestycydów
Kiedy okaże się, że jeden z modułów ma więcej błędów, testerzy podejmują dodatkowe wysiłki, aby przetestować ten moduł.
Po kilku iteracjach testowania jakość kodu ulega poprawie, a liczba defektów zaczyna spadać, ponieważ większość defektów jest naprawiana przez zespół programistów, ponieważ programiści są również ostrożni podczas kodowania konkretnego modułu, w którym testerzy znaleźli więcej błędów.
Dlatego w pewnym momencie większość defektów jest wykrywana i naprawiana, tak że w tym module nie znajdują się żadne nowe defekty.
Jednak czasami może się zdarzyć, że zachowując szczególną ostrożność podczas kodowania na jednym konkretnym module (tutaj w naszym przypadku „ Przekroczenie konta bankowego ”), Deweloper może zaniedbać inne moduły w celu prawidłowego zakodowania go lub zmiany dokonane w tym konkretnym module mogą mieć negatywny wpływ na inne funkcjonalności, takie jak Podsumowanie Rachunku, Transfer środków i Stałe Instrukcje.
Gdy testerzy używają tego samego zestawu przypadków testowych do wykonania modułu, w którym znajduje się większość defektów (moduł Overdraft), to po naprawieniu tych defektów przez programistów te przypadki testowe nie są zbyt skuteczne w znajdowaniu nowych defektów. Jako koniec do końca przepływ w rachunku bieżącym, moduł jest dokładnie testowany, a programiści również ostrożnie napisali kod dla tego modułu.
Konieczne jest poprawienie i zaktualizowanie tych przypadków testowych. Dobrym pomysłem jest również dodanie nowych przypadków testowych, aby można było znaleźć nowe i więcej defektów w różnych obszarach oprogramowania lub aplikacji.
Metody zapobiegawcze paradoksu pestycydów
Istnieją dwie opcje, dzięki którym możemy zapobiec paradoksowi pestycydów, jak pokazano poniżej:
do) Napisz nowy zestaw przypadków testowych, który skupi się na innym obszarze lub modułach (innych niż wcześniejszy moduł podatny na defekty - Przykład: „Kredyt w rachunku bieżącym”) oprogramowania.
b) Przygotuj nowe przypadki testowe i dodaj je do istniejących.
W ' metoda A ”, Testerzy mogą znaleźć więcej błędów w innych modułach, na których nie skupiali się podczas wcześniejszych testów lub programiści nie byli szczególnie ostrożni podczas kodowania.
W powyższym przykładzie testerzy mogą znaleźć więcej błędów w modułach Podsumowanie konta, Transfer środków lub Stałe instrukcje, korzystając z nowego zestawu przypadków testowych.
Może się jednak zdarzyć, że testerzy mogą zaniedbać wcześniejszy moduł ( Przykład: „Kredyt w rachunku bieżącym”), gdzie większość defektów została znaleziona we wcześniejszej iteracji i może to stanowić ryzyko, ponieważ ten moduł (Kredyt w rachunku bieżącym) mógł zostać wprowadzony z nowymi defektami po zakodowaniu innych modułów.
W ' metoda B. ”, Przygotowywane są nowe przypadki testowe, dzięki czemu w pozostałych modułach można znaleźć nowe potencjalne defekty.
W naszym przykładzie nowo utworzone przypadki testowe będą w stanie pomóc w zidentyfikowaniu defektów w modułach, takich jak Podsumowanie konta, Transfer środków i Stała instrukcja. Jednak testerzy nie mogą ignorować wcześniejszych modułów podatnych na defekty ( Przykład: „Kredyt w rachunku bieżącym”), ponieważ te nowe przypadki testowe są łączone z istniejącymi przypadkami testowymi.
Istniejące przypadki testowe były bardziej skoncentrowane na module „Kredyt w rachunku bieżącym”, a nowe przypadki testowe koncentrowały się na innych modułach. W związku z tym cały zestaw przypadków testowych jest wykonywany przynajmniej raz, nawet gdy w dowolnym module nastąpi zmiana kodu. Zapewni to wykonanie prawidłowej regresji i zidentyfikowanie defektu dzięki tej zmianie kodu.
Korzystając z drugiego podejścia, całkowita liczba przypadków testowych znacznie wzrasta i powoduje więcej wysiłku i czasu potrzebnego na wykonanie. Będzie to oczywiście miało wpływ na ramy czasowe projektu, a przede wszystkim na budżet projektu.
Dlatego też, aby rozwiązać ten problem, zbędne przypadki testowe można przejrzeć, a następnie usunąć. Istnieje wiele przypadków testowych, które stają się bezużyteczne po dodaniu nowych przypadków testowych i zmodyfikowaniu istniejących przypadków testowych.
Konieczne jest sprawdzenie, które przypadki testowe nie powiodły się, aby zidentyfikować defekty w ostatnich 5 iteracjach (załóżmy 5 iteracji), a które nie są zbyt ważne. Może się również zdarzyć, że pojedynczy przepływ objęty kilkoma przypadkami testowymi może zostać objęty innym przypadkiem od końca do końca, a przypadki testowe z pojedynczym przepływem można usunąć.
To z kolei zmniejszy całkowitą liczbę przypadków testowych.
Na przykład ,mamy 50 przypadków testowych do pokrycia jednego konkretnego modułu i widzieliśmy, że z tych 50 przypadków testowych 20 przypadków testowych nie wykryło nowego defektu w kilku ostatnich iteracjach testowych (załóżmy 5 iteracji). Tak więc te 20 przypadków testowych wymaga dokładnego przeglądu i musimy sprawdzić, jak ważne są te przypadki testowe i podjąć odpowiednią decyzję, czy zachować 20 przypadków testowych, czy je usunąć.
Przed usunięciem dowolnego przypadku testowego sprawdź, czy przepływ funkcjonalności objęty tymi przypadkami testowymi jest objęty innym przypadkiem testowym. Ten proces należy wykonać we wszystkich modułach, aby całkowita liczba przypadków testowych została znacznie zmniejszona. Zapewni to zmniejszenie całkowitej liczby przypadków testowych, ale nadal istnieje 100% pokrycie wymagań.
Oznacza to, że wszystkie pozostałe przypadki testowe obejmują wszystkie wymagania biznesowe, dlatego nie ma kompromisu w kwestii jakości.
Wniosek
Testowanie oprogramowania jest niezbędnym krokiem w SDLC, ponieważ sprawdza, czy oprogramowanie działa zgodnie z potrzebami użytkownika końcowego, czy nie.
Testowanie identyfikuje jak najwięcej defektów. Dlatego też, aby skutecznie i wydajnie przeprowadzać testy, każdy powinien być świadomy i rzeczywiście rozumieć siedem zasad testowania oprogramowania, które są znane jako filary testowania.
Większość testerów wdrożyła i doświadczyła tych zasad podczas rzeczywistych testów.
darmowy program do pobierania wideo z dowolnej pełnej wersji witryny
Ogólnie termin zasada oznacza zasady lub prawa, których należy przestrzegać. Dlatego wszyscy w branży testowania oprogramowania muszą przestrzegać tych siedmiu zasad, a jeśli ktoś zignoruje którąkolwiek z tych zasad, może to kosztować projekt.
Miłego czytania !!
rekomendowane lektury
- Najlepsze narzędzia do testowania oprogramowania 2021 (Narzędzia do automatyzacji testów QA)
- Asystent testowania oprogramowania
- Kurs testowania oprogramowania: Do którego Instytutu Testowania Oprogramowania mam dołączyć?
- Wybór testowania oprogramowania jako swojej kariery
- Testowanie oprogramowania Praca Freelancer Writer treści technicznych
- Co to jest technika testowania oparta na defektach?
- Kilka interesujących pytań do rozmowy kwalifikacyjnej dotyczącej testowania oprogramowania
- Opinie i recenzje dotyczące kursu testowania oprogramowania