3 worst defect reporting habits
Дефектите са сериозен бизнес и малките грешки могат да бъдат скъпи.
Знаете какво да правите, когато откриете дефект. Вие го докладвате; или в a Проследяване на дефекти / Инструмент за управление на дефекти или в лист на Excel. Основните принципи са еднакви и за двата метода.
Инструментите за управление на дефекти не гарантират по-добро отчитане. Добрите практики спасяват деня.
За да оценим доброто, трябва да разпознаем какво не.
Какво ще научите:
- 3 най-лоши навици за докладване на дефекти и как да ги преодолеем
- # 1) Мързел
- # 2) Бързане
- # 3) Липса на креативност
- Препоръчително четене
3 най-лоши навици за докладване на дефекти и как да ги преодолеем
Ето какво става:
# 1) Мързел
Не отделяте време да направите най-доброто, което можете.
Това е процес на проследяване на дефекти следвани в повечето отбори:
(Забележка- щракнете върху произволно изображение за увеличен изглед)
Както можете да видите, Test Lead прегледа дефектите, преди да ги изпрати от екипите за QA.
Този преглед включва потвърждение:
- Валидност - грешка ли е?
- Пълнота - заглавие, стъпки, данни, екранна снимка и т.н.
- Дубликати
- Възпроизвежда се или не ... и т.н.
От първа ръка знам, че е невъзможно QA възможността да бъде 100% задълбочена.
И така, нагласата: „Ще докладвам за проблема по начина, по който искам. QA оловото може да провери отново. Той може да реши дали дефектът е валиден / пълен или не “е краят на вашия екип за QA и вашето доверие.
Знаете ли, че някои клиенти имат SLA за броя на допустимите невалидни дефекти? След като броят им надхвърли, започват да наказват изпълнителите за всеки докладван невалиден дефект?
Лекарство: Направете дължимата грижа и бъдете отговорни за резултата си. Върна се дефект поради недостатъчна информация или че не е грешка? Не винаги е виновен екипът на разработчиците. Не че не искат да притежават проблемите в приложението. Това може да е истинско объркване на екипа за QA. Не позволявайте да се случи.
# 2) Бързане
Нека направим това спример.
По-долу е снимка на екрана OpenEMR екран за създаване на пациент. Това е система за управление на болници с отворен код.
Този екран позволява на потребителя да въведе датата на раждане на пациента чрез функция на календара. Това, което не прави, е да ограничи влизането до избор от календара. Това, което искам да кажа, е, че можете да изберете DOB, както кажете, „31 март 1983 г.“ от календара. По-късно го променете на „31 февруари 1983“.
Защо 31 февруари? За изпълнение познаване на грешка и опитайте отрицателни данни в полето; което е целият смисъл на тестването, нали?
След като приключа, щраквам върху „Създаване на пациент“. Тъй като датата е невалидна, очаквам системата да покаже грешка и да не създава пациента. Но това не се случва. Той създава пациента, както е показано по-долу.
Обърнете внимание на полетата Възраст и Дата на раждане на екрана по-долу:
Когато тествате, можете да опитате това няколко пъти и да решите, че:
- Това е грешка.
- Той е възпроизводим.
- Това не е дубликат (проверете с екипа си, за да потвърдите)
- Знаете точното описание на проблема
- Освен това знаете точните стъпки, които го правят.
Сега, когато разполагате със суровината, можете да тръгнете.
Започвате да го докладвате. Присвояването на тежестта на дефекта е задължителна стъпка и вашият екип може да използва нещо подобно на следната таблица за справка:
Тежест | Въздействие |
---|---|
1 (критично) | • Тази грешка е достатъчно критична, за да срине системата, да причини повреда на файла или да причини потенциална загуба на данни • Това води до необичайно връщане към операционната система (срив или се появява съобщение за повреда на системата). • Това кара приложението да виси и изисква повторно стартиране на системата. |
2 (високо) | • Това води до липса на жизненоважна функционалност на програмата с решение. |
3 (средно) | • Тази грешка ще влоши качеството на системата. Има обаче интелигентно решение за постигане на желаната функционалност - например чрез друг екран. • Тази грешка предотвратява тестването на други области на продукта. Други области обаче могат да бъдат тествани независимо. |
4 (ниско) | • Съществува недостатъчно или неясно съобщение за грешка, което има минимално въздействие върху употребата на продукта. |
5 (козметични) | • Съществува недостатъчно или неясно съобщение за грешка, което не оказва влияние върху употребата на продукта. |
Тъй като този дефект не води до срив на системата или блокиране на жизненоважна функционалност или предотвратяване на тестването на другите области на приложението, може да приемем „Low“.
Изглежда нали?
ГРЕШНО. От данните на пациента всички имунизации и други напомняния са просрочени. Това може и да не е правилно. Също така, за пациент възрастта им определя дали ще посещава педиатър или общ лекар и т.н.
Това засяга дозировките на лекарствата и много други области на лечение, за които може би дори не знаем.
И така, ще отида с „High“. Съгласен съм, че е малко вероятно болничният персонал да въведе грешно DOB на пациент. Но нека това да е фактор, който влияе върху приоритета кога да се реши проблемът.
Моята работа като тестер е да се уверя, че възможно най-добре съобщавам сериозността на проблема.
Лекарство: Не бързайте да докладвате. Бъдете 100% сигурни, че разбирате въздействието на проблемите от много ъгли. Това е най-добрата добавена стойност, която тестерите можем да предоставим. Ние не просто казваме: „Нещо не работи“. Също така казваме: „Ето какво ще се случи, ако това продължи да не работи.“ Тонове разлика, нали?
# 3) Липса на креативност
Тестерите имат прекрасна възможност да правят предложения за подобряване на софтуера.
Във вашия Инструмент за управление на дефекти също можете да изпратите дефект от типа „Предложение за подобрение“. Тук можете да проявите креативност.
Лекарство: Мислете нестандартно. Ако смятате, че в дадена функция липсва фактор „Уау“ и знаете как да я включите, представете идеята напред. В най-лошия случай може да бъде отхвърлено и това е добре. Важната част е опитите.
Също така, използвайте тази супер мощност с повишено внимание. Опитайте се да не правите коментари като „Мразя цвета на банера, моля, променете го.“
Ето едно добропримерна предложение за подобрение, на което попаднах: Замяна на „Изпращане на имейл до дилър“ с опция „Чат с дилъра“ в сайта на автокъща. Предвижда се повече трафик да се преобразува в продажби.
Иска ми се да бях толкова креативна! Но може би всички можем да работим за това.
Ето бонус. Контролен списък за освобождаване от тези лоши навици:
1. Предава ли заглавието ми проблема ясно и кратко?
Например:„Създаване на пациент не работи“ не е добро заглавие. „Създаването на пациент не е успешно дори когато всички полета за въвеждане съдържат правилни стойности“ е.
2. Каква е степента на възпроизводимост?
С други думи, винаги ли се случва? Знам ли точната последователност от стъпки, които ще повторят проблема?
3. Това проблем ли е платформа, браузър или потребител?
Четири. Изпълнени ли са стъпките и ще стигнете ли до проблема си?
5 . Имам ли включена екранна снимка?
6. Трябва ли да коментирам екрана си, за да подчертая някои конкретни области?
7. Описателно ли е името на прикачения файл с изображение?
Не използвайте нещо като „Untitled.jpg.“ Дайте му описателно име.
8. Включих ли данните от теста?
Например:За дефект в администраторски модул, който се нуждае от идентификационни данни за оторизация, включете ги. Екипът за разработка може или няма да има достъп до QA средата. Не искате забавяне и последващи действия по нещо толкова основно.
9. Мога ли да дам някакви други подробности, за да затвърдя дефекта си?
(Пример:препратка към FRD или разговор с клиента и т.н.)
10. Разбирам ли колко сериозен е проблемът от различни гледни точки?
единадесет. Знам ли основната причина за проблема? Ако да, имам ли доказателства (може би регистрационни файлове) и мога ли да ги включа? Моля, обърнете внимание, че може би не винаги знаете това или трябва да знаете това. Но ако го направите, не боли да го включите.
12. Докладът за дефект не съдържа ли граматика, формат, правопис и пунктуация?
с какво отваряте jar файлове
13. Знам ли как да подобря продукта?
Мислите ли, че това отнема много време? Е, щом това стане навик, вече няма да е така.
Вкореняване за по-добро докладване на дефекти рутини!
За автора: Тази статия е написана от член на екипа на STH Swati.
Чувствайте се свободни да публикувате вашите запитвания / коментари по-долу.
Препоръчително четене
- Защо докладването на грешки е изкуство, което трябва да се научи от всеки тестер?
- Какво представлява жизнения цикъл на дефекти / грешки при тестване на софтуер? Урок за жизнения цикъл на дефекти
- Примерни отчети за грешки за уеб и продуктови приложения
- Какво е техника за изпитване на базата на дефекти?
- Процес на управление на дефекти: Как да управляваме ефективно дефекта
- Процес на дефектна триация и начини за справяне с дефектната триажна среща
- Как да напиша добър доклад за грешка? Съвети и трикове
- 3 стратегии за справяне с блокиращ дефект