Śledzenie błędów

Jeśli uruchomisz testy, aby sprawdzić swoje wymagania, jesteś zobowiązany do znalezienia błędów.Użyj elementu roboczego błędów do opisu i śledzenie postępu dla każdego błędu, który można znaleźć.

Aby uzyskać więcej informacji na temat tworzenia usterek elementów roboczych, zobacz Uruchamianie ręcznych testów za pomocą systemu Team Web Access.Gdy zostaną znalezione błędy, postępuj zgodnie ze wskazówkami w tym temacie, aby je traktować priorytetowo w celu zapewnienia, że zostaną naprawione i upewnij się, że posiadasz zapis pracy i decyzje, które były podjęte.

Selekcja błędów

Selekcje posiedzenia powinny odbywać się w ustalonych odstępach czasu po uruchomieniu w projekcie prac projektowych i testów.To jak często odbywają się spotkania i jak długo trwają zależy od konkretnej sytuacji.

Zazwyczaj spotkania błędu klasyfikacji są uruchamiane przez menedżera projektu i z udziałem Liderów zespołów i być może analityków biznesowych i zainteresowanych stron, które mogą mówić o zagrożeniach dla określonego projektu.Menedżer projektu może użyć zapytania Aktywnych Błędów dla nowych i ponownie otwartych błędów, aby wygenerować listę błędów do klasyfikacji.

Przed rozpoczęciem klasyfikowania, należy opracować zestaw kryteriów, aby określić, które błędy należy naprawić, w jakim priorytecie.Kryteria określają zazwyczaj ważności błędów, błędów, które są skojarzone z funkcją znaczącej wartość (lub znaczącym kosztem możliwości opóźnienia) lub innymi czynnikami ryzyka projektu.

Kryteria selekcji chorych powinny być przechowywane w folderze dokumenty projektu zespołowego.Z biegiem czasu dokument będzie aktualizowany.Zakłada się, że projekt ma włączoną kontrolę wersji i że szczególne kryteria, które są używane w danym momencie w projekcie mogą być pobierane do celów inspekcji i oceny dowodów.

Na początku projektu najprawdopodobniej zdecydujesz o naprawieniu większości błędów, które klasyfikujesz.Jednak w miarę postępu projektu, zaklasyfikowane kryteria (lub zakaz) mogą zostać podjęte do zmniejszenia liczby błędów naprawionych.

Podnosi poprzeczkę kryteriów selekcji chorych i pozwala zgłaszanym błędom na pozostanie nieokreślonymi jako kompromis.To kompromis, który mówi, że naprawianie błędów jest mniej istotne niż dotrzymanie zakresu projektu, budżetu i harmonogramu.

Umożliwia określenie, które błędy mają zostać naprawione i ustawiania ich stanu, priorytetu, ważności i innych pól kryteriów.Domyślnie szablon zawiera cztery priorytety: od 1 dla „musi naprawić” do 4 „nieistotne”. W przypadku zmiany definicji w szablonie procesu, należy odpowiednio zaktualizować wskazówki, tekst pomocy i wszelkie dokumenty kryteriów.

Napraw błędy

Po przejściu błędu przez klasyfikację i nadaniu mu priorytetu, powinien zostać przypisany do dewelopera w celu dalszego badania.

Błąd elementu pracy ma kartę dla odtworzenia kroków, które dostarczają tego, czego potrzebujesz, aby odtworzyć błąd.Jednakże, możesz także być w stanie korzystać z IntelliTrace, co pomaga odtworzyć trudne błędy.Aby uzyskać więcej informacji na temat IntelliTrace, zobacz Śledzenie jakości oprogramowania.

Jeśli deweloper zdecyduje się na tryb postępowania, powinien zanotować swoje decyzje w elemencie roboczym błędu.

Podejmij decyzję w sprawie poprawki

Pracując z innymi członkami zespołu, deweloper może zalecić poprawkę, która ma wpływ na inne sekcje kodu i która wymaga znaczących regresji badania.Wszelkie rozmowy, które odnoszą do oceny takiego rozwiązania, powinny być rejestrowane w historii elementu roboczego błędu, ponieważ dokumentują przydatną analizę podejmowania decyzji i dowody zarządzania ryzykiem do audytu lub oceny standardowej metody poprawy procesu CMMI (SCAMPI).Aby uzyskać więcej informacji na temat biblioteki CMMI, zobacz Podstawy CMMI.

Aktualizowanie i uruchomianie testów jednostkowych dla naprawianie błędów

Testy jednostkowe sprawdzają poprawność implementacji kodu jednostki.Pisanie i wykonywania testów jednostkowych identyfikuje błędy przed testowaniem i dlatego przyczynia się do zmniejszenia kosztów kontroli jakości.Deweloperzy muszą pisać testy jednostkowe dla całego kodu, które będą zapisywane jako część wykonania zadania rozwoju lub naprawienia błędu wykonania.Aby uzyskać więcej informacji, zobacz Weryfikowanie kodu przy użyciu testów jednostkowych.

Użytkownik może chcieć napisać test jednostki przed dokonywaniem jakichkolwiek poprawek w kodzie w strategii rozwoju pierwszego badania.Ten typ strategii jest wybierany przez deweloperów oprogramowania.CMMI nie wymaga, aby testy były napisane w określonej kolejności,tylko żeby uzyskano efektywną weryfikację funkcjonalności.

Dowód na to, że testy jednostek były napisane i uruchomione jest wymagany do oceny CMMI.Pamiętaj, aby połączyć elementy robocze badania do poprawki kodu i połącz te zadania do elementu roboczego błędu.Zapewnia to możliwość śledzenia dowody, że są to krewetki, których rzeczoznawca będzie szukał.

Przejrzyj i zreorganizuj kod naprawiania błędów

Przegląd kodu jest używany do zapewnienia, że nowy lub zmodyfikowany kod spełnia założony poziom jakości zanim kod zostanie zintegrowany z codzienną kompilacją.Uwagi dotyczące jakości kodują standardy, zgodność z architekturą i projektem, wydajność, czytelności i bezpieczeństwo.Przeglądy kodu mogą także dostarczyć dodatkowy wgląd od innych deweloperów o tym w jaki sposób kod powinien być napisany.Aby uzyskać więcej informacji na sposobu przeglądu i refaktoryzacji kodu, zobacz Implementowanie zadań rozwoju.

Zamknij błędy

Po naprawie błędu, powinien zostać przypisany do testera, aby sprawdzić, czy problem ten został rozwiązany przed zamknięciem elementu roboczego błędu.

Weryfikowanie poprawki

Aby zweryfikować poprawkę, należy próbować odtworzyć błąd, wyszukać dodatkowe nieoczekiwanych zachowanie i, w razie potrzeby ponownie uaktywnić ten błąd.

Podczas weryfikowania rozdzielczości błędów, może się okazać że błąd nie został całkowicie naprawiony lub może być niezgodny z rozdzielczością.W tym przypadku omów problem z osobą, która go rozwiązała, dojdź do porozumienia i ewentualnie ponownie uaktywnij ten błąd.Jeśli ponownie aktywujesz błąd, upewnij się, że zawarto przyczyny reaktywacji błędu w opisie błędu tak, że informacje są zachowane.

Zamykanie elementu roboczego błędu

Błąd jest zamknięty z wielu powodów.W prostym przypadku, błąd zweryfikowano jako stały i może także zostać zamknięty.Jednak błąd może zostać odroczony do następnej wersji produktu; udowodniono, że nie jest odtwarzalny i nie potwierdzono duplikatu.Każdy z tych powodów musi być udokumentowany, a błąd musi zostać poprawnie zamknięty w celu zapewnienia, że nie ma żadnych wątpliwości dotyczących powodów zamknięcia.