Co to jest błąd?
Błąd jest konsekwencją / wynikiem błędu w kodowaniu.
Wada testowania oprogramowania
Defect w testowaniu oprogramowania jest odmianą lub odchylenie od wymagań aplikacji użytkownika końcowego lub oryginalnych wymagań biznesowych. Wada oprogramowania to błąd w kodowaniu, który powoduje nieprawidłowe lub nieoczekiwane wyniki programu, który nie spełnia rzeczywistych wymagań. Testerzy mogą napotkać takie defekty podczas wykonywania przypadków testowych.
Te dwa terminy mają bardzo cienką linię różnic. W branży oba są usterkami, które muszą zostać naprawione, a więc używane zamiennie przez niektóre zespoły testujące.
Kiedy testerzy wykonują przypadki testowe, mogą natknąć się na takie wyniki testów, które są sprzeczne z oczekiwanymi wynikami. Ta różnica w wynikach testów jest określana jako Wada Oprogramowania. Te wady lub odmiany są określane różnymi nazwami w różnych organizacjach, takich jak problemy, problemy, błędy lub incydenty.
W tym samouczku nauczysz się:
- Zgłoszenie błędu
- Proces zarządzania defektami
- Odkrycie
- Kategoryzacja
- Rozkład
- Weryfikacja
- Zamknięcie
- Raportowanie
- Ważne wskaźniki defektów
Raport o błędzie w testowaniu oprogramowania
Bug Report w testowaniu oprogramowania jest szczegółowy dokument na temat błędów znalezionych w oprogramowaniu. Raport błędu zawiera wszystkie szczegóły dotyczące błędów, takie jak opis, data znalezienia błędu, nazwisko testera, który go znalazł, nazwisko programisty, który go naprawił, itp. Raport błędu pomaga zidentyfikować podobne błędy w przyszłości, aby można było ich uniknąć.
Zgłaszając błąd do programisty, Twój raport o błędzie powinien zawierać następujące informacje
- Defect_ID - Unikalny numer identyfikacyjny wady.
- Opis Wady - Szczegółowy opis Wady wraz z informacją o module, w którym wykryto Wadę.
- Wersja - wersja aplikacji, w której wykryto usterkę.
- Kroki - szczegółowe kroki wraz ze zrzutami ekranu, za pomocą których programista może odtworzyć wady.
- Data podniesienia - data zgłoszenia wady
- Odniesienie - gdzie w tobie Podaj odniesienie do dokumentów, takich jak. wymagania, projekt, architektura, a może nawet zrzuty ekranu błędu, aby pomóc w zrozumieniu usterki
- Wykryty przez - nazwa / identyfikator testera, który zgłosił usterkę
- Status - stan wady, więcej o tym później
- Naprawione przez - nazwa / identyfikator dewelopera, który to naprawił
- Data zamknięcia - data zamknięcia usterki
- Waga opisująca wpływ wady na aplikację
- Priorytet związany z pilnością usuwania usterek. Priorytet ważności może być odpowiednio Wysoki / Średni / Niski w zależności od pilności wpływu, przy którym usterka powinna zostać naprawiona
Kliknij tutaj, jeśli wideo nie jest dostępne
Zasoby
Pobierz przykładowy szablon zgłaszania defektów
Jako Kierownik Testów weź pod uwagę następujące kwestie
Twój zespół znalazł błędy podczas testowania projektu bankowego Guru99.
Po tygodniu deweloper odpowiada -
W przyszłym tygodniu tester odpowiada
Podobnie jak w powyższym przypadku, jeśli komunikacja wady odbywa się werbalnie, wkrótce sytuacja staje się bardzo skomplikowana. Aby kontrolować i skutecznie zarządzać błędami, potrzebny jest cykl życia defektu.
Co to jest proces zarządzania defektami?
Zarządzanie defektami to systematyczny proces identyfikowania i naprawiania błędów. Cykl zarządzania defektami składa się z następujących etapów: 1) Wykrywanie usterki, 2) Kategoryzacja usterek 3) Naprawianie usterki przez programistów 4) Weryfikacja przez testerów 5) Zamknięcie usterki 6) Raporty o usterkach na koniec projektu
W tym temacie dowiesz się, jak zastosować proces zarządzania defektami na stronie internetowej Banku Guru99 projektu. Możesz wykonać poniższe kroki, aby zarządzać defektami.
Odkrycie
Na etapie odkrywania zespoły projektowe muszą wykryć jak najwięcej defektów , zanim klient końcowy będzie mógł je odkryć. Mówi się, że wada zostanie wykryta i zmieni stan na zaakceptowany, gdy zostanie potwierdzona i zaakceptowana przez programistów
W powyższym scenariuszu testerzy odkryli 84 usterki w serwisie Guru99.
Spójrzmy na następujący scenariusz; Twój zespół testowy odkrył pewne problemy w witrynie banku Guru99. Uważają je za wady i zgłosili do zespołu programistów, ale jest konflikt -
W takim przypadku, jako Kierownik Testów, co będziesz robić?
A) Zgadzam się z zespołem testowym, że jest to wada
B) Kierownik Testów przyjmuje rolę sędziego, który decyduje, czy problem jest defektem, czy nie
C) Zgadzam się z zespołem programistów, który nie jest usterką. Correct InCorrect
W takim przypadku w celu rozwiązania konfliktu należy zastosować proces rozwiązywania, a Ty podejmujesz rolę sędziego, który decyduje, czy problem z witryną jest wadą, czy nie.
Kategoryzacja
Kategoryzacja defektów pomaga twórcom oprogramowania w ustalaniu priorytetów ich zadań. Oznacza to, że ten rodzaj priorytetu pomaga programistom w naprawieniu najpierw tych defektów, które są bardzo istotne.
Wady są zwykle kategoryzowane przez Kierownika Testów -
Zróbmy małe ćwiczenie, jak poniżej Przeciągnij i upuść priorytet defektu poniżej
- Krytyczny
- Wysoki
- Średni
- Niska
| 1) Witryna działa zbyt wolno |
|
| 2) Funkcja logowania w witrynie nie działa poprawnie |
|
| 3) GUI witryny nie wyświetla się poprawnie na urządzeniach mobilnych |
|
| 4) Serwis nie mógł zapamiętać sesji logowania użytkownika |
|
| 5) Niektóre linki nie działają |
|
Oto zalecane odpowiedzi
| Nie. | Opis | Priorytet | Wyjaśnienie |
|---|---|---|---|
| 1 | Witryna działa zbyt wolno | Wysoki | Błąd wydajności może powodować ogromne niedogodności dla użytkownika. |
| 2 | Funkcja logowania w witrynie nie działa poprawnie | Krytyczny | Logowanie jest jedną z głównych funkcji serwisu bankowego, jeśli ta funkcja nie działa, są to poważne błędy |
| 3 | GUI witryny nie wyświetla się poprawnie na urządzeniach mobilnych | Średni | Wada dotyczy użytkownika korzystającego ze smartfona do przeglądania strony internetowej. |
| 4 | Serwis nie mógł zapamiętać sesji logowania użytkownika | Wysoki | Jest to poważny problem, ponieważ użytkownik będzie mógł się zalogować, ale nie będzie mógł wykonywać żadnych dalszych transakcji |
| 5 | Niektóre linki nie działają | Niska | Jest to łatwa poprawka dla programistów, a użytkownik nadal może uzyskać dostęp do witryny bez tych linków |
Rozwiązanie wady
Rozwiązywanie defektów w testowaniu oprogramowania to krok po kroku proces naprawiania defektów. Proces rozwiązywania defektów rozpoczyna się od przypisania defektów programistom, następnie programiści planują naprawę usterki według priorytetu, następnie usterki są naprawiane, a na koniec programiści wysyłają raport rozwiązania do kierownika testów. Ten proces pomaga w łatwym naprawianiu i śledzeniu usterek.
Możesz wykonać następujące kroki, aby naprawić usterkę.
- Zadanie : przydzielone programiście lub innemu technikowi do naprawy i zmieniło stan na Odpowiada .
- Ustalanie harmonogramu : na tym etapie kontrolę przejmuje strona deweloperska. Stworzą harmonogram naprawy tych defektów, w zależności od priorytetu defektu.
- Napraw usterkę : Podczas gdy zespół programistów naprawia usterki, Kierownik Testów śledzi proces naprawiania usterki w porównaniu z powyższym harmonogramem.
- Zgłoś rozwiązanie : Uzyskaj raport rozwiązania od programistów, gdy usterki zostaną naprawione.
Weryfikacja
Gdy zespół programistów naprawił i zgłosił usterkę, zespół testujący sprawdza , czy usterki zostały faktycznie naprawione.
Na przykład w powyższym scenariuszu, gdy zespół programistów zgłosił, że naprawił już 61 usterek, Twój zespół przeprowadziłby ponowne testy, aby sprawdzić, czy te usterki zostały faktycznie naprawione, czy nie.
Zamknięcie
Po usunięciu i zweryfikowaniu wady usterka zmienia status na zamkniętą . Jeśli nie, wyślij powiadomienie do dewelopera, aby ponownie sprawdzić usterkę.
Zgłaszanie defektów
Raportowanie defektów w testowaniu oprogramowania to proces, w którym kierownicy testów przygotowują i wysyłają raport defektu do zespołu zarządzającego w celu uzyskania informacji zwrotnej na temat procesu zarządzania defektami i statusu defektów. Następnie zespół zarządzający sprawdza raport o usterce i wysyła informacje zwrotne lub zapewnia dalsze wsparcie, jeśli jest to konieczne. Zgłaszanie defektów pomaga lepiej komunikować się, śledzić i szczegółowo wyjaśniać defekty.
Zarząd ma prawo znać stan usterki. Muszą zrozumieć proces zarządzania defektami, aby wesprzeć Cię w tym projekcie. Dlatego musisz zgłosić im obecną sytuację wady, aby uzyskać od nich informacje zwrotne.
Ważne wskaźniki defektów
Wróć do powyższego scenariusza. Deweloperzy i zespoły testowe dokonały przeglądu zgłoszonych usterek. Oto wynik tej dyskusji
Jak mierzyć i oceniać jakość wykonania testów?
To jest pytanie, które chce wiedzieć każdy Kierownik Testów. Istnieją 2 parametry, które można rozważyć w następujący sposób
W powyższym scenariuszu można obliczyć współczynnik odrzucenia defektów (DRR) na poziomie 20/84 = 0,238 (23,8%).
Inny przykład, zakładając, że strona internetowa Guru99 Bank ma łącznie 64 usterki, ale Twój zespół testujący wykrywa tylko 44 usterki, tj. Pominął 20 usterek. Dlatego można obliczyć współczynnik wycieku defektu (DLR) na 20/64 = 0,312 (31,2%).
Podsumowując, jakość wykonania testu jest oceniana za pomocą następujących dwóch parametrów
Im mniejsza wartość DRR i DLR, tym lepsza jakość wykonania testu. Jaki jest dopuszczalny zakres współczynnika ? Zakres ten można zdefiniować i zaakceptować jako podstawę w celu projektu lub można odnieść się do metryk podobnych projektów.
W tym projekcie zalecana wartość dopuszczalnego wskaźnika to 5 ~ 10%. Oznacza to, że jakość wykonania testów jest niska. Powinieneś znaleźć środek zaradczy, aby zmniejszyć te współczynniki, takie jak
- Popraw umiejętności testowania członka.
- Poświęć więcej czasu na wykonanie testów, zwłaszcza na przeglądanie wyników wykonania testów.