raportowanie statusu testowania oprogramowania
” umowa, że pewna Informacja, w określonym formacie, będzie wysyłana przez określony zespół/osobę, w określonych odstępach czasu, do niektórych członków-jest jak uścisk dłoni-potwierdzeniem, że bez względu na wynik zadania pod ręką, wcześniej niż później będziesz o tym informowany.”
to pierwsza część przysięgi Informatyka. Żartuję! Nie ma przysięgi, ale gdyby była, to z pewnością byłoby na szczycie listy pozycji w nim. Prawda?
odpowiedzialność i przejrzystość (A & T) są niezbędne dla każdego projektu IT na różnych poziomach-na poziomie projektu, na poziomie zespołu, na poziomie zadań, a także na poziomie indywidualnym. Jak upewnić się, że te atrybuty są spełnione? Odpowiedź brzmi-komunikowanie się, bardziej formalnie-raportowanie statusu!
na poziomie indywidualnym, czy nie wszyscy wysyłają raporty, głównie EOD każdego dnia, aby poinformować o spełnieniu (lub niewykonaniu) Twoich codziennych obowiązków. To dowodzi, że faktycznie” jesteś ” świadomy, od czego miałeś zacząć swoje obowiązki.
raport o stanie dziennym
informacje, które muszą być częścią „raportu o stanie dziennym” danej osoby, to:
- co dziś robiłeś?
- co planujesz zrobić jutro?
- czy w ciągu dnia miałeś jakieś problemy? Jeśli tak, jak je rozwiązałeś, czy nadal są otwarte?
- czy potrzebne są jakieś wejścia na jutro? Jeśli tak, to od kogo i czym są?
odbiorcą tego e-maila / raportu jest zazwyczaj menedżer, również członkowie zespołu mogą być CC’ed w niektórych przypadkach-zależy to od protokołu komunikacyjnego, którego przestrzega zespół.
raporty z testów
teraz nadszedł czas, aby uzyskać szczegółowe informacje i dowiedzieć się wszystkiego o raportach wysyłanych przez zespoły testujące/QA.
zespoły testujące wysyłają różne raporty w różnych fazach w STLC.
- Status planu testowego
- Status dokumentacji testowej
- Status wykonania testu (stan błędu)
Plan testowy: wystarczy komunikować się z resztą zespołów projektowych, gdy plan testowy jest tworzony lub gdy wprowadza się w nim znaczącą zmianę.
dokumentacja testu: poinformuj wszystkie zespoły o rozpoczęciu projektowania testów, gromadzeniu danych i innych działaniach, a także o ich zakończeniu. Ten raport nie tylko poinformuje ich o postępach w realizacji zadania, ale także zasygnalizuje zespołom, które muszą przejrzeć i podpisać artefakty, że są następne.
wykonanie testu: wykonanie jest fazą projektu, w której zespół testowy jest głównym celem – pozytywnie i negatywnie – jesteśmy zarówno bohaterami, jak i złoczyńcami.
typowy dzień w cyklu testowym nie jest wykonywany, chyba że wysyłany jest Raport o stanie dobowym. W niektórych zespołach mogą uzgodnić cotygodniowy raport, ale wysyłanie go codziennie jest normą.
nierzadko zdarza się również, że każdego dnia (lub tygodnia) odbywa się spotkanie statusowe w celu przedstawienia statusu zespołu ds. kontroli jakości zainteresowanym stronom.
stąd tryb raportu o stanie może być:
- e-mail / dokument
- Spotkanie / prezentacja
- zarówno-codzienny e-mail, jak i cotygodniowe spotkanie lub tak.
raport o stanie wykonania testu
dzienny/tygodniowy raport wykonania testu:
co to jest? Ogólnie rzecz biorąc, jest to komunikat wysłany w celu zapewnienia przejrzystości działań zespołu ds. kontroli jakości w danym dniu podczas cyklu testowego-zawiera zarówno informacje o usterkach, jak i informacje o przebiegu testu.
do kogo powinien trafić? – Zwykle odbiorcami/uczestnikami spotkania są zespół programistów, zespół wsparcia środowiska, analityk biznesowy i zespół projektowy. Plan testowy jest najlepszym miejscem, aby znaleźć te informacje.
co zawiera raport o stanie wykonania testu? – 10 punktów
- liczba przypadków testowych zaplanowanych na ten dzień
- liczba przypadków testowych wykonanych – tego dnia
- liczba przypadków testowych wykonanych ogólnie
- Liczba usterek napotkanych tego dnia/i ich Stany
- liczba dotychczas napotkanych usterek/i ich Stany
- liczba wad krytycznych – nadal otwarte
- czas przestoju środowiska – jeśli występuje
- showstoppers – jeśli występuje
- Załącznik arkusza wykonania testu / link do narzędzia do zarządzania testami, w którym znajdują się przypadki testowe
- załącznik do raportu o błędzie/link do Narzędzia Defect /Test / Management używanego do zarządzania incydentami
powyższe 10 punktów, jeśli zauważysz uważnie, to surowe dane. Raportowanie faktów to jedno, a raportowanie „mądrych” faktów to co innego. Jak udoskonalić te informacje?
- pokazuje ogólny stan za pomocą wskaźnika koloru. Na przykład zielony – na czas, pomarańczowy-nieco z tyłu, ale może wchłonąć opóźnienie, Czerwony-opóźniony.
- zawiera kilka prostych metryk, takich jak zaliczenie % przypadków testowych do tej pory, gęstość defektów, % poważnych defektów; robiąc to nie tylko dając numery, jesteś rzeczywiście zapewniając wgląd w jakość produktu, który testujesz.
- jeśli znacząca faza jest zakończona – zaznacz to.
- jeśli istnieje krytyczna wada, która zablokuje całą/część przyszłego wykonania – zaznacz to.
- jeśli korzystasz z prezentacji, upewnij się, że dodałeś kilka wykresów, aby uzyskać lepszy efekt.
na przykład poniższy wykres jest reprezentacją liczby otwartych defektów, w zależności od modułu:
oprócz nich można również opcjonalnie dołączyć:
- jakie działania są planowane w przyszłości?
- czy potrzebne są jakieś wejścia od innych drużyn, a jeśli tak, to co?
na koniec kilka wskazówek, które pomogą w procesie:
- bądź zwięzły, a jednocześnie kompletny
- upewnij się, że raportowane wyniki są dokładne
- użyj punktowanych punktów, aby raport był bardzo czytelny
- Sprawdź dwukrotnie, aby podać właściwą datę, temat, listę i załączniki.
- jeśli raport jest zbyt duży i ma zbyt wiele czynników do zgłoszenia: umieść go we wspólnej lokalizacji jako plik i wyślij link 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 – przygotuj się na prezentację, przyjedź na czas i co najważniejsze zachowaj równomierny ton (nie bądź zbyt dumny z wad – są one ogólnie „złą wiadomością”).
przykładowy Raport o stanie
raport o stanie testów QA:
zgodnie z tymi wytycznymi otrzymaliśmy poniższy raport o stanie.
dla wygody naszych czytelników zamieściliśmy 3 arkusze zawierające różne poziomy informacji, które mogą przekazać.
Arkusz 1-jest podsumowaniem ogólnego stanu projektu.
arkusz 2-jest bardziej o indywidualnym szczególe statusu przypadku testowego.
Arkusz 3-jest przykładowym raportem o błędzie.
Pobierz ten przykładowy Raport o stanie szablonu Xls ze wszystkimi trzema arkuszami. (Kliknij prawym przyciskiem myszy na link i wybierz ’ Zapisz link jako..’do pobrania)
o autorze – jest to artykuł autorstwa członka zespołu sth Swati Seela. Możesz dowiedzieć się więcej o niej na naszej stronie kursu testowania oprogramowania.
