Menu

3 Strategie radzenia sobie z defektem blokującym

3 strategies dealing with blocker defect

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Wady blokujące dodają dramatyzmu zwykłym dniom testowym.

W tym artykule chcę omówić kilka kroków, które tester może wykonać, mając do czynienia z nimi.

Zakładam, że nasi drodzy czytelnicy już dogłębnie rozumieją wagę i priorytet usterek. Potrzebujesz szybkiego podsumowania? Spójrz na to.

Czy to zawsze oznacza, że ​​musimy całkowicie przerwać testy, jeśli napotkamy problem z blokerem?

W niektórych przypadkach „tak”, ale może nie zawsze. Mogą wystąpić sytuacje, w których możliwe są pewne działania testowe.

Rozpraw się z defektem blokera

wizerunek źródło

Poniżej przedstawiamy kilka sytuacji, których doświadczyłem w swojej karierze jako tester. Jestem głęboko przekonany, że należy postępować zgodnie z krokami opisanymi poniżej (później skonsolidowanymi w schemacie blokowym), aby uprościć ten proces.

Zacznijmy od razu.

Kroki, które powinieneś podjąć, gdy natrafisz na defekt blokera

Krok 1: Kiedy napotkasz problem, poświęć czas na znalezienie przyczyny.

Jestem głęboko przekonany, że nasza praca jako testera się nie kończy zgłaszanie usterek . Jeśli czas na to pozwoli, powinniśmy zbadać, co mogło spowodować problem. Nie zawsze jesteśmy w stanie wskazać dokładny obszar problemu, ale staramy się jak najwięcej go rozwiązać. Te same szczegóły można zaktualizować w przypadku wady jako dodatkowe komentarze.

Robiłem to dużo w moich projektach, co zaowocowało szybką poprawką. Korzyści z analizy przyczyn źródłowych są:

  • Będąc wartością dodaną, może to zdecydowanie zapewnić programistom lepsze wskazówki dotyczące usuwania błędów.
  • Ponadto osoba przeprowadzająca kontrolę jakości może rozpoznać, czy problem został spowodowany samodzielnie (problemy z wprowadzaniem danych lub użytkowaniem przez człowieka), a jeśli tak, może zostać naprawiony przez samego testera. Kiedy takie błędy są zgłaszane programistom bez sprawdzania ich od strony kontroli jakości, to właśnie one uważane za nieistotne i może stworzyć negatywną reputację testera.

Dlatego sugeruję, abyśmy zawsze dokładnie sprawdzali po naszej stronie przed zarejestrowaniem usterki.

Oto kilka przykładów z moich projektów w czasie rzeczywistym, które wzmocnią powyższe punkty:

Pracowałem nad projektem, w którym nasze testy wymagałyby upuszczenia pliku w określonej lokalizacji. Zmień nazwę, aby była zgodna z nazwą w konfiguracji. Zaplanowane zadanie pobierze plik danych i załaduje dane do systemu. Następnie sprawdzilibyśmy dane w bazie danych i interfejsie użytkownika.

ile jest firm zajmujących się bezpieczeństwem cybernetycznym

Kiedyś napotykaliśmy problemy, w których zadanie było uruchamiane, ale dane się nie ładowały, a po zbadaniu sprawy było tak, ponieważ tester nie zmienił nazwy podczas upuszczania pliku w tej lokalizacji.

To było dla nas blokerem, ale nie wymagało uwagi programisty. Musieliśmy zwracać uwagę na szczegóły i unikać takich drobnych błędów.

Oto kilka typowych kategorii, głównych przyczyn i środków zaradczych:

# 1) Plik hostów Kwestia - Powiedzmy, że plik hosts zawiera nieprawidłowe parametry i powoduje problem. W takim przypadku możesz samodzielnie zaktualizować plik hosta lub zwrócić się o pomoc do kogoś, kto ma dostęp do aktualizacji i kontynuowania wykonywania testu.

jak otworzyć plik xml

Należy zgłosić usterkę tego samego, więc programiści zbadają to, ale dzięki obejściu można nadal testować funkcjonalne.

Uwaga: Zanim to zrobisz, skontaktuj się ze swoimi zespołami projektowymi, czy zespół kontroli jakości może wprowadzić te zmiany.

# 2) Konfiguracja - Często odnotowywaliśmy problemy z konfiguracją, takie jak brak wskazania właściwego środowiska lub inne problemy z konfiguracją, które blokują. W takich przypadkach również testerzy mogą wprowadzać zmiany i kontynuować testowanie.

Uwaga: Jeszcze raz poproś o pozwolenie, zanim to zrobisz.

# 3) Problem z kodem - Jeśli uważasz, że przyczyną problemu jest kod, testerzy nie mogą wiele zrobić. Zarejestruj usterkę programu blokującego i poczekaj, aż poprawka rozpocznie testowanie.

# 4) Problem z wdrożeniem - Złe wdrożenie to kolejna częsta przyczyna problemów z blokerami, które można wykryć podczas testu poczytalności. Również w tym przypadku testowanie należy natychmiast przerwać do czasu otrzymania nowej kompilacji.

# 5) Środowisko wyłączone - Jeśli środowisko nie działa, powiedzmy, że baza danych nie łączy się z serwerem lub adres URL nie działa w przypadku witryn internetowych; W takich przypadkach testerzy nie mogą wiele zrobić poza zgłoszeniem usterki i czekaniem, aż system zacznie działać.

Dlatego jeśli istnieje obejście, użyj go, aby kontynuować testowanie. Jedynym sposobem na znalezienie tego obejścia jest zbadanie przyczyny źródłowej. Najczęściej może istnieć alternatywa.

Krok 2: Bardzo łatwo jest wpaść w nieskończoną pętlę podczas badania pierwotnej przyczyny. Dlatego upewnij się, że nie pochłania całego dnia i całego wysiłku.

Oto kilka wskazówek:

  • Znajdź równowagę i rozpoznaj punkt zatrzymania, gdy tam dotrzesz.
  • Doświadczenie i wiedza testera mają kluczowe znaczenie dla pomyślnego RCA. Jednak w razie potrzeby dobrze jest zaangażować zespół i kierownictwo zespołu.
  • Jeśli uważasz, że RCA jest czasochłonne, najpierw natychmiast zgłoś problem i podaj jak najwięcej informacji. Zrzut ekranu jest zawsze pomocny.
  • W razie potrzeby kontynuuj. Wyślij wiadomość e-mail do menedżera lub programisty, aby zwrócić uwagę na krytyczny problem.
  • Kontynuuj rozwiązywanie problemów po zaalarmowaniu odpowiednich stron.

Powód, dla którego defekty blokerów powinny być zgłaszane natychmiast:

  • Kierownictwo powinno być świadome wszystkich przestojów, jeśli okaże się, że problem jest usterką, która zatrzymuje show. Informacje te muszą zostać przekazane klientowi i mogą również wymagać aktualizacji planu projektu (harmonogramy kontroli jakości), zmiany elementów dostarczanych itp.
  • Każde opóźnienie w wynikach kontroli jakości musi być poparte dowodami. Dlatego zawsze lepiej jest porozumieć się jak najszybciej, zamiast czekać do końca dnia.

Krok 3: A teraz, przechodząc do ostatniego kroku, odkąd skończyliśmy analizować problem i informować o nim, co dalej?

  • Jeśli problem blokuje dostęp do jednego obszaru funkcjonalnego, sprawdź, czy ma to wpływ na inne obszary
  • Jeśli aplikacja frontonu nie działa, sprawdź, czy można kontynuować testowanie zaplecza / oprogramowania pośredniego / bazy danych.
  • Jeśli nie można wykonać żadnej czynności testowej, spróbuj pracować nad dokumentacją związane z Twoim projektem.
  • Możesz też spróbować zidentyfikować obszary do automatyzacji jeśli ręcznie powtarzasz dużo pracy. Automatyzacja nie zawsze musi korzystać z narzędzia. Powiedzmy, generowanie raportów to dla Ciebie monotonne zadanie, to jeden obszar, który można zautomatyzować za pomocą prostych makr programu Excel i tym podobnych.
  • Poświęć czas na poznanie narzędzi open source, które można wdrożyć w swoim projekcie
  • Ostatni, ale nie mniej ważny , pracujcie nad innowacjami, mantrą, która obecnie rządzi światem!

Wreszcie , schemat blokowy podsumowujący całą dyskusję!

Schemat blokowy: kroki postępowania w przypadku defektu elementu blokującego

wada blokera

Autor : Ten niesamowity artykuł został napisany przez członka zespołu STH, Priyę R.

Jakie kroki podejmujesz, gdy napotykasz jakąkolwiek wadę blokera?

rekomendowane lektury

^