Menu

W tym scenariuszu wyjaśniono, jak ważne jest udokumentowanie często występujących błędów

this scenario explains how important it is document frequently encountered errors

Czy uważasz, że błędy oprogramowania występują tylko raz, a po naprawieniu nigdy się nie pojawiają? Czuję, że około 30% błędów powtarza się.

W tym artykule chcę wyjaśnić, jak ważne jest udokumentowanie niektórych często napotykanych błędów.

Poniżej znajdziesz kilka wspólne obszary, w których widoczne są problemy i szablon do ich udokumentowania.

Mam nadzieję, że okaże się to pomocne!

Dokumentowanie często występujących błędów

wizerunek źródło

Scenariusz 1

Kod jest wdrożony i gotowy do kontroli jakości. John, tester jest gotowy ze swoimi przypadkami testowymi. W trakcie testów napotyka problem. Czuje, że zostało to zauważone kilka razy wcześniej, ale John nie wiedział, jak to rozwiązać.

Dokumentowanie błędów 1

Dokumentowanie błędów 2

Zarówno John, jak i Sheryl poszli szukać Smitha, który wcześniej widział ten sam błąd i wcześniej go rozwiązał. Niestety, Smith był tego dnia na urlopie.

Co powinien teraz zrobić John? Czy John powinien spróbować skontaktować się ze Smithem, aby znaleźć rozwiązanie, nawet gdy Smith jest niedostępny?

Dlatego też, jeśli problem środowiskowy pojawia się wielokrotnie w wielu wydaniach, dobrym pomysłem jest udokumentowanie szczegółów i umieść go w udostępnionym miejscu. Pozwoli to wyeliminować zależność od jednej osoby i pomoże wszystkim członkom zespołu samodzielnie znaleźć rozwiązanie, gdy tak się stanie.

Scenariusz 2

John testuje nową wersję i ponownie napotyka znany błąd. Tym razem wie, że w jednym z poprzednich wydań powstał dla niego defekt. Ale pytanie brzmi: „jak znaleźć numer wady i inne powiązane szczegóły?”

W tym przypadku, jak myślisz, co pomogłoby Johnowi?

To są możliwości.

Ale moim zdaniem dobrze udokumentowane takie kwestie w oddzielnym obszarze i udostępnione zespołowi, to dodaje wartości i oszczędza czas.

Czego się nauczysz:

Przykład sortowania bąbelkowego w języku c ++

Niektóre obszary z częstymi błędami:

1) Plik parametrów - Na podstawie moich doświadczeń z narzędziem Informatica w wielu przypadkach zauważyłem, że plik param wskazuje na nieprawidłowe połączenie z bazą danych. Powodowało to wielokrotnie te same problemy. Głównym powodem było to, że połączenie było współdzielone między programistami i kontrolą jakości. Tak więc plik param zawsze musiał być aktualizowany zgodnie z potrzebami, aby uniknąć błędu.

2) URL wskazujący na nieprawidłową bazę danych

3) Problemy z dostępem - Użytkownicy napotykają problemy, gdy mają niewystarczające lub nieprawidłowe uprawnienia dostępu do bazy danych lub w takim przypadku bardzo pomocny byłby dokument przedstawiający kroki, które należy podjąć lub osobę / osoby, z którymi należy się skontaktować.

4) Problem z danymi testowymi - Używanie nieprawidłowego formatu lub wartości danych najczęściej powoduje problemy.

5) Problemy z bazą danych - Jednym z takich typowych problemów jest przekroczenie limitu czasu połączenia DB. Niektóre przestoje są tymczasowe, zaplanowane i czasami możemy potrzebować pomocy DBA. Użytkownicy są powiadamiani z wyprzedzeniem o planowanej konserwacji, ale testerzy zdecydowanie potrzebują w przypadku tymczasowych błędów i rozwiązania

Większość powtarzających się błędów to ogólnie kwestie ochrony środowiska .

Jednak, problemy z kodem nie można zignorować. Powyższa dyskusja jest ogólna i nie obejmuje problemów z kodem, ponieważ problemy z kodem są bardziej specyficzne dla twojej aplikacji, frameworka, języka programowania itp.

Może to być również niewielki obszar defektów wprowadzenie danych lub błąd w użyciu przez człowieka s .

ŚciągnijSzablony do śledzenia często występujących błędów

Format słowa

=> Pobierz szablon śledzenia błędów (świat)

Format programu Excel

=> Pobierz szablon śledzenia błędów (Excel)

Korzyści z dokumentowania często napotykanych błędów

1) Eliminuje zależność - W scenariuszu 1 John był zależny od Smitha w kwestii rozwiązania. Gdyby istniał dokument, na który mógł zwrócić się John, nie miałoby to miejsca.

2) Szybsza realizacja - Weź scenariusz 2. Tester nie musiałby przeglądać całej listy już zarejestrowanych defektów, gdyby istniał specjalny dokument dotyczący problemów o wysokiej częstotliwości.

3) Pomaga nowym członkom zespołu być samowystarczalnymi

4) Pomaga w usuwaniu błędów ludzkich

Wniosek

Powiedziałbym, że udokumentowanie częstszych problemów jest zdecydowanie korzystne, ponieważ stanowiłoby to wspaniałe odniesienie i wartość dodaną.

Dokumentowanie w trakcie wykonywania testów może być uciążliwe, ale zgodnie z najlepszą praktyką podczas wykonywania można sporządzać wstępne notatki, które można później podsumować i zaktualizować we wspólnych dokumentach.

rekomendowane lektury

^