Kiedy przestać testować (kryteria zakończenia w testowaniu oprogramowania)

when stop testing

Kryteria zakończenia w testowaniu:

„Dobry początek to połowa sukcesu” - ma zastosowanie wszędzie, nawet przy testowaniu oprogramowania.

Często na początku projektu obserwujemy entuzjastów testerów oprogramowania. Tworzymy dokumenty testowe takich jak Strategia testów, Plan testów czy Przypadki Testowe chętnie i entuzjastycznie.

Następnie przechodzimy do testowania oprogramowania z BANG! Potęgują to tylko interesujące wady, które znaleźliśmy na początku projektu. Ich rozwiązanie tylko przyczyni się do naszego osiągnięcia.

Gdy znajdziemy mnóstwo usterek i zakończymy pierwszy przebieg, przechodzimy do kolejnej fazy. Kiedy docieramy do drugiego biegu, trochę się odprężamy i tak jest z ogólną ludzką skłonnością znudzić się testowaniem tego samego w drugim biegu.

zautomatyzowane narzędzia testowe dla aplikacji internetowych

Wielu testerów uważa, że ​​tak się stanie monotonna praca w późniejszych seriach i zacznij tracić zainteresowanie ciągłym testowaniem tego samego oprogramowania. Kiedy docieramy do, być może trzeciego biegu, zaczyna nas dręczyć jedno pytanie, a mianowicie: „Kiedy przestać testować oprogramowanie?”

Założę się, że musiałeś czuć to samo i przynajmniej raz zapytać: „Kiedy przestać testować?”. Powiedziałbym, że pytanie brzmi „Kiedy, gdzie i jak zakończyć testowanie?” :)

Koncepcyjnie przeczytaliśmy i wielu testerów uważa, że ​​nie może istnieć określony warunek lub równanie, które zadecydowałoby „Kiedy przerwać testowanie?” Zanim przejdziemy do tego pytania, należy wziąć pod uwagę kilka czynników.

W dzisiejszym artykule chciałbym podzielić się moimi przemyśleniami na temat tego, jak zakończyć czynności testowe, gdy dojdziemy do punktu w naszym cyklu testowania, w którym możemy powiedzieć, że to testowanie wystarczy. Zrobimy to za pomocą kilku przykładów z życia wziętych w typowym cyklu testowym.

Czego się nauczysz:

• Kiedy wystarczy testów?
• Zatrzymywanie się po znalezieniu wszystkich wad: czy to możliwe?
• Decyzja o przerwaniu testowania: kryteria zakończenia
• Co to są kryteria ukończenia lub zakończenia?
• Co powinno znajdować się w kryteriach wyjścia?
• Testowanie można zatrzymać, gdy:
• Wniosek:
• rekomendowane lektury

Kiedy wystarczy testów?

Kiedy możemy powiedzieć, że tyle testów wystarczy? Czy testy można kiedykolwiek ukończyć?

Aby odpowiedzieć na te pytania, będziemy musieli przeanalizować czynności testowe od początku do końca. Proszę zauważyć, że - zamierzam zdefiniować te czynności w kategoriach laika - Nie w wyszukany techniczny sposób.

Rozważmy, że zaczynasz testować nowy projekt.

Działania wstępne:

• Zespół testujący otrzymuje wymagania.
• Rusza zespół testujący planowanie i projektowanie.
• Dokumenty testu wstępnego są gotowe i przejrzane.

Uruchomienie testowe nr 1)

• Zespół testujący rozpoczyna wykonywanie testów po otrzymaniu opracowanego produktu.
• Podczas fazy testowania wykonują różne scenariusze, aby złamać oprogramowanie i znaleźć wiele defektów. (Również tutaj współczynnik defektów jest wyższy, ponieważ aplikacja jest nowa i jest poddawana ocenie po raz pierwszy).
• Wady są naprawiane przez programistów i zwracane do zespołu testowego w celu ponownego przetestowania.
• Zespół testowy przeprowadza ponowne testy usterek i wykonuje regresję.
• Po usunięciu większości poważnych usterek i stabilnym wyglądzie oprogramowania zespół programistów wydaje kolejną wersję.

Uruchomienie testowe nr 2)

• Zespół testowy rozpoczyna drugą serię testów, a podobne czynności są wykonywane jako Uruchomienie 1.
• W tym procesie podczas drugiego przebiegu testowego wychwytywanych jest jeszcze kilka błędów.
• Defekty są naprawiane przez programistów i zwracane do zespołu testowego w celu ponownego przetestowania.
• Zespół testujący ponownie testuje usterki i działa regresja .

