Меню

Изкуството на докладването на грешки: Как да предлагаме на пазара и да коригираме грешките си?

art bug reporting

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

Защо има нужда от маркетинг на грешка?

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

Сега - Каква е разликата между намиране на повечето грешки и отстраняване на повечето грешки ?

Не е ли очевидно, че всяка грешка е влязла в a система за управление на грешки трябва да се поправи от разработчика? Отговорът е не. Фактори като време за пускане на пазара на продукта, време за изпълнение на проекта по график и разработчици, работещи в непрактични строги графици и др. принуждават компаниите да пуснат продукта с малко грешки, които няма да засегнат до голяма степен потребителите.

Изкуство за докладване на грешки

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

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

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

Мислете за това като за реклама или маркетинг на проблема - това включва 2 стъпки:

  1. Пишете или докладвайте грешки правилно
  2. Знаете всичко за грешката, така че всички допълнителни подробности могат да бъдат обяснени по-добре

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

Изкуството на докладване на грешки

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

Обикновено грешката трябва да съдържа следната информация:

  • Резюме на грешки
  • Стъпки за възпроизвеждане
  • Прикачени файлове (снимка, регистрационни файлове и т.н.,)
  • Възпроизводимост на бъгове
  • Тежест на бъговете
  • Версия на софтуера, Информация за околната среда
  • Друга информация, основана на организационни изисквания.

Важна забележка: Винаги ровете по-дълбоко, за да откриете основната причина за проблема и да го докладвате. Например прост неуспех при влизане с правилната комбинация от потребителско име и парола може да бъде свързан с различни причини като:

  1. Идентификационните данни за вход изобщо не са потвърдени
  2. Проблеми с мрежовото изчакване в случай на отдалечени влизания
  3. Системата може да разглежда всички CAPS като не CAPS.

Така че като тестер трябва да можете да дешифрирате разликите, докато следвате резюметата на грешките:

  • „Не мога да вляза с правилното потребителско име и парола“
  • „Не мога да вляза с правилното потребителско име и парола, когато потребителското име или паролата съдържа комбинация от CAPS и не CAPS азбуки.“

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

Сега, нека да разгледаме всяко поле, включено в доклад за грешка, и да обсъдим важните аспекти на всяко от тях:

# 1. Резюме на грешки

Резюмето на грешки трябва да предостави бърза снимка какъв точно е проблемът. То трябва да бъде точно и добре насочено.

Пример :

Освен на теория, ще се опитам да обясня с примери.

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

как да играя .mkv файлове на Windows

' Новият потребител не може да влезе ”

„Потребителският вход не работи според очакванията“

„Потребителят не може да влезе с правилна парола“

резюме на грешки грешно и правилно

От горните проби, можете ли да изберете едно твърдение, което всъщност описва проблема? Не мисля така. Обобщението винаги трябва да дава пълна информация за неуспешния сценарий.

Обмислете следното твърдение:

„Новият потребител не може да влезе с паролата по подразбиране, предоставена по имейл или SMS“

Както можете да видите, от горното изявление разработчикът може ясно да разбере какъв е проблемът и къде е проблемът.

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

# 2. Стъпки за възпроизвеждане и прикачени файлове

Невъзпроизводимите грешки винаги отстъпват, въпреки че може да са значителни. Затова внимавайте да напишете стъпките правилно и описателно.

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

Пример :

Помислете за същия въпрос, посочен в предишния раздел.

  1. Създайте нов потребител, като използвате опцията Регистрация в началната страница. (Примерно потребителско име: HelloUser)
  2. Ще бъдат получени имейл и SMS с парола по подразбиране. Идентификационният номер на електронната поща и мобилният номер за SMS се предоставят при създаването на потребителя в стъпка 1. (Примерен имейл: HelloUser@hello.com , Примерен мобилен номер: 444-222-1123)
  3. Изберете опция Вход в началната страница.
  4. В текстовото поле за потребителско име въведете примерното потребителско име, предоставено в стъпка 1.
  5. В полето за парола въведете паролата по подразбиране, получена чрез имейл или SMS.
  6. Кликнете върху бутона Вход
  7. Очакван резултат: Потребителят трябва да може да влезе с предоставеното потребителско име и парола и да отиде до страницата на потребителския акаунт.
  8. Действителен резултат: Показва се съобщението „Невалидно потребителско име / парола“.

стъпки за докладване на дефекти

Ако някоя от информацията не е предоставена в горната извадка, тогава ще бъде водят до пропуски в комуникацията и разработчикът няма да може да възпроизведе проблема. Стъпките трябва да бъдат конкретни и подробни с примерните данни, които използвате по време на тестването.

Ако е възможно или където е приложимо, предоставете a моментална снимка на това, което точно виждате на екрана. По този начин той ще осигури не само добър изглед на проблема на разработчиците, но и доказателство за резултата от теста ви.

The нефункционален тестови случаи като тестове за стрес, стабилност или производителност в допълнение към горните подробности, информация за сценария, който причинява стреса на системата, може да бъде докладвана такава, каквато е. Освен това има малко системи, които отчитат регистрационни файлове за всяка извършена операция. Дневниците обикновено са отпечатъци, предоставени от разработчиците в техния код. Всеки път, когато модулът се изпълни, съответните дневници ще бъдат отпечатани или показани. Когато са налични регистрационни файлове, това би помогнало на разработчиците до голяма степен да възпроизведат проблема.

# 3. Възпроизводимост на грешки

Проблемът, който е голям или малък, ще бъде приоритизиран въз основа на възпроизводимостта. Може да се види винаги, понякога, рядко или дори само веднъж. Проблемът, който се възпроизвежда като „винаги“, ще бъде приоритизиран по-високо от останалите.

не може да възпроизведе дефект

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

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

# 4. Тежест на бъговете

Сериозността е несъмнено един от най-влиятелните фактори за определяне на приоритетите на Bug.

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

  1. Тежест 1 - Показване на ограничител - за грешки, които са катастрофални, без да бъдат отстранени, потребителят няма да може да продължи да използва софтуера и няма възможно решение
  2. Severity 2 - High - за грешки, подобни на Severity 1, но има решение
  3. Тежест 3 - средна
  4. Тежест 4 - Ниска
  5. Тежест 5 - Тривиална.

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

В нашите декодери малко доставчици на услуги предоставят информация за честотата на услугата, както е настроена в момента. Да приемем, че честотата се показва като 100 MHz вместо 100,20 MHz. Това може да не повлияе на гледането от потребителя на услугите, но може да повлияе по отношение на мониторинга на диагностиката на настройките. Следователно това може да бъде представено като проблем със сериозността 3.

Ако приемем подобен проблем в банковия домейн: Ако салдото в сметката ви се показва като $ 100, вместо $ 100.20, представете си въздействието на проблема. Това трябва да е дефект на тежестта -1. Както можете да видите и в двата случая проблемът е много подобен, че потребителският интерфейс не показва цифрите след десетичната запетая. Но въздействието варира в зависимост от съответния домейн.

Ефективно участие в срещи за контрол на версията на софтуера

Обикновено всяка организация има свой собствен процес за разследване и определяне на приоритетите на грешките. Обикновено по време на проекта ще се проведе среща на определени интервали, за да се обсъдят грешките и да се даде приоритет на същите.

Процесът по време на такива срещи е следният:

  1. Заявете списъка с грешки от системата за управление на грешки според тежестта.
  2. Погледнете резюмето и обсъдете въздействието на грешката върху опита на потребителя върху използването на софтуерен продукт.
  3. Въз основа на оценката на риска и въздействието задайте приоритет и възложете грешката на подходящ разработчик за поправяне на същия.

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

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

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

Ефект от неправилното пускане на пазара на грешка

Ако грешка не се продава правилно, тя ще създаде проблеми като:

  • Неправилен приоритет на дефекта
  • Забавяне при решаването на важните проблеми
  • Пускане на продукт с тежки дефекти
  • Отрицателни отзиви на клиентите
  • Обезценяване на стойността на марката

Ефект от неправилното пускане на пазара на грешка

Освен всички причини, споменати по-горе, много е важно да изградите своя репутация на инженер по тестове . Това е по-скоро като развиване на стойност на марката за себе си.

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

За да развиете такава стойност на марката и да спечелите доверието на вашия екип и екипите за разработка / или управление, трябва да развиете някои технически умения по отношение на тестване на знания, домейн и комуникационни умения.

Заключение

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

Като каза това, свръхрекламирането на продукт също може да причини вреда на репутацията.

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

Сега не е късно! Нека да продължим и да отстраним грешките веднага!

как да отворите bin файлове на Windows 10

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

^