STLC - Szybki przewodnik

STLC oznacza cykl życia testowania oprogramowania. STLC to sekwencja różnych czynności wykonywanych przez zespół testujący w celu zapewnienia jakości oprogramowania lub produktu.

• STLC jest integralną częścią cyklu życia oprogramowania (SDLC). Ale STLC zajmuje się tylko fazami testowania.

• STLC rozpoczyna się natychmiast po zdefiniowaniu wymagań lub udostępnieniu interesariuszy SRD (dokument wymagań oprogramowania).

• STLC zapewnia proces krok po kroku w celu zapewnienia wysokiej jakości oprogramowania.

• Na wczesnym etapie STLC, podczas gdy oprogramowanie lub produkt jest rozwijane, tester może analizować i definiować zakres testów, kryteria wejścia i wyjścia, a także Przypadki Testowe. Pomaga skrócić czas cyklu testowego i poprawia jakość.

• Gdy tylko faza rozwoju dobiegnie końca, testerzy są gotowi z przypadkami testowymi i rozpoczynają wykonanie. Pomaga to znaleźć błędy w początkowej fazie.

Fazy ​​STLC

STLC ma następujące różne fazy, ale nie jest obowiązkowe przestrzeganie wszystkich faz. Fazy ​​zależą od rodzaju oprogramowania lub produktu, czasu i zasobów przeznaczonych na testowanie oraz modelu SDLC, który ma być przestrzegany.

Istnieje 6 głównych faz STLC -

• Requirement Analysis - Kiedy SRD jest gotowy i udostępniony interesariuszom, zespół testujący rozpoczyna analizę wysokiego poziomu dotyczącą AUT (testowana aplikacja).

• Test Planning - Zespół testowy planuje strategię i podejście.

• Test Case Designing - Opracuj przypadki testowe w oparciu o zakres i kryteria.

• Test Environment Setup - Gdy zintegrowane środowisko jest gotowe do walidacji produktu.

• Test Execution - Walidacja produktu w czasie rzeczywistym i znajdowanie błędów.

• Test Closure - Po zakończeniu testów, matryce, raporty i wyniki są dokumentowane.

W tym rozdziale zrozumiemy czynniki porównania między STLC i SDLC. Rozważmy następujące punkty, a tym samym porównajmy STLC i SDLC.

• STLC jest częścią SDLC. Można powiedzieć, że STLC jest podzbiorem zbioru SDLC.

• STLC ogranicza się do fazy testowania, w której zapewnia jakość oprogramowania lub produktu. SDLC odgrywa ogromną i istotną rolę w pełnym rozwoju oprogramowania lub produktu.

• Jednak STLC jest bardzo ważną fazą SDLC i produktu końcowego lub oprogramowania nie można wydać bez przejścia przez proces STLC.

• STLC jest również częścią cyklu po wydaniu / aktualizacji, czyli fazie konserwacji SDLC, w której znane usterki są naprawiane lub do oprogramowania dodawana jest nowa funkcjonalność.

Poniższa tabela zawiera listę czynników porównania między SDLC i STLC na podstawie ich faz -

Faza	SDLC	STLC
Gromadzenie wymagań	Analityk biznesowy zbiera wymagania. Zespół programistów analizuje wymagania. Po osiągnięciu wysokiego poziomu, zespół programistów rozpoczyna analizę od strony architektury i projektowania.	Zespół testujący przegląda i analizuje dokument SRD. Identyfikuje wymagania testowe - kluczowe punkty dotyczące zakresu, weryfikacji i walidacji. Dokonuje przeglądu wymagań dotyczących relacji logicznych i funkcjonalnych między różnymi modułami. Pomaga to w identyfikacji luk na wczesnym etapie.
Projekt	Architektura SDLC pomaga opracować wysokopoziomowy i niskopoziomowy projekt oprogramowania w oparciu o wymagania. Analityk biznesowy pracuje nad kpiną z projektowania UI. Po zakończeniu projektu jest on podpisywany przez interesariuszy.	W STLC strategię testów zazwyczaj planuje architekt testów lub kierownik testów. Identyfikuje punkty testowe. Przydział zasobów i ramy czasowe są finalizowane tutaj.
Rozwój	Zespół programistów rozpoczyna tworzenie oprogramowania. Integracja z różnymi systemami. Po zakończeniu integracji dostarczane jest gotowe do przetestowania oprogramowanie lub produkt.	Zespół testujący pisze scenariusze testów, aby zweryfikować jakość produktu. Szczegółowe przypadki testowe są napisane dla wszystkich modułów wraz z oczekiwanym zachowaniem. Wymagania wstępne oraz kryteria wejścia i wyjścia modułu testowego są określone w tym miejscu.
Konfiguracja środowiska	Zespół programistów tworzy środowisko testowe z opracowanym produktem do walidacji.	Zespół testowy potwierdza skonfigurowane środowisko w oparciu o wymagania wstępne. Wykonuje testy dymu, aby upewnić się, że środowisko jest stabilne dla testowanego produktu.
Testowanie	Właściwe testy są przeprowadzane w tej fazie. Obejmuje testowanie jednostkowe, testowanie integracji, testowanie systemu, ponowne testowanie defektów, testy regresyjne itp. Zespół programistów naprawia zgłoszony błąd, jeśli występuje, i odsyła go do testera w celu ponownego przetestowania. Testowanie UAT przeprowadza się tutaj po wylogowaniu się z testów SIT.	Testowanie integracji systemu rozpoczyna się na podstawie przypadków testowych. Ewentualne zgłoszone usterki są ponownie testowane i naprawiane. Przeprowadzane są tutaj testy regresyjne, a produkt zostaje wyrejestrowany po spełnieniu kryteriów zakończenia.
Wdrożenie / wydanie produktu	Po otrzymaniu potwierdzenia od różnych zespołów testowych aplikacja jest wdrażana w środowisku produkcyjnym dla rzeczywistych użytkowników końcowych.	Testowanie dymu i normalności w środowisku produkcyjnym jest wykonywane tutaj, gdy tylko produkt zostanie wdrożony. Raporty z testów i przygotowanie matryc są wykonywane przez zespół testowy w celu analizy produktu.
Konserwacja	Obejmuje wsparcie po wdrożeniu, ulepszenia i aktualizacje, jeśli takie istnieją.	Na tym etapie utrzymywanie przypadków testowych, kombinezonów regresji i skryptów automatyzacji odbywa się w oparciu o ulepszenia i aktualizacje.