To może trwać wiecznie. Uruchom 3, Uruchom 4 i dalej, aż wszystkie usterki oprogramowania zostaną znalezione i oprogramowanie stanie się wolne od błędów.

Jeśli chcemy narysować schemat blokowy dla tych działań, będzie on wyglądał mniej więcej tak, jak poniżej:

Z powyższego schematu możemy jasno wywnioskować, że testowanie może trwać do momentu znalezienia wszystkich defektów w oprogramowaniu.

Ale pytanie brzmi - czy można znaleźć każdą usterkę w oprogramowaniu? Spróbujmy znaleźć odpowiedź na to pytanie za milion dolarów :).

Zatrzymywanie się po znalezieniu wszystkich wad: czy to możliwe?

Większość oprogramowania jest złożona i ma ogromny zakres testowania. Nie jest niemożliwe znalezienie wszystkich usterek w oprogramowaniu, ale zajmie to wieczność.

Nawet po znalezieniu wielu błędów w oprogramowaniu, nikt nie może zagwarantować, że oprogramowanie jest teraz wolne od wad. Nie może być sytuacji, w której możemy śmiało powiedzieć, że zakończyliśmy testy, znaleźliśmy wszystkie usterki w oprogramowaniu i nie ma więcej błędów.

Ponadto celem testowania nie jest znalezienie każdej usterki w oprogramowaniu. Celem testowania oprogramowania jest udowodnienie, że oprogramowanie działa zgodnie z zamierzeniami, poprzez złamanie go lub znalezienie odchylenia między jego obecnym zachowaniem a oczekiwanym zachowaniem.

Oprogramowanie ma nieograniczoną liczbę defektów, dlatego testowanie go do czasu znalezienia wszystkich defektów jest niepraktyczne, ponieważ nigdy nie wiemy, która z usterek jest ostatnia. Prawda jest taka, że ​​nie możemy polegać na znalezieniu wszystkich błędów w oprogramowaniu, aby zakończyć nasze testy.

Szczerze mówiąc, testowanie jest nieskończone, a cykle testowe będą kontynuowane, dopóki nie zostanie podjęta decyzja, kiedy i gdzie zakończyć. Teraz podjęcie decyzji o zaprzestaniu testów staje się jeszcze bardziej skomplikowane. Jeśli „zatrzymanie się po znalezieniu wszystkich defektów” nie jest kryterium zatrzymania testów, to na jakiej podstawie należy podjąć taką decyzję?

Decyzja o zaprzestaniu testów: Kryteria wyjścia

Spróbujmy teraz zrozumieć - jakie są najważniejsze czynniki, które należy wziąć pod uwagę przy kończeniu czynności testowych? Wydaje mi się, że decyzja o zaprzestaniu testów zależy głównie od Czas, budżet i zakres testów.

Najczęstszym podejściem jest zatrzymanie się po wyczerpaniu czasu / budżetu lub wykonaniu wszystkich scenariuszy testowych. Jednak przy takim podejściu pójdziemy na kompromis w kwestii jakości testowania, a to nie da wystarczającej pewności co do oprogramowania; w jaki sposób?

Zobaczmy zprzykład.

Scenariusz testowy:

Załóżmy, że testujesz moduł oprogramowania. Otrzymałeś określony budżet na jego pokrycie. Terminy realizacji projektu obejmują miesiąc. Wszystkich scenariuszy testowych jest 200. Tylko Ty testujesz ten moduł.

Scenariusz 1)

Tydzień 1: W pierwszym dniu znajdujesz błąd showstopper / severity 1, a całe testy są blokowane na 3 dni. W związku z tym nie możesz zrealizować żadnego ze scenariuszy do czasu usunięcia usterki o Poziomie ważności 1. Po utracie 3 dni bloker zostanie rozwiązany i kontynuujesz wykonanie.

Pod koniec tygodnia wykonujesz 20 scenariuszy z kilkoma ważniejszymi szczytami wady priorytetowe .

Tydzień 2: Zaczynasz testować oprogramowanie, kładąc większy nacisk na znajdowanie defektów. Otwierasz jeszcze kilka usterek o Poziomie 1, 2 i 3 w drugim tygodniu, a pod koniec tygodnia możesz pokryć 70 Scenariuszy.

Tydzień 3: Na początku 3^{r & D}tydzień, w którym wszystkie usterki o wysokim priorytecie zostaną usunięte, więc wraz z wykonaniem oczekujących scenariuszy musisz teraz ponownie przetestować wszystkie defekty, które trafiły do ​​wiadra testowego. Kontynuując dobry postęp, obejmiesz 120 scenariuszy z dodatkowymi defektami.

