how report test execution smartly
Raportowanie stanu testowania oprogramowania
„Zgoda, że określona informacja w określonym formacie będzie wysyłana przez określony zespół / osobę w określonych odstępach czasu do określonych członków - jest jak uścisk dłoni - potwierdzenie, że niezależnie od wyniku zadania w Wcześniej niż później będziesz o tym informowany ”.
To jest pierwsza część przysięgi informatyka. Cóż, żartuję! Nie ma przysięgi, ale gdyby taka była, z pewnością znalazłaby się na szczycie listy pozycji w niej zawartych. Prawda?
Odpowiedzialność i przejrzystość (A&T) są niezbędne dla każdego projektu IT na różnych poziomach - na poziomie projektu, zespołu, zadania, a także na poziomie indywidualnym. Jak upewniamy się, że te atrybuty są spełnione? Odpowiedź brzmi - komunikując się, bardziej formalnie - Raportowanie statusu !
Na poziomie indywidualnym nie wszyscy wysyłamy codziennie raporty, głównie EOD, aby poinformować o wykonaniu (lub niewykonaniu) swoich codziennych obowiązków. To udowadnia, że faktycznie „jesteście” świadomi tego, od czego mieli zacząć się obowiązki.
Czego się nauczysz:
Codzienny raport o stanie
Informacje, które muszą być częścią „Dziennego raportu o stanie” danej osoby, to:
android pytania i odpowiedzi do wywiadu pdf
- Co robiłeś dzisiaj?
- Co planujesz robić jutro?
- Czy napotkałeś jakieś problemy w ciągu dnia? Jeśli tak, jak je rozwiązałeś, czy nadal są otwarte?
- Czy potrzebujesz środków na jutro? Jeśli tak, od kogo i kim oni są?
Odbiorcą tego e-maila / raportu jest na ogół kierownik, w niektórych przypadkach także członkowie zespołu mogą otrzymać informację zwrotną - zależy to od protokołu komunikacyjnego, którego używa zespół.
Raporty z testów
Nadszedł czas, aby uzyskać szczegółowe informacje i dowiedzieć się wszystkiego o raportach wysyłanych przez zespoły ds. Testów / kontroli jakości.
Zespoły testujące wysyłają różne Raporty na różnych etapach STLC.
- Stan planu testów
- Stan dokumentacji testowej
- Stan wykonania testu (stan defektu)
Plan testów : Wystarczy porozumieć się z pozostałymi zespołami projektowymi, kiedy tworzony jest plan testów lub gdy wprowadzana jest do niego poważna zmiana.
Dokumentacja testowa : Poinformuj wszystkie zespoły o rozpoczęciu projektowania testów, gromadzeniu danych i innych czynnościach, a także o ich zakończeniu. Ten raport nie tylko poinformuje ich o postępie zadania, ale także zasygnalizuje zespołom, które muszą przejrzeć i zatwierdzić artefakty, że są następne.
Wykonanie testu : Realizacja to faza projektu, w której zespół testujący jest głównym celem - pozytywnie i negatywnie - jesteśmy zarówno bohaterami, jak i złoczyńcami.
Typowy dzień podczas cyklu testowego nie jest wykonywany, chyba że zostanie wysłany dzienny raport o stanie. W niektórych zespołach mogliby uzgodnić cotygodniowy raport, ale wysyłanie go codziennie jest normą.
Nierzadko zdarza się również, że codziennie (lub co tydzień) odbywa się spotkanie Status, aby przedstawić status zespołu kontroli jakości zainteresowanym stronom.
najlepsze darmowe oprogramowanie do klonowania dysków twardych 2017
W związku z tym tryb raportu o stanie może być:
- E-mail / dokument
- Spotkanie / prezentacja
- Oba - codzienne e-maile i cotygodniowe spotkania.
Raport o stanie wykonania testu
Raport z dziennego / tygodniowego wykonania testów:
Co to jest? Zwykle jest to komunikat wysyłany w celu zapewnienia przejrzystości działań zespołu ds. Kontroli jakości w ciągu dnia podczas cyklu testowego - obejmuje zarówno informacje o usterce, jak i informacje o przebiegu przypadków testowych.
Do kogo ma się udać? - Zwykle odbiorcami / uczestnikami spotkania są zespół programistów, zespół wsparcia środowiska, analityk biznesowy i zespół projektowy. Plan testów to najlepsze miejsce na znalezienie tych informacji.
Co zawiera raport o stanie wykonania testów? - 10 punktów
- Liczba przypadków testowych zaplanowanych na ten dzień
- Liczba wykonanych przypadków testowych - tego dnia
- Ogólna liczba wykonanych przypadków testowych
- Liczba usterek napotkanych tego dnia / i ich stany
- Liczba napotkanych dotychczas usterek / i ich stany
- Liczba krytycznych usterek - wciąż otwarte
- Przestoje środowiskowe - jeśli występują
- Showstoppers - jeśli istnieją
- Załącznik do arkusza wykonania testu / Link do pliku Narzędzie do zarządzania testami gdzie umieszczane są przypadki testowe
- Załącznik do raportu błędu / link do narzędzia Defect / Test / Management służącego do zarządzania incydentami
Powyższe 10 punktów, jeśli uważnie zauważysz, to surowe dane. Zgłaszanie faktów to jedno, a zgłaszanie „inteligentnych” faktów to co innego . Jak udoskonalamy te informacje?
- Pokazuje ogólny stan za pomocą kolorowego wskaźnika. Na przykład, Zielony - na czas, Pomarańczowy - Trochę za, ale może wchłonąć opóźnienie, Czerwony - Opóźniony.
- Uwzględnij kilka prostych wskaźników, takich jak% pozytywnych przypadków testowych do tej pory, gęstość defektów,% poważnych defektów; robiąc to, nie tylko podajesz liczby, ale w rzeczywistości dajesz wgląd w jakość testowanego produktu.
- Jeśli ważny etap jest zakończony - zaznacz to.
- Jeśli istnieje krytyczny defekt, który zablokuje całość / część przyszłej realizacji - zaznacz to.
- Jeśli korzystasz z prezentacji, pamiętaj o dołączeniu kilku wykresów, aby wywrzeć większy wpływ.
Na przykład, poniższy wykres jest reprezentacją liczba otwartych defektów w podziale na moduły :
Oprócz tego możesz opcjonalnie dołączyć:
- Jakie działania są planowane dalej?
- Czy potrzebujesz wkładu ze strony innych zespołów, a jeśli tak, to co?
Na koniec kilka wskazówek, które pomogą w tym procesie:
- Bądź zwięzły i kompletny
- Upewnij się, że raportowane wyniki są dokładne
- Użyj punktów wypunktowanych, aby raport był bardzo czytelny
- Dokładnie sprawdź, czy uwzględnij właściwą datę, temat, listę i załączniki.
- Jeśli raport jest zbyt duży i zawiera zbyt wiele czynników, aby go zgłosić: umieść go we wspólnej lokalizacji jako plik i wyślij łącze w wiadomości e-mail zamiast samego pliku. (Upewnij się, że odbiorcy mają uprawnienia dostępu do tej lokalizacji i pliku)
- Jeśli jest to spotkanie statusowe - bądź przygotowany na prezentację, przyjdź na czas i co najważniejsze, zachowaj równy ton (nie bądź zbyt dumny z usterek - są to generalnie „zła wiadomość”).
Przykładowy raport o stanie
Raport o stanie testów kontroli jakości:
Postępując zgodnie z tymi wskazówkami, otrzymaliśmy poniższy Raport o stanie.
Dla wygody naszych czytelników zamieściliśmy 3 arkusze przedstawiające różne poziomy informacji, które mogą przekazać.
Arkusz 1 - jest podsumowaniem ogólnego stanu projektu.
Arkusz 2 - zawiera więcej informacji na temat poszczególnych szczegółów statusu przypadku testowego.
Arkusz 3 - to przykładowy raport o błędzie.
Pobierz to Przykładowy szablon raportu o stanie Xls ze wszystkimi trzema arkuszami. (Kliknij link prawym przyciskiem myszy i wybierz „Zapisz link jako…”, aby pobrać)
plsql pytania do wywiadu i odpowiedzi dla doświadczonych
O autorze - To jest artykuł członka zespołu STH Swati Seela. Możesz dowiedzieć się więcej o niej na naszej Strona kursu testowania oprogramowania .
Podziel się z nami swoimi komentarzami i pytaniami poniżej.
rekomendowane lektury
- Jak napisać tygodniowy raport o stanie testów oprogramowania
- Jak zdalnie zaktualizować stan wykonania przypadku testowego TestLink za pomocą Selenium - samouczek nr 3
- Jak napisać efektywny raport podsumowujący test (pobieranie przykładowego raportu)
- Przykładowy raport o błędzie
- Przykładowy szablon raportu z testu akceptacji z przykładami
- Biblioteka standardowych szablonów (STL): krótkie wprowadzenie
- Tworzenie typów generycznych i zestawów testowych - samouczek Selenium # 22
- Przykładowy szablon przypadku testowego z przykładami przypadków testowych (Pobierz)