Wspólnym celem testowania jest jak najwcześniejsze znajdowanie błędów. Po naprawieniu błędów upewnij się, że działa zgodnie z oczekiwaniami i nie psuje żadnej innej funkcjonalności.

Aby osiągnąć te cele, podano siedem podstawowych zasad testowania oprogramowania -

Co pokazuje testowanie?

Testy mogą wykazać, że występują wady, ale nie ma sposobu, aby udowodnić, że nie ma wady produktu. Fazy ​​testowania zapewniają, że testowana aplikacja działa w oparciu o zadane wymaganie i pomaga zmniejszyć prawdopodobieństwo nieodkrytych defektów w aplikacji. Ale nawet jeśli nie zostaną znalezione żadne wady, nie oznacza to, że jest to absolutnie poprawne. Możemy założyć, że AUT pasuje do naszych kryteriów wyjścia i zachowuje wymagania zgodnie z SRD.

Czy możliwe jest przeprowadzenie wyczerpujących testów?

100% pokrycia lub przetestowanie wszystkich kombinacji danych wejściowych i możliwych kombinacji nie jest możliwe, z wyjątkiem trywialnych przypadków. Zamiast wyczerpującego testowania, do określenia zakresu testów stosuje się analizę ryzyka i priorytety. Tutaj można rozważyć większość scenariuszy w czasie rzeczywistym, w tym najbardziej prawdopodobny scenariusz negatywny. Pomoże nam to śledzić awarię.

Wczesne testy

Czynności testowe powinny rozpocząć się jak najszybciej i skupić się na celach zdefiniowanych w strategii testów i oczekiwanych wynikach. Wczesny etap testowania pomaga zidentyfikować defekt wymagania lub rozbieżności na poziomie projektu. Jeśli tego typu błędy zostaną wychwycone na początkowym etapie, pomaga nam to zaoszczędzić czas i jest również opłacalne. Odpowiedź na pytanie, dlaczego testowanie powinno rozpoczynać się na wczesnym etapie, jest bardzo prosta - po otrzymaniu SRD testerzy mogą przeanalizować wymaganie z perspektywy testowania i zauważyć rozbieżność wymagań.

Grupowanie defektów

Na podstawie wcześniejszej analizy defektów produktu można stwierdzić, że większość defektów jest identyfikowana za pomocą małego zestawu modułów, które są krytyczne dla aplikacji. Moduły te można zidentyfikować na podstawie złożoności, różnych interakcji systemu lub zależności od różnych innych modułów. Jeśli testerzy mogą zidentyfikować te kluczowe moduły, mogą bardziej skoncentrować się na tych modułach, aby zidentyfikować wszystkie możliwe błędy. W badaniu stwierdzono, że 8 na 10 defektów jest zidentyfikowanych na podstawie 20% funkcjonalności AUT.

Paradoks pestycydów

Co to jest paradoks pestycydów - jeśli pestycydy są często stosowane na uprawach, pojawia się pewien rodzaj odporności owadów i stopniowo rozpylane pestycydy wydają się nieskuteczne dla owadów.

Ta sama koncepcja ma również zastosowanie do testowania. Tutaj owady to błędy, podczas gdy pestycydy to przypadki testowe, które są używane wielokrotnie. Jeśli te same zestawy przypadków testowych są wykonywane wielokrotnie, te przypadki testowe stają się nieskuteczne po pewnym czasie i testerzy nie będą w stanie zidentyfikować żadnego nowego defektu.

Aby przezwyciężyć te warunki, przypadki testowe powinny być korygowane i weryfikowane od czasu do czasu, a także można dodawać nowe i różne przypadki testowe. Pomoże to w identyfikacji nowych defektów.

Testowanie zależy od kontekstu

Ta zasada stanowi, że nie można testować dwóch różnych typów aplikacji przy użyciu tego samego podejścia, dopóki obie aplikacje nie będą miały tego samego charakteru. Na przykład, jeśli tester stosuje to samo podejście do aplikacji internetowych i aplikacji mobilnych, jest to całkowicie błędne i istnieje wysokie ryzyko niskiej jakości wydania produktu. Testerzy powinni stosować różne podejścia, metodologie, techniki i zakresy dla różnych typów i charakteru aplikacji.

Brak błędu - błąd

Zasada ta mówi o znajdowaniu usterek i ich naprawianiu, dopóki aplikacja lub system nie będzie stabilny, jest czasochłonny, a także pochłania zasoby. Nawet po naprawieniu 99% wad istnieje duże ryzyko niestabilnej aplikacji. Pierwszą niezbędną rzeczą jest zweryfikowanie stabilności aplikacji i wymagań wstępnych środowiska. Jeśli te dwa warunki są spełnione, dopiero wtedy możemy rozpocząć szczegółowe testy.