Do tego czasu wszystkie usterki o wysokim priorytecie są już wykrywane i zgłaszane. Zatem teraz do znalezienia pozostały tylko defekty o Poziomie 3.

Tydzień 4: Do 4 tygodnia musisz ponownie przetestować większość otwartych błędów i pozostałych 80 Scenariuszy. Dzięki temu do końca 4 tygodnia możesz ukończyć do 180 scenariuszy z naprawionymi i ponownie przetestowanymi wszystkimi usterkami o wysokim i średnim priorytecie.

Umieszczanie tych informacji w formie tabelarycznej:

Czy powinieneś się tutaj zatrzymać?

Powód, który wyczerpałeś Całkowity czas testowania oraz zgłosili i naprawili większość usterek o wysokim priorytecie. Czy zatrzymanie się w tym momencie da Ci pewność co do oprogramowania? Niezupełnie z poniższych powodów:

• Scenariusze nie są wykonywane w całości.
• Niewiele przepływów nie jest nawet testowanych raz.
• Wszystkie objęte scenariusze są wykonywane tylko raz.
• Oprogramowanie nadal zawiera wady.
• Regresja nie jest uwzględniona.

Scenariusz 2)

Tydzień 1: W pierwszym dniu znajdujesz usterkę o poziomie ważności 1, a pełne testowanie jest blokowane na 3 dni. W związku z tym nie możesz zrealizować żadnego ze scenariuszy do czasu rozwiązania Wady o Poziomie Ważności 1. Po utracie 3 dni bloker został rozwiązany i kontynuujesz wykonanie.

Pod koniec tygodnia wykonujesz 20 scenariuszy z kilkoma dodatkowymi defektami. Ten tydzień pozostaje taki sam jak w scenariuszu 1.

Tydzień 2: Otwierasz jeszcze kilka usterek o Poziomie 1, 2 i 3 w drugim tygodniu, ale celem jest uwzględnienie większej liczby scenariuszy w celu pokrycia zaległości z 1. tygodnia. Pod koniec tygodnia jesteś w stanie pokryć 120 Scenariuszy.

Tydzień 3: Na początku 3^{r & D}tydzień, w którym wszystkie otwarte usterki zostaną rozwiązane, więc wraz z wykonaniem oczekujących scenariuszy musisz teraz ponownie przetestować wszystkie defekty, które trafiają do wiadra testowego. Wciąż z dobrym postępem pod koniec liczba ukończonych scenariuszy osiąga 200 z dodatkowymi defektami.

Teraz możesz zgłaszać tylko usterki o poziomie ważności 2 i 3.

Umieszczanie tych informacji w formie tabelarycznej:

Czy powinieneś się tutaj zatrzymać?

Ty masz całkowicie objął wszystkie scenariusze testowania raz i otworzyłem kilka poważnych wad. Czy zatrzymanie się w tym momencie da Ci pewność co do oprogramowania?

Niezupełnie z poniższych powodów:

• Wszystkie scenariusze są wykonywane tylko raz.
• Oprogramowanie wciąż ma wiele poważnych wad.
• Regresja nie jest uwzględniona.

Widzimy, że jakość jest zagrożona w obu powyższych scenariuszach. Najlepszym podejściem będzie znalezienie punktu, w którym uwzględnione zostaną wszystkie czynniki ze scenariusza 1 i scenariusza 2, a jakość również nie zostanie obniżona. Aby to osiągnąć, na początku testów będziemy musieli zdefiniować określone kryteria.

Kryteria te określane są jako kryteria ukończenia lub zakończenia. To odpowiedź na nasze pytanie - „Kiedy przestać testować?”.

Co to są kryteria ukończenia lub zakończenia?

Kryteria zakończenia są oceniane na koniec cyklu testowego i są zdefiniowane w Planie testów. Jest to zbiór warunków lub czynności, które muszą zostać spełnione, aby zakończyć badanie.

Kryteria zakończenia określają, ile testów wystarczy i kiedy można zadeklarować ukończenie czynności testowych. Pokrycie a kryteria ukończenia są łączone, aby zdefiniować kryteria zakończenia testowania.

Co powinno znajdować się w kryteriach wyjścia?

W idealnym przypadku kryteria zakończenia lub zatrzymania są definiowane przez połączenie różnych czynników i dlatego są unikalne dla wszystkich projektów. Zależy to od wymagań projektu i dlatego należy je zdefiniować podczas planowania testów; na początku projektu. Zdefiniowane w nim parametry powinny być w miarę możliwości kwantyfikowane.

