10 reasons why your bugs are getting rejected
Няма да я щадя. През последните три дни тя отхвърли 7 грешки. Знам, че тя използва личните си обиди като професионален меч ......
Един съотборник се разпали и дискусията изведнъж се запали, когато няколко други съотборници се присъединиха към споделянето на същия опит с други разработчици. Срещата на екипа обърна точка за дискусия относно отхвърлянето на грешки. След дискусия, всички решихме да направим просто упражнение, за да се спасим от унижението на отхвърлената грешка в бъдеще.
Всеки от нас започна да си прави бележки като причини за отхвърляне на грешки за последните 10 грешки, докладвани и отхвърлени. Списъкът с тези бележки за отхвърляне се оказа полезен за разбиране на бъдещата следа от докладване на грешки и какво е неправилното предположение.
Отхвърляне на бъгове и причини за това
Вместо да разкривам списъка, бих искал да споделя резултатите от списъка. Ето го -
инструменти за автоматизиране на тестове за мобилни приложения
# 1) Неразбиране на изискванията:
По някаква причина, ако не сте разбрали правилно изискването, определено ще внимавате за погрешно интерпретираното изискване в действителното изпълнение и когато не го намерите, това ще бъде грешка според вас, която накрая ще бъде отхвърлена.
Пример от реалния живот : След тестването на рецепта установихте, че тя е безвкусна, тъй като не се добавя сол, но не знаете, че трябва да се добавя сол по време на сервиране, в противен случай това може да повлияе на външния вид на рецептата.
# 2) Изпълнение на изискванията:
Като част от по-ранна дискусия, вие бяхте наясно, че конкретно изискване ще бъде приложено по XYZ начин. Но по време на разработката разработчикът установи, че не е възможно да се следва XYZ пътя и затова той следва ABC пътя и това не ви е съобщено.
В крайна сметка ще докладвате за грешка, когато установите, че изискването не е изпълнено по начина, по който беше обсъдено.
Пример от реалния живот : Помолихте шивача да подготви риза и когато ви помолиха за процеса, вие го отхвърлихте, като казахте, че не сте намерили копчета на нея. Когато шивачът обясни, че поставянето на копчета отпред би повлияло на цялостния вид на ризата и следователно той го е сложил вътре в предната граница, вие определено бихте онемели.
# 3) Няма ясни изисквания:
Когато няма налични ясни изисквания, всеки е свободен да поеме изискването по свой собствен начин и това води до предположение на лично ниво. Когато видите, че личното предположение не е изпълнено, вие го отбелязвате като грешка.
Пример от реалния живот : Трябва да нарисувате цикъл, когато учителката обяви, че е очаквала учениците да нарисуват велосипед. След половин час, когато провери рисунката на всички, тя не намери никого, който отговаря на очакванията й. Всеки взе неясното твърдение по свой начин и резултатът беше триколка, бебешки цикъл, твърде много цикли, цикъл с инвалидната количка и така нататък.
# 4) Промяна в изискването:
Друг пример за неправилно общуване, през повечето време. Когато тестерите не бъдат съобщени за промени в изискванията, ще бъдат докладвани повече грешки и в крайна сметка ще бъдат отхвърлени.
Пример от реалния живот : Определено ще отхвърлите сандвича, когато откриете, че той използва меден хляб, а не бананов хляб, който сте поръчали. Поне знаехте, че вашият партньор е променил вида на хляба за поръчка, докато сте били по телефона и разбира се, той / тя не е намерил за необходимо да го сподели с вас.
# 5) Разбиране на обхвата:
Докато тествате, започвате да тествате нещо, което не трябва да се счита за проверимо в определен момент или изобщо не е обхванато от продуктовите критерии; ще станете жертва на отхвърляне на грешки.
Пример от реалния живот : Трябва да пометете стая и това е единственият фокус. И все пак, ако се оплаквате от бъркотията в другите области, определено ще бъдете пренебрегнати.
# 6) Тестова среда:
Приложението / продуктът е комбинация от много хардуерни и софтуерни изисквания - главни и малки и двете, и когато не се използва подходяща тестова среда или нещо липсва в тестовата среда, приложението / продуктът се срива и се съобщава за критична грешка ...
Това, което се случва по-нататък е - задълбочено разследване, тъй като през повечето време неволно не се грижим да предоставим незначителни подробности за тестовата среда, която използвахме и което увеличава работата на разработчика. В крайна сметка грешката се отхвърля.
Пример от реалния живот : Онези вкусни кифли, които сте опитали от къщата на приятел преди няколко дни, бяха страхотни и след спазването на рецептата кифлите не бяха дори по-близо до тази, която имате.
Е, не трябваше да използвате остаряло масло, тъй като прясното масло не се предлагаше, не трябваше да добавяте щипка грамово брашно, тъй като смятате, че може да добави вкуса, не трябваше да го готвите на тигана като фурната не беше в ред.
Препоръчително четене => Как да подготвим ефективно „Тестова среда“.
# 7) Използвани тестови данни:
Данните от теста, използвани за тестване, не съответстваха на изискването.
Пример от реалния живот : Дори след като знаете, че калкулаторът е полезен за цифрова обработка, ако се опитате да добавите специални символи и когато калкулаторът реагира неочаквано, смятате, че е бил неправилен. Наистина ли?
Препоръчително четене => Съвети за проектиране на тестови данни и Тествайте техниките за управление на данните .
# 8) Дублирана грешка:
Някой вече е съобщил за същата грешка и не сте се погрижили да проверите за същата, преди да докладвате за грешката. Отново отхвърляне.
Пример от реалния живот: Лицето за поддръжка на клиенти няма да бъде доволно, когато получи множество обаждания за оплакване за един и същ продукт от всеки член на семейството. Нямаше ли достатъчно обаждане, щеше да си помисли той.
как да използвам float в java -
# 9) Неправилно описание на грешка:
Когато разработчикът не може да разбере какво се опитвате да предадете чрез отчета за грешка, очаквайте той да бъде отхвърлен, тъй като те също са заредени с други задачи и когато не намерят правилното описание и необходимите подробности в отчета за грешки, без значение как критичен е грешката, очаква се да бъде маркирана като Отхвърлена.
Препоръчително четене => Как да напиша добър доклад за грешки? Съвети и трикове.
Пример от реалния живот: Трябва да отключите колата, да седнете и да започнете, като преместите клавишите по посока на часовниковата стрелка .... Колата не е стартирала и затова сте разстроени. Не бяхте ли инструктирани да проверите за бензин? О, грешка в ръководството, тъй като предполагаше, че със сигурност ще разберете, че по подразбиране трябва да бъде проверено.
# 10) Невъзпроизводими грешки:
Докато съобщавате за грешка, никога не сте осъзнали важността на възпроизводимостта на грешката. Само като се уверите дали грешката е възпроизводима винаги или се появява произволно, може да спестите часове работа и още една отхвърлена грешка.
Пример от реалния живот: Какво ще провери лекарят, когато се оплаквате от тежкия студ, но той не открива никакви симптоми. О, просто кихах силно , няма да подобри ситуацията.
Заключение
През повечето време нашата човешка природа ни позволява да мислим негативно, когато докладваната грешка бъде отхвърлена. Наистина разработчиците не виждат конкретна причина да отхвърлят грешката, ако тя е валидна.
Така че, следващия път нататък, моля, не се фокусирайте върху броя на грешките. Съсредоточете се върху качествените грешки с подходящи подробности, защото в крайна сметка е важно как сте помогнали за подобряване на качеството на продукта, а не колко грешки сте докладвали.
Също така прочетете => Как да разрешим всички грешки без етикет „Невалидна грешка“?
За автора: Тази полезна статия е написана от член на екипа на STH Bhumika Mehta. Тя е ръководител на проекта със 7+ години опит в софтуерното тестване.
Приятно тестване! Както обикновено чакаме вашите възгледи за същото.
Препоръчително четене
- Как да разрешите всички грешки без етикет „Невалидна грешка“?
- Защо докладването на грешки е изкуство, което трябва да се научи от всеки тестер?
- Изкуството на докладването на грешки: Как да предлагаме на пазара и да коригираме грешките си?
- Защо софтуерът има грешки?
- 7 вида софтуерни грешки, които всеки тестер трябва да знае
- 11 начина, по които знаете, че сте изпитател ..
- Примерен доклад за грешка
- 5 начина да бъдете смел и уверен софтуерен тестер