Analiza wymagań jest pierwszą fazą STLC i rozpoczyna się, gdy tylko SRD / SRS zostanie udostępniony zespołowi testującemu. Rozważmy następujące punkty, aby zrozumieć analizę wymagań w STLC.

• Kryterium wejścia na tę fazę to zapewnienie SRS (Specyfikacja Wymagań Oprogramowania); zaleca się również, aby architektura aplikacji była poręczna.

• Na tym etapie zespół ds. Kontroli jakości analizuje na wyższym poziomie, co i jak testować.

• Zespół ds.Kontroli jakości współpracuje z różnymi interesariuszami, takimi jak analityk biznesowy, architektura systemu, klient, kierownik / kierownik testów, w przypadku, gdy do zrozumienia wymagania wymagane jest jakiekolwiek zapytanie lub wyjaśnienie.

• Wymagania mogą być funkcjonalne lub niefunkcjonalne, takie jak wydajność, bezpieczeństwo, użyteczność itp. Lub zarówno funkcjonalne, jak i niefunkcjonalne.

• Kryteriami wyjścia z tej fazy jest wypełnienie dokumentu RTM, raportu wykonalności automatyzacji i listy pytań, jeśli ma to zastosowanie, aby bardziej szczegółowo określić wymagania.

Działania wykonywane w celu analizy wymagań

Na tym etapie zespół ds. Zapewnienia jakości wykonuje trzy główne czynności. Działania zostały opisane poniżej.

Definiowanie zakresu

Zespół QA określa zakres testów na wysokim poziomie i dzieli się na różne moduły funkcjonalne. Zespół identyfikuje również rodzaje testów wymaganych do wykonania - testy dymne, testy poprawności, testy funkcjonalne, testy regresyjne itp. Zespół kontroli jakości analizuje wymagania wstępne i szczegóły środowiska, w którym testy mają zostać przeprowadzone. Zespół gromadzi szczegółowe informacje na temat priorytetów testowania i koncentruje się na sekwencji modułów do walidacji. Identyfikuje również defekty wymagań, jeśli zaprzecza się modułom, a funkcjonalność nie jest przenoszona wraz z innymi modułami.

Przygotuj RTM

Śledzenie wymagań to proces dokumentowania powiązań między wymaganiami a produktami pracy opracowanymi w celu wdrożenia i weryfikacji tych wymagań. RTM rejestruje wszystkie wymagania z analizy wymagań wraz z ich identyfikowalnością w jednym dokumencie. Wszystko to jest dostarczane pod koniec cyklu życia.

Matrix jest tworzony na samym początku projektu, ponieważ stanowi podstawę zakresu projektu i produktów, które zostaną wyprodukowane.

Macierz jest dwukierunkowa, ponieważ śledzi wymagania w przód, badając wyniki produktów i wstecz, patrząc na wymaganie biznesowe, które zostało określone dla określonej funkcji produktu.

Analiza automatyzacji

W fazie wymagań zespół QA analizuje zakres automatyzacji testów regresyjnych. Jeśli automatyzacja zostanie dodana w zakresie, zespół decyduje, które narzędzie może zostać użyte, jakie funkcje będą objęte automatyzacją, ramy czasowe i alokację zasobów związanych z rozwojem automatyzacji. Po zakończeniu tej analizy zespół ds. Kontroli jakości dostarcza raport wykonalności automatyzacji różnym interesariuszom w celu zatwierdzenia.

W tym rozdziale zobaczymy kryteria wejścia i wyjścia na różnych poziomach STLC. Aby zrozumieć kryteria, należy wziąć pod uwagę następujące punkty.

W idealnym przypadku zespół ds. Kontroli jakości nie przechodzi do następnej fazy, dopóki nie zostaną spełnione kryteria zakończenia bieżącej fazy. Kryteria wejścia powinny obejmować spełnienie kryteriów wyjścia z poprzedniego etapu.

W czasie rzeczywistym nie można czekać na kolejną fazę do momentu spełnienia kryteriów wyjścia. Teraz można rozpocząć kolejną fazę, jeśli krytyczne rezultaty poprzedniej fazy zostały zakończone.

Na każdym etapie STLC należy określić kryteria wejścia i wyjścia.

Kryteria wejścia

Kryteria wejścia dla faz STLC można zdefiniować jako warunki szczególne; lub wszystkie te dokumenty, które są wymagane do rozpoczęcia określonej fazy STLC, powinny być obecne przed wejściem do którejkolwiek fazy STLC.

Kryteria wejściowe to zestaw warunków, które pozwalają zadaniu wykonać lub w przypadku braku któregokolwiek z tych warunków, zadanie nie może zostać wykonane.

Podczas ustawiania kryteriów wejściowych ważne jest również zdefiniowanie ram czasowych, w których pozycja kryteriów wejściowych jest dostępna, aby rozpocząć proces.

Na przykład, aby rozpocząć fazę opracowywania przypadków testowych, należy spełnić następujące warunki:

• Dokument wymagań powinien być dostępny.
• Wymagane jest pełne zrozumienie przepływu aplikacji.
• Dokument planu testów powinien być gotowy.

Kryteria wyjścia

Kryteria wyjścia dla faz STLC można zdefiniować jako pozycje / dokumenty / czynności / zadania, które muszą zostać zakończone przed zakończeniem bieżącej fazy i przejściem do następnej fazy.

Kryteria wyjścia to zestaw oczekiwań; należy to spełnić przed zakończeniem fazy STLC.

Na przykład, aby zakończyć fazę opracowywania przypadków testowych, należy spełnić następujące oczekiwania -

• Przypadki testowe powinny zostać napisane i przejrzane.
• Dane testowe powinny być zidentyfikowane i gotowe.
• Jeśli to konieczne, skrypt automatyzacji testów powinien być gotowy.

Kryteria akceptacji oznaczają oczekiwane zachowanie funkcjonalności, modułu i aplikacji wymienione w dokumentach wymagań. Są to etapy weryfikacji / punkty kontrolne w celu ustalenia, czy system oprogramowania spełnił wymagania specyfikacji. Głównym celem tego testu jest ocena zgodności systemu z wymaganiami biznesowymi i sprawdzenie, czy spełnia on wymagane kryteria.

Kryteria akceptacji to zestaw instrukcji, które jasno wspominają o oczekiwanym wyniku pozytywnym / negatywnym. Kryteria akceptacji określają zarówno wymagania funkcjonalne, jak i niefunkcjonalne. Te wymagania reprezentują „warunki satysfakcji lub oczekiwanego zachowania”. Nie ma częściowej akceptacji; albo kryterium jest spełnione, albo nie jest spełnione.

Kryteria te określają granice i parametry funkcjonalności / modułu i określają, czy funkcjonalność / moduł jest ukończony i działa zgodnie z oczekiwaniami.

Kryteria akceptacji wysokiego poziomu są wymienione na poziomie planu testów. Kryteria akceptacji są konwertowane na listę punktów do zweryfikowania lub oczekiwanych wyników na poziomie przypadków testowych.

Kryteria akceptacji definiowane są na podstawie następujących atrybutów -

• Funkcjonalna poprawność i kompletność
• Integralność danych
• Konwersja danych
• Usability
• Performance
• Timeliness
• Poufność i dostępność
• Możliwość instalacji i aktualizacji
• Scalability
• Documentation

Plan testów określa strategię, która będzie używana do testowania aplikacji, zasoby, które będą używane, środowisko testowe, w którym testy będą wykonywane, oraz ograniczenia testowania i harmonogram czynności testowych. Zazwyczaj kierownik zespołu ds. Zapewnienia jakości będzie odpowiedzialny za napisanie planu testów.

Co obejmuje plan testów?

Plan testów obejmuje następujące elementy.

• Wprowadzenie do dokumentu planu testów.
• Założenia podczas testowania aplikacji.
• Lista przypadków testowych wchodzących w skład testowania aplikacji.
• Lista funkcji do przetestowania.
• Rodzaj podejścia, jakie należy zastosować podczas testowania oprogramowania.
• Lista produktów do przetestowania.
• Zasoby przeznaczone na testowanie aplikacji.
• Wszelkie ryzyka związane z procesem testowania.
• Harmonogram zadań i kamieni milowych do osiągnięcia.

Ważne punkty dotyczące planowania testów

Podczas planowania testów w STLC należy wziąć pod uwagę następujące punkty.

• W idealnym przypadku analityk testów (wiodący) / kierownik przygotowuje dokument dotyczący strategii testów / planu testów.

• Analiza jest bardziej skoncentrowana na danych / informacjach związanych z aplikacjami.

• To pierwsza faza rzeczywistych zadań testowych.

• Ta faza odpowiada „CO ma być przetestowane” i „JAKIE ZASOBY są wymagane do przetestowania”.

• Podstawowym kryterium wejścia w tej fazie jest dostarczenie Dokumentów Wymagań (zaktualizowana wersja niejasnych / brakujących / wyjaśnionych wymagań) wraz z Matrycą Identyfikowalności Wymagań.

• Jeśli automatyzacja jest w zakresie, przed wejściem w tę fazę należy przygotować Raport wykonalności automatyzacji.

• Kryterium zakończenia tej fazy to ukończenie dokumentu strategii testów / planu testów i dokumentu oszacowania nakładu testowego.

Aspekty fazy planowania testów

Głównym celem tej fazy jest przygotowanie dokumentu planu testów / strategii testów. Obejmuje trzy główne aspekty - zakres rezultatów, oszacowanie nakładu pracy i plan zasobów.

Zakres dostarczanych materiałów

Aby zakończyć zakres produktów, należy wykonać następujące czynności -

• Zidentyfikuj odpowiedni model zaangażowania i realizacji.
• Zdefiniuj cele testów, zakres testów, fazy testowania i czynności.
• Przejrzyj wymagania biznesowe i wymagania systemowe w celu określenia wykonalności testów.
• Zdefiniuj proces testowania, rodzaj testów i procedury.
• Zdefiniuj zarządzanie defektami i procedury zarządzania zmianami.
• Zidentyfikuj narzędzia, techniki i najlepsze praktyki testowe.
• Zdefiniuj analizę ryzyka.
• Zdefiniuj rozwiązanie do automatyzacji i zidentyfikuj odpowiednich kandydatów do automatyzacji, jeśli ma to zastosowanie.

Szacowanie wysiłku

Szacowanie to proces znajdowania oszacowania lub przybliżenia, które jest wartością, której można użyć do jakiegoś celu, nawet jeśli dane wejściowe mogą być niekompletne, niepewne lub niestabilne.

Oszacowanie określa, ile pieniędzy, wysiłku, zasobów i czasu zajmie zbudowanie określonego systemu lub produktu. Szacunek opiera się na -

• Wcześniejsze dane / wcześniejsze doświadczenia
• Dostępne dokumenty / wiedza
• Assumptions
• Zidentyfikowane ryzyka

Cztery podstawowe kroki szacowania testów to:

• Oszacowanie wielkości AUT (testowana aplikacja).
• Oszacowanie nakładu w osobomiesiącach lub osobogodzinach.
• Oszacowanie harmonogramu w miesiącach kalendarzowych.
• Oszacowanie kosztu projektu w uzgodnionej walucie.

Plan zasobów

Plany zasobów są kluczowym elementem w fazach testowania. Plany te są odwrotnie proporcjonalne do czasu potrzebnego zespołowi testującemu na wykonanie określonego zadania. Zwiększenie liczby zasobów zmniejszy liczbę dni ukończenia dla określonego limitu, po czym zostanie on nasycony, a zwiększenie zasobów nie będzie miało dużego wpływu i może nie prowadzić do zmniejszenia liczby dni ukończenia.

Osoba prosząca o zasoby, zwykle kierownik projektu, tworzy plany zasobów, aby poprosić o zasoby, śledzić wysiłki i koszty. Menedżer zasobów może modyfikować i zatwierdzać plany zasobów przed ich użyciem.

Normalny przepływ pracy dla planu zasobów to -

• Planowanie przez kierownika projektu
• Żądanie zgłoszone przez kierownika projektu
• Zatwierdź / zmodyfikuj / odrzuć przez menedżera zasobów
• Zakończono - zamknięcie żądania po wylogowaniu się przez Menedżera zasobów

Gdy plan testów jest gotowy, zespół QA inicjuje tworzenie przypadków testowych. Głównym celem tej fazy jest przygotowanie przypadków testowych dla pojedynczej jednostki. Te funkcjonalne i strukturalne przypadki testowe obejmują funkcjonalność, punkty weryfikacji i walidacji wymienione w Planie testów.

Poniższe punkty należy wziąć pod uwagę podczas opracowywania przypadków testowych w STLC.

• Na tym etapie zespół ds. Kontroli jakości pisze przypadek testowy, stosując podejście etapowe. Przypadek testowy jest następnie podpisywany przez analityka biznesowego po przejrzeniu lub ponownym opracowaniu przypadków testowych, jeśli wymagane są modyfikacje.

• Gdy przypadki testowe są gotowe, zespół ds. Kontroli jakości przygotowuje dane testowe na podstawie warunków wstępnych.

• Kryterium wejścia do tej fazy jest takie, że czynności związane z planowaniem testów powinny zostać zakończone, a plan testów powinien być gotowy.

• Kryterium wyjścia z tej fazy jest takie, że przypadki testowe powinny być podpisane, dane testowe powinny być gotowe, a skrypty testowe przygotowane, jeśli automatyzacja jest w zakresie.

• Przypadki testowe należy odwzorować za pomocą macierzy śledzenia wymagań, aby śledzić pokrycie wymagań, jeśli cokolwiek zostanie pominięte.

Działania w fazie tworzenia przypadku testowego

Poniżej przedstawiono trzy czynności, które są wykonywane w fazie opracowywania przypadku testowego -

Identyfikacja scenariuszy testowych

Scenariusze ułatwiają testowanie i ocenę złożonego systemu. Poniższe strategie pomagają w tworzeniu dobrych scenariuszy -

• Wymień możliwych użytkowników, ich działania i cele.

• Oceniaj użytkowników z nastawieniem hakera i wypisz możliwe scenariusze nadużyć systemu.

• Wymień zdarzenia systemowe i sposób, w jaki system obsługuje takie żądania.

• Wypisz korzyści i utwórz kompleksowe zadania, aby je sprawdzić.

• Przeczytaj o podobnych systemach i ich zachowaniu.

• Badanie reklamacji produktów konkurencji i ich poprzedników.

Pisanie przypadków testowych

Przypadek testowy to dokument zawierający dane testowe, warunki wstępne, oczekiwane wyniki i warunki końcowe, opracowany dla określonego scenariusza testowego w celu sprawdzenia zgodności z określonym wymaganiem.

Przypadek testowy działa jako punkt wyjścia do wykonania testów. Po zastosowaniu zestawu wartości wejściowych; aplikacja ma ostateczny wynik i opuszcza system w pewnym punkcie końcowym, który jest również nazywany stanem po wykonaniu.

Przygotowanie danych testowych

Dane testowe służą do wykonywania testów na oprogramowaniu testowym. Dane testowe muszą być precyzyjne i wyczerpujące, aby wykryć wady. Aby osiągnąć te trzy cele, stosuje się podejście krokowe, jak podano poniżej -

• Zidentyfikuj zasoby lub wymagania testowe
• Zidentyfikuj warunki / funkcjonalność do przetestowania
• Ustaw priorytetowe warunki testu
• Wybierz warunki testowania
• Określ oczekiwany wynik przetwarzania przypadków testowych
• Utwórz przypadki testowe
• Dokumentuj warunki testu
• Przeprowadź test
• Weryfikuj i poprawiaj przypadki testowe na podstawie modyfikacji

Schemat blokowy aktywności

Poniższy diagram przedstawia różne czynności, które składają się na tworzenie przypadków testowych.

Środowisko testowe składa się z elementów obsługujących wykonywanie testów przy skonfigurowanym oprogramowaniu, sprzęcie i sieci. Konfiguracja środowiska testowego musi naśladować środowisko produkcyjne, aby wykryć wszelkie problemy związane ze środowiskiem / konfiguracją.

Podczas konfiguracji środowiska testowego należy wziąć pod uwagę następujące punkty.

• Jest to połączenie sprzętu i oprogramowania, na którym testy będą wykonywane.

• Obejmuje konfigurację sprzętu, ustawienia systemu operacyjnego, konfigurację oprogramowania, terminale testowe i inne wsparcie do wykonania testu.

• Jest to najważniejszy aspekt procesu testowania. Niedostępność lub błędna konfiguracja środowiska może zrujnować wszystkie wysiłki związane z testowaniem.

• W praktyce zespół ds. Kontroli jakości nie może rozpocząć rzeczywistej pracy bez odpowiedniego środowiska do testów.

• Jest to niezależna czynność, którą można rozpocząć wraz z tworzeniem przypadków testowych.

• Najogólniej czynność ta jest wykonywana przez programistów w aspektach technicznych, podczas gdy warunki wymagań mogą być wykonywane przez klientów / analityków biznesowych.

• Gotowość środowiska testowego można zweryfikować za pomocą testów dymnych i wykonać ją przez zespół QA.

• W idealnym przypadku możemy powiedzieć, że Kryteriami Wejścia do tej fazy jest dostarczenie Planu Testów, gotowość przypadków testowych dymu i przygotowanie danych testowych.

• Kryterium wyjścia z tej fazy jest takie, że środowisko testowe powinno być gotowe, a testowanie dymu powinno być przeprowadzone pomyślnie i z oczekiwanymi wynikami.

Czynności wykonywane w celu skonfigurowania środowiska testowego

W tej fazie wykonywane są następujące czynności.

Zaprojektuj środowisko testowe

Następujące czynniki odgrywają ważną rolę w projektowaniu środowiska testowego.

• Określ, czy środowisko testowe wymaga archiwizacji w celu wykonania kopii zapasowych.

• Sprawdź konfigurację sieci.

• Zidentyfikuj wymagany system operacyjny serwera, bazy danych i inne komponenty.

• Zidentyfikuj liczbę licencji wymaganą przez zespół testowy.

Konfiguracja środowiska

Przeanalizuj wymagania dotyczące konfiguracji środowiska i przygotuj listę wymagań oprogramowania i sprzętu do konfiguracji. Uzyskaj oficjalne potwierdzenie konfiguracji środowiska testowego i skonfiguruj dostęp do środowiska testowego.

Testowanie dymu

Po skonfigurowaniu środowiska i uzyskaniu do niego dostępu przez zespół ds. Zapewnienia jakości, należy przeprowadzić szybką rundę testów dymnych w celu sprawdzenia stabilności kompilacji środowiska testowego. Jeśli wyniki są zgodne z oczekiwaniami, zespół ds. Kontroli jakości może przejść do następnej fazy, w przeciwnym razie wskazać rozbieżności i poczekać na wdrożenie po poprawkach.

Wykonywanie testów to proces wykonywania kodu i porównywania oczekiwanych i rzeczywistych wyników. Podczas wykonywania testów należy wziąć pod uwagę następujące czynniki:

• W oparciu o ryzyko wybierz podzbiór zestawu testów do wykonania w tym cyklu.
• Przypisz przypadki testowe z każdego zestawu testów do testerów do wykonania.
• Wykonuj testy, zgłaszaj błędy i rejestruj stan testów w sposób ciągły.
• Rozwiąż problemy z blokowaniem, gdy się pojawią.
• Raportuj status, dostosowuj przydziały i codziennie ponownie rozważaj plany i priorytety.
• Raportowanie wyników i stanu cyklu testowego.

Podczas wykonywania testów należy wziąć pod uwagę następujące punkty.

• W tej fazie zespół ds. Kontroli jakości przeprowadza faktyczną walidację AUT na podstawie przygotowanych przypadków testowych i porównuje wynik krokowy z oczekiwanym wynikiem.

• Kryterium wejścia do tej fazy to ukończenie Planu Testów i fazy Rozwoju Przypadków Testowych, dane testowe również powinny być gotowe.

• Walidacja konfiguracji środowiska testowego jest zawsze zalecana poprzez testowanie dymu przed oficjalnym wejściem do wykonania testu.

• Kryteria zakończenia wymagają pomyślnej weryfikacji wszystkich przypadków testowych; Wady powinny być zamknięte lub odroczone; Wykonanie przypadku testowego i raport podsumowujący defekty powinny być gotowe.

Działania w celu wykonania testów

Celem tej fazy jest walidacja AUT w czasie rzeczywistym przed przejściem do produkcji / wydania. Aby wypisać się z tej fazy, zespół kontroli jakości przeprowadza różne rodzaje testów, aby zapewnić jakość produktu. Wraz z raportowaniem defektów i ponownym testowaniem jest również kluczowym działaniem na tym etapie. Poniżej przedstawiono ważne czynności w tej fazie -

Testowanie integracji systemów

Prawdziwa walidacja produktu / AUT zaczyna się tutaj. Testowanie integracji systemu (SIT) to technika testowania czarnoskrzynkowego, która ocenia zgodność systemu z określonymi wymaganiami / przygotowanymi przypadkami testowymi.

Testowanie integracji systemu jest zwykle wykonywane na podzbiorze systemu. SIT można przeprowadzić przy minimalnym użyciu narzędzi testujących, zweryfikować pod kątem wymienianych interakcji, a także zbadać zachowanie każdego pola danych w ramach poszczególnych warstw. Po integracji istnieją trzy główne stany przepływu danych -

• Stan danych w warstwie integracji
• Stan danych w warstwie bazy danych
• Stan danych w warstwie aplikacji

Note- Podczas testów SIT zespół QA stara się znaleźć jak najwięcej usterek, aby zapewnić jakość. Głównym celem jest znalezienie jak największej liczby błędów.

Zgłaszanie defektów

Błąd oprogramowania pojawia się, gdy oczekiwany wynik nie zgadza się z rzeczywistym wynikiem. Może to być błąd, wada, awaria lub usterka w programie komputerowym. Większość błędów wynika z błędów i błędów popełnianych przez programistów lub architektów.

Podczas przeprowadzania testów SIT zespół QA znajduje tego typu defekty i należy je zgłosić odpowiednim członkom zespołu. Członkowie podejmują dalsze działania i naprawiają usterki. Kolejną zaletą raportowania jest ułatwienie śledzenia statusu defektów. Istnieje wiele popularnych narzędzi, takich jak ALM, QC, JIRA, Version One, Bugzilla, które obsługują raportowanie i śledzenie defektów.

Raportowanie defektów to proces znajdowania usterek w testowanej aplikacji lub produkcie poprzez testowanie lub rejestrowanie informacji zwrotnych od klientów i tworzenie nowych wersji produktu, które usuwają usterki na podstawie opinii klienta.

Śledzenie defektów jest również ważnym procesem w inżynierii oprogramowania, ponieważ złożone i krytyczne dla firmy systemy mają setki defektów. Jednym z najtrudniejszych czynników jest zarządzanie tymi defektami, ich ocena i priorytetyzacja. Liczba defektów zwielokrotnia się w czasie, a do efektywnego zarządzania nimi stosowany jest system śledzenia defektów ułatwiający pracę.

Mapowanie defektów

Po zgłoszeniu i zarejestrowaniu defektu należy go zmapować z odpowiednimi przypadkami testowymi zakończonymi niepowodzeniem / zablokowanymi i odpowiednimi wymaganiami w macierzy śledzenia wymagań. To mapowanie jest wykonywane przez zgłaszającego defekty. Pomaga sporządzić prawidłowy raport o wadzie i przeanalizować niegrzeczność produktu. Po zmapowaniu przypadków testowych i wymagań z defektem, interesariusze mogą przeanalizować i podjąć decyzję, czy naprawić / odroczyć defekt w oparciu o priorytet i wagę.

Ponowne testowanie

Ponowne testowanie polega na wykonywaniu uprzednio zakończonego niepowodzeniem testu przeciwko AUT w celu sprawdzenia, czy problem został rozwiązany. Po naprawieniu usterki przeprowadza się ponowne testy, aby sprawdzić scenariusz w tych samych warunkach środowiskowych.

Podczas ponownego testowania testerzy szukają szczegółowych szczegółów w zmienionym obszarze funkcjonalności, podczas gdy testy regresyjne obejmują wszystkie główne funkcje, aby zapewnić, że żadna funkcjonalność nie zostanie uszkodzona z powodu tej zmiany.

Testowanie regresji

Gdy wszystkie defekty mają status zamknięty, odroczony lub odrzucony, a żaden z przypadków testowych nie jest w toku / nie powiódł się / nie działa, można powiedzieć, że testowanie integracji systemu jest całkowicie oparte na przypadkach testowych i wymaganiach. Jednak jedna runda szybkiego testowania jest wymagana, aby upewnić się, że żadna z funkcji nie zostanie uszkodzona z powodu zmian kodu / naprawionych defektów.

Testowanie regresyjne to technika testowania czarnoskrzynkowego polegająca na ponownym wykonaniu tych testów, które miały wpływ na zmiany kodu. Testy te powinny być wykonywane tak często, jak to możliwe, przez cały cykl życia oprogramowania.

Rodzaje testów regresji

• Final Regression Tests- „Końcowe testy regresji” są wykonywane w celu sprawdzenia poprawności kompilacji, która nie uległa zmianie przez pewien czas. Ta kompilacja jest wdrażana lub wysyłana do klientów.

• Regression Tests - Zwykłe testy regresyjne są wykonywane w celu sprawdzenia, czy kompilacja NIE uszkodziła żadnych innych części aplikacji przez ostatnie zmiany kodu w celu naprawienia defektów lub rozszerzenia.

Schemat blokowy aktywności

Poniższy schemat blokowy przedstawia ważne czynności wykonywane w tej fazie; pokazuje również zależność z poprzednich faz -

Cykl życia defektu, znany również jako cykl życia błędu, to podróż defektu, cykl, przez który defekt przechodzi w trakcie swojego życia. Różni się w zależności od organizacji, a także od projektu do projektu, ponieważ podlega procesowi testowania oprogramowania, a także zależy od używanych narzędzi.

Cykl życia defektu - przepływ pracy

Poniższy diagram przedstawia przepływ pracy w cyklu życia defektu.

Stany cyklu życia wady

Poniżej przedstawiono różne stany cyklu życia wady.

• New - Potencjalna wada, która została zgłoszona i jeszcze nie została zweryfikowana.

• Assigned - Przydzielony do zespołu programistów, do którego należy się zwrócić.

• Active- Wada jest usuwana przez dewelopera, a dochodzenie jest w toku. Na tym etapie możliwe są dwa wyniki - Odroczony lub Odrzucony.

• Test / Fixed / Ready for Retest - Wada jest naprawiona i gotowa do testowania.

• Verified - Wada, która jest ponownie testowana, a test został zweryfikowany przez QA.

• Closed - Ostateczny stan wady, który można zamknąć po ponownym teście QA lub zamknąć, jeśli wada jest zduplikowana lub nie jest uznana za wadę.

• Reopened - Gdy wada NIE jest naprawiona, kontrola jakości ponownie otwiera / reaktywuje defekt.

• Deferred - Gdy wada nie może być usunięta w tym konkretnym cyklu, jest ona odkładana do przyszłego wydania.

• Rejected - Wadę można odrzucić z jednego z trzech powodów - wada duplikatu, NIE Wada, Niepowtarzalna.

Z punktu widzenia zespołu kontroli jakości usterki są klasyfikowane jako Priority a z punktu widzenia rozwoju jako Severity(złożoność kodu, aby to naprawić). Są to dwie główne klasyfikacje, które odgrywają ważną rolę w ramach czasowych i ilości pracy włożonej w naprawę usterek.

Co to jest priorytet?

Priorytet definiuje się jako kolejność usuwania usterek. Status priorytetu jest zwykle ustalany przez zespół ds. Kontroli jakości, zgłaszając usterkę zespołowi deweloperskiemu, wspominając o czasie na naprawienie usterki. Status Priorytetu jest ustalany na podstawie wymagań użytkowników końcowych.

Na przykład, jeśli logo firmy jest nieprawidłowo umieszczone na stronie internetowej firmy, wówczas priorytet jest wysoki, ale ma niewielki stopień ważności.

Lista priorytetowa

Priorytet można podzielić na następujące kategorie:

• Low - Ta usterka może zostać naprawiona po naprawieniu krytycznych.

• Medium - Wada powinna zostać usunięta w kolejnych kompilacjach.

• High - Usterka musi zostać usunięta natychmiast, ponieważ wada wpływa w znacznym stopniu na aplikację i nie można jej używać, dopóki nie zostanie naprawiona.

• Urgent - Wadę należy usunąć natychmiast, ponieważ wada poważnie wpływa na zastosowanie lub produkt, a produktu nie można używać, dopóki nie zostanie naprawiony.

Co to jest dotkliwość?

Wagę definiuje się jako prostotę defektu w aplikacji i złożoność kodu w celu naprawienia go z punktu widzenia programowania. Itjest związany z aspektem rozwoju produktu. O wadze można zdecydować na podstawie tego, jak zła / kluczowa jest wada systemu. Stan ważności może dać wyobrażenie o odchyleniach w funkcjonalności z powodu defektu.

Example - W przypadku witryny obsługującej loty, błąd w generowaniu numeru biletu w porównaniu z rezerwacją jest poważny, a także ma wysoki priorytet.

Lista ważności

Dotkliwość można podzielić na następujące kategorie -

• Critical /Severity 1- Defekt ma wpływ na najważniejsze funkcje Aplikacji, a zespół ds. Kontroli jakości nie może kontynuować walidacji testowanej aplikacji bez jej naprawienia. Na przykład często dochodzi do awarii aplikacji / produktu.

• Major / Severity 2- Wada wpływa na moduł funkcjonalny; zespół ds. kontroli jakości nie może przetestować tego konkretnego modułu, ale kontynuować walidację innych modułów. Na przykład rezerwacja lotu nie działa.

• Medium / Severity 3- Wada ma problem z jednym ekranem lub jest związana z jedną funkcją, ale system nadal działa. Wada tutaj nie blokuje żadnej funkcjonalności. Na przykład numer biletu to reprezentacja, która nie występuje po odpowiednich znakach alfanumerycznych, takich jak pierwsze pięć znaków i ostatnie pięć jako numeryczne.

• Low / Severity 4- Nie wpływa to na funkcjonalność. Może to być defekt kosmetyczny, niespójność interfejsu użytkownika dla pola lub sugestia, aby poprawić wrażenia użytkownika końcowego po stronie interfejsu użytkownika. Na przykład kolor tła przycisku Wyślij nie jest zgodny z kolorem przycisku Zapisz.

Sprawdzenie kryteriów zakończenia testu jest bardzo istotne, aby stwierdzić, że testowanie zostało zakończone. Przed zakończeniem procesu testowania jakość produktu jest mierzona według kryteriów ukończenia testów.

Kryterium wejścia do tej fazy jest to, że wykonanie przypadku testowego zostało zakończone, wyniki testów są dostępne, a raport defektów jest gotowy.

Kryteria ukończenia testu obejmują:

• Określony zasięg został osiągnięty.
• Nie showstoppers lub krytyczne wady
• Istnieje bardzo niewiele znanych defektów o średnim lub niskim priorytecie. Nie mają one wpływu na użytkowanie produktu.

Kryterium wyjścia z tej fazy jest dostarczenie raportów z zakończenia testów i przygotowanie matryc, które są później podpisywane przez klienta.

Omówmy teraz activities involved in the closure of Test Cycle.

Raport z zakończenia testu

Raportowanie ukończenia testów to proces, w ramach którego metryki testów są raportowane w formie podsumowania w celu zaktualizowania interesariuszy. Dzięki temu mogą podjąć świadomą decyzję.

Raport z zakończenia testu zawiera następujące informacje.

• Identyfikator raportu podsumowania testu
• Summary
• Variances
• Podsumowanie wyników
• Evaluation
• Wysiłki zaplanowane a rzeczywiste
• Wycofać się

Dobry raport z zakończenia testu wskazuje jakość, mierzy nierozwiązane ryzyka i określa poziom testowanego oprogramowania.

Macierz ukończenia testów

Po zakończeniu testów zbierane są różne matryce w celu przygotowania raportów z testów. Kryteria sporządzania raportów obejmują:

• Liczba wykonanych testów
• Liczba zdanych testów
• Liczba testów zakończonych niepowodzeniem
• Liczba testów zakończonych niepowodzeniem na podstawie każdego modułu
• Liczba błędów testowych zgłoszonych podczas cyklu wykonywania
• Liczba zaakceptowanych usterek testowych
• Liczba odrzuconych błędów testowych
• Liczba odroczonych błędów testowych
• Status aktywnych usterek
• Obliczanie wskaźnika jakości konstrukcji

Wyniki testu

Podczas wykonywania przypadku testowego, ponownego testowania defektów i wykonywania przypadku testowego regresji, Test results articulate powinny być zapisane i mogą być tworzone wraz z dokumentami zakończenia cyklu testowego w celu wsparcia zakończenia wykonywania testów.

Artykułami mogą być zrzuty ekranu, wyniki zapytań do bazy danych, nagrania, pliki dziennika itp.