Poniżej znajduje się kilka wskazówek, które należy wziąć pod uwagę podczas definiowania kryteriów wyjścia w przypadku testów funkcjonalnych lub systemowych. Możesz połączyć kilka lub wszystkie poniższe czynniki, decydując, gdzie przerwać testowanie zgodnie z potrzebami projektu.

Testowanie można zatrzymać, gdy:

Wymagania:

• 100% pokrycia wymagań.

Wady:

• Osiągnięto zdefiniowaną / żądaną liczbę defektów.
• Wszystkie usterki lub blokady Pokaż Stopper są naprawione i żaden znany defekt krytyczny / o istotności 1 nie ma stanu Otwarcia.
• Wszystkie usterki o wysokim priorytecie są identyfikowane i naprawiane.
• Współczynnik defektów spada poniżej zdefiniowanej dopuszczalnej wartości.
• Bardzo niewiele usterek o średnim priorytecie jest otwartych i można je obejść.
• Bardzo niewiele otwartych defektów o niskim priorytecie, które nie mają wpływu na użycie oprogramowania.
• Wszystkie defekty o wysokim priorytecie są ponownie testowane i zamykane, a odpowiednie scenariusze regresji są pomyślnie wykonywane.

Pokrycie testowe:

• Pokrycie testowe powinno zostać osiągnięte w 95%.
• Współczynnik pomyślności przypadku testowego powinien wynosić 95%. Można to obliczyć według wzoru
  • (Łączna liczba pozytywnych TC / łączna liczba TC) * 100.
• Wszystkie krytyczne przypadki testowe są zaliczane.
• 5% przypadków testowych może zakończyć się niepowodzeniem, ale przypadki testowe zakończone niepowodzeniem mają niski priorytet.
• Osiągnięto pełne pokrycie funkcjonalne.
• Wszystkie główne przepływy funkcjonalne / biznesowe są pomyślnie wykonywane z różnymi danymi wejściowymi i działają dobrze.

Terminy:

• Termin zakończenia projektu lub zakończenia testu został osiągnięty.

Dokumenty testowe:

• Wszystkie dokumenty testowe / produkty (przykład - Raport podsumowujący test ) są przygotowywane, recenzowane i publikowane.

Budżet:

• Całkowity budżet testów został wyczerpany.

Spotkania „Go / No Go”:

• ' Idź / Nie idź ' spotkanie została przeprowadzona z interesariuszami i podejmowana jest decyzja, czy projekt powinien przejść do produkcji, czy nie.

Wniosek:

Na koniec zróbmy to bardzo prosto.

Odpowiedz na pytania prostym tak lub nie.

jak zrobić tablicę ciągów w java

Jeśli większość odpowiedzi brzmi „tak”, oznacza to, że w tym momencie można przerwać testowanie. Jeśli większość odpowiedzi brzmi `` nie '', oznacza to, że musisz sprawdzić, czego brakuje w testowaniu, a to może pomóc w znalezieniu uciekającej usterki produkcyjnej :)

• Czy wszystkie przypadki testowe są wykonywane przynajmniej raz?
• Czy współczynnik pozytywnego wyniku testu jest zgodny z definicją?
• Czy osiągnięto pełne pokrycie testu?
• Czy wszystkie przepływy funkcjonalne / biznesowe są wykonywane przynajmniej raz?
• Czy osiągnięto zdecydowaną liczbę wad?
• Czy wszystkie poważne usterki o wysokim priorytecie zostały naprawione i zamknięte?
• Czy wszystkie wady zostały ponownie przetestowane i zamknięte?
• Czy przeprowadzono regresję dla wszystkich otwartych defektów?
• Czy wyczerpałeś budżet na testy?
• Czy nadszedł czas zakończenia testowania?
• Czy wszystkie materiały testowe są sprawdzane i publikowane?

O autorze: To jest gościnny artykuł autorstwa Renuka K. Ma ponad 11 lat doświadczenia w testowaniu oprogramowania.

Mam nadzieję, że ten artykuł był dla Ciebie pomocny. Chciałbym również poznać Twoje przemyślenia / komentarze na ten temat.

Miłego testowania!

rekomendowane lektury

• Najlepsze narzędzia do testowania oprogramowania 2021 (Narzędzia do automatyzacji testów QA)
• Asystent testowania oprogramowania
• Sylabus kursu testowania oprogramowania - szczegółowy plan szkolenia kursu online
• 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
• Kilka interesujących pytań do rozmowy kwalifikacyjnej dotyczącej testowania oprogramowania
• Opinie i recenzje dotyczące kursu testowania oprogramowania