10 reasons why your bugs are getting rejected
Нећу је поштедети. Одбацила је 7 грешака, пријавио сам, у последња три дана. Знам да користи личну незадовољство као професионални мач ……
Саиграч је побеснео и дискусија се изненада запалила када се неколико других саиграча придружило поделивши исто искуство са другим програмерима. Састанак тима окренуо се дискусији о одбацивању грешака. После неке дискусије, сви смо одлучили да у будућности направимо једноставну вежбу да се спасимо понижавања одбачене грешке.
Свако од нас је почео да прави белешке као разлоге за одбијање грешака у последњих 10 грешака, пријављених и одбачених. Списак тих напомена о одбијању показао се корисним за разумевање будућег трага извештавања о грешкама и шта је погрешна претпоставка.
Одбијање грешака и разлози за то
Уместо да откријем списак, желео бих да поделим тачке резултата са списка. Ево га -
# 1) Неразумевање захтева:
Из било ког разлога, ако нисте правилно разумели захтев, дефинитивно бисте пазили на погрешно протумачен захтев у стварној имплементацији, а када га не бисте пронашли, то би по вама била грешка која ће коначно бити одбијена.
Пример из стварног живота : Након тестирања рецепта, открили сте да је безукусан, јер се сол није додавала, али нисте знали да је сол требало да се додаје у време сервирања, у супротном може утицати на изглед рецепта.
# 2) Имплементација захтева:
Као део раније расправе, били сте свесни да ће се специфични захтев применити на КСИЗ начин. Али током развоја, програмер је открио да није могуће следити КСИЗ путању, па је следио АБЦ путању и то вам није саопштено.
На крају ћете пријавити грешку када утврдите да захтев није примењен онако како је расправљено.
Пример из стварног живота : Тражили сте од кројача да припреми кошуљу, а када су вас питали за суђење, одбили сте је рекавши да на њој нисте нашли дугмад. Када кројач објасни да би стављање дугмади на предњој страни утицало на целокупан изглед кошуље и стога је ставио унутар предње границе, ви бисте дефинитивно занемели.
# 3) Нема јасних захтева:
Када не постоје јасни захтеви, свако може слободно да их претпостави на свој начин, што доводи до претпоставке на личном нивоу. Када видите да лична претпоставка није задовољена, означите је као грешку.
Пример из стварног живота : Требате нацртати циклус када је учитељица објавила да је очекивала да ће ученици цртати бицикл. После пола сата, када је проверила цртеж свих, није пронашла никога ко би одговарао њеним очекивањима. Свако је на свој начин узео нејасне изјаве и исход је био трицикл, беба, превише циклуса, бицикл са инвалидским колицима и тако даље.
# 4) Промена захтева:
Још један пример погрешне комуникације, већину времена. Када тестери не буду обавештени о променама захтева, пријавиће се још грешака и на крају ће се одбити.
Пример из стварног живота : Дефинитивно ћете одбити сендвич када откријете да се користи хлеб од меда, а не хлеб од банане који сте наручили. Најмање сте знали да је ваш партнер променио врсту хлеба по наруџби док сте били на телефону и наравно није сматрао потребним да га дели са вама.
# 5) Разумевање опсега:
Током тестирања започињете са тестирањем нечега што се не би требало сматрати тестираним у одређеном тренутку или уопште није обухваћено критеријумима производа; бићете жртва одбацивања грешака.
Пример из стварног живота : Треба да пометнете собу и то је једини фокус. Ипак, ако се жалите на неред у другим областима, сигурно ћете бити игнорисани.
# 6) Тест окружење:
Апликација / производ је комбинација многих хардверских и софтверских захтева - како главних тако и мањих, и када се не користи одговарајуће тестно окружење или нешто недостаје у тестном окружењу, апликација / производ пада и пријављује се критична грешка ...
Следи следеће - дубока истрага, јер већину времена ненамерно не водимо рачуна о томе да пружимо мање детаље о тестном окружењу које смо користили и то повећава рад програмера. На крају се грешка одбија.
Пример из стварног живота : Они укусни кифли које сте кушали код пријатеља пре неколико дана били су сјајни, а пошто сте следили рецепт, муффини нису били ни ближи оном који сте имали.
Па, нисте требали да користите устајали путер, јер свежи путер није био доступан, нисте смели да додате прстохват грама брашна, јер сте мислили да би могло додати укус, нисте требали да га кувате на тави као рерну био ван функције.
Препоручена литература => Како ефикасно припремити „тест окружење“.
# 7) Подаци о тестирању који се користе:
Подаци теста који су коришћени за тестирање нису се подударали са захтевом.
Пример из стварног живота : Чак и након што сте знали да је калкулатор користан за нумеричку обраду ако покушате да додате посебне знакове и када калкулатор неочекивано одговори, мислите да није био у реду. Стварно?
Препоручена литература => Савети за дизајн података о тестирању и Испитајте технике управљања подацима .
# 8) Двострука грешка:
Неко је већ пријавио исту грешку и нисте се постарали да је проверите пре него што је пријавите. Опет одбијање.
Пример из стварног живота: Особа за корисничку подршку неће бити срећна када од сваког члана породице прими више позива за жалбу на исти производ. Није био довољан један позив, помислио би.
најбоље веб локације за преузимање иоутубе видео снимака
# 9) Неправилан опис грешке:
Када програмер не може да разуме шта сте покушавали да пренесете путем извештаја о грешци, очекујте да ће бити одбијено јер су такође оптерећени другим задацима и када у извештају о грешци не пронађу одговарајући опис и потребне детаље, без обзира како критична грешка је, очекује се да буде означена као Одбијена.
Препоручена литература => Како написати добар извештај о грешкама? Савети и Трикови.
Пример из стварног живота: Треба да откључате аутомобил, седите и започните померањем тастера у смеру кретања казаљке на сату ... аутомобил се није упалио, па сте узнемирени. Зар вам није наложено да проверите да ли има бензина? Ох, грешка у упутству јер се претпостављало да ћете сигурно разумети да би требало да буде подразумевано проверено.
# 10) Непродуктивне грешке:
Док сте пријављивали грешку, никада нисте схватили важност поновљивости грешке. Само осигурање да ли се грешка може репродуковати увек или се појављује случајно може уштедети сате рада и још једну одбијену грешку.
Пример из стварног живота: Шта би лекар проверио када се жалите на грубу прехладу, али он не налази никакве симптоме. Ох, само сам јако кихнуо , неће побољшати ситуацију.
Закључак
Већина времена, наша људска природа нам омогућава негативно размишљање када се пријави грешка која се одбаци. Искрено, програмери не виде одређени разлог за одбацивање грешке ако је тачна.
Дакле, следећи пут надаље, немојте се фокусирати на број грешака. Усредсредите се на квалитативне грешке са одговарајућим детаљима, јер је на крају важно како сте помогли у побољшању квалитета производа, а не колико грешака сте пријавили.
Такође прочитајте => Како решити све грешке без ознаке „Неважећа грешка“?
О аутору: Овај користан чланак написао је члан СТХ тима Бхумика Мехта. Она је вођа пројекта која има 7 и више година искуства у тестирању софтвера.
Срећно тестирање! Као и обично, чекамо ваше ставове о истом.
Препоручено читање
- Како решити све грешке без ознаке „Неважећа грешка“?
- Зашто је пријављивање грешака уметност коју би требало да научи сваки тестер?
- Уметност пријављивања грешака: Како пласирати на тржиште и поправити грешке?
- Зашто софтвер има грешке?
- 7 врста софтверских грешака које би сваки тестер требао знати
- 11 начина на које знате да сте испитивач ..
- Узорак извештаја о грешкама
- 5 начина да будете храбар и самопоуздан испитивач софтвера