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!
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ć.
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?
- Poszukaj wady Narzędzie do śledzenia defektów z opisem?
- Przeszukaj całą przeszłość raporty o defektach ?
- Zwrócić się o pomoc do swojego lidera zespołu?
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:
- Pobierz szablony, aby śledzić często występujące błędy
- Korzyści z dokumentowania często napotykanych błędów
- Wniosek
- rekomendowane lektury
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
- 10 najlepszych systemów zarządzania dokumentami dla lepszego przepływu pracy
- Aktualizuj MongoDB i usuń dokument z przykładami
- Dokument zapytania MongoDB przy użyciu metody Find () (przykłady)
- Samouczek dotyczący systemu zarządzania dokumentami SharePoint
- 7 rodzajów błędów oprogramowania, które powinien znać każdy tester
- Jak testować mądrzej: odkrywaj więcej, dokumentuj mniej
- Scenariusz testowy a Przypadek testowy: Jaka jest różnica między nimi?
- Jak napisać dokument dotyczący strategii testów (z przykładowym szablonem strategii testów)