Меню

Този сценарий обяснява колко е важно да се документират често срещаните грешки

this scenario explains how important it is document frequently encountered errors

Опитайте Нашия Инструмент За Премахване На Проблемите

Вярвате ли, че софтуерните грешки се появяват само веднъж и че при поправянето им никога не се появяват отново? Чувствам, че около 30% от грешките се появяват отново.

В тази статия искам да разбера колко е важно да се документират някои от често срещаните грешки.

По-долу ще намерите някои общи области, където се виждат проблеми и шаблон за документирането им.

Надявам се, че ще ви е от полза!

Документиране на често срещаните грешки

изображение източник

Сценарий # 1

Кодът е внедрен и готов за QA. Джон, тестерът е готов с тестовите си случаи. Отчасти чрез тестване, той попада на проблем. Той чувства, че е забелязан няколко пъти по-рано, но Джон не е знаел как да го реши.

Грешки при документиране 1

Грешки при документиране 2

И Джон, и Шерил отидоха да търсят Смит, който е виждал същата грешка по-рано и я е разрешил преди. За съжаление Смит беше в отпуск този ден.

Какво трябва да направи Джон сега? Трябва ли Джон да се опита да се свърже със Смит, за да намери решение, дори когато Смит е недостъпен?

Следователно, ако проблемът с околната среда се вижда многократно в няколко издания, добра идея е да документирате подробностите и го поставете на споделено място. Това ще премахне зависимостта от някой човек и ще помогне на всички членове на екипа сами да намерят решение, когато това се случи.

Сценарий # 2

Джон тества нова версия и отново попада на известна грешка. Този път той знае, че за него е създаден дефект в едно от последните издания. Но въпросът е: „Как да намеря номера на дефекта и други свързани данни?“

И в този случай какво мислите, че би помогнало на Джон?

Това са възможности.

Но според мен, ако подобни проблеми са добре документирани в отделна област и споделени с екипа, това добавя стойност и спестява време.

Какво ще научите:

Някои от областите с чести грешки:

1) Файл с параметри - Въз основа на моя опит с инструмента Informatica, в много случаи съм забелязал файла param, сочещ към неправилна DB връзка. Това е довело до едни и същи проблеми няколко пъти. Основната причина беше, че връзката беше споделена между dev и QA. Така че файлът param винаги трябваше да се актуализира според нуждите, за да се избегне грешката.

2) URL, сочещ към неправилна DB

3) Проблеми с достъпа - Потребителите се сблъскват с проблеми, когато имат недостатъчни или неправилни разрешения за достъп до DB или В този случай документ, описващ стъпките, които трябва да се предприемат, или лице / лица, с които трябва да се свърже, би било от голяма полза.

4) Издаване на тестови данни - Използването на неправилен формат или стойности на данни по-често води до проблеми.

5) DB проблеми - Времето за изчакване на DB връзката е един такъв често срещан проблем. Част от престоя е временен, планиран и понякога може да се нуждаем от съдействие на DBA. Потребителите се уведомяват предварително за планирана поддръжка, но за временни грешки и разрешаване тестерите определено се нуждаят

Повечето повтарящи се грешки обикновено са проблемите на околната среда .

Въпреки това, проблеми с кода не може да се игнорира. Горната дискусия е обща и не включва проблеми с кода, тъй като проблемите с кода са по-специфични за вашето приложение, рамка, език за програмиране и т.н.

как да премахна елемента от масива в java с пример

Може да има и малка площ от дефекти въвеждане на данни или грешка при използване на хора с .

ИзтеглиШаблони за проследяване на често срещани грешки

Формат на думата

=> Изтеглете шаблон за проследяване на грешки (Свят)

Формат на Excel

=> Изтеглете шаблон за проследяване на грешки (Excel)

Предимства на документирането на често срещани грешки

1) Елиминира зависимостта - В сценарий 1 Джон беше зависим от Смит за резолюция. Ако имаше документ за справка на Джон, това не би било така.

2) По-бърз обрат - Вземете сценарий 2. Изпитателят не би трябвало да прегледа целия списък с вече регистрирани дефекти, ако има специален документ за високочестотни проблеми.

3) Помага на новите членове на екипа да бъдат самодостатъчни

4) Съдейства за разрешаване на човешки грешки

Заключение

Бих казал, че определено е полезно да се документират по-честите проблеми, тъй като това би направило чудесна справка и добавена стойност.

Документирането може да стане досадно, докато е в ход изпълнението на теста, но като най-добра практика могат да се правят груби бележки по време на изпълнението, които по-късно могат да бъдат обобщени и актуализирани в споделени документи.

Препоръчително четене

^