Што ўключыць у справаздачу пра памылку?



Як напісаць добры справаздачу пра памылку

Напісанне добрай справаздачы пра дэфекты альбо памылкі значна дапамагае хутка выявіць і вырашыць праблемы. У гэтым паведамленні мы пералічым агульныя элементы, якія звычайна ўключаюцца ў справаздачу пра памылку.

У пэўным парадку:

Ідэнтыфікатар дэфекту, ідэнтыфікатар

Ідэнтыфікатар вельмі важны для таго, каб мець магчымасць спасылацца на дэфект у справаздачах. Калі для рэгістрацыі дэфектаў выкарыстоўваецца інструмент паведамлення пра дэфекты, ідэнтыфікатар звычайна з'яўляецца унікальным нумарам, які генеруецца праграмай і павялічваецца за кожны журнал дэфектаў.


Рэзюмэ

Рэзюмэ - агульнае апісанне дэфекту і назіранай няспраўнасці на высокім узроўні. Гэта кароткае рэзюмэ павінна стаць асноўнай выявай дэфекту, бо менавіта гэта распрацоўшчыкі і рэцэнзенты ўпершыню бачаць у справаздачы пра памылку.

Апісанне

Характар ​​дэфекту павінен быць дакладна напісаны. Калі распрацоўшчык, які разглядае дэфект, не можа зразумець і не можа сачыць за дэталямі дэфекту, то, хутчэй за ўсё, справаздача будзе вернута тэсцеру з просьбай даць дадатковыя тлумачэнні і больш падрабязную інфармацыю, што выклікае затрымкі ў выпраўленні праблемы.


Апісанне павінна дакладна растлумачыць крокі для прайгравання дэфекту, а таксама чаканыя вынікі і вынік этапу выпрабаванні. У справаздачы павінна быць сказана, на якім этапе назіралася няспраўнасць.



Суровасць

Цяжар дэфекту паказвае, наколькі сур'ёзны дэфект з пункту гледжання шкоды для іншых сістэм, прадпрыемстваў, навакольнага асяроддзя і жыцця людзей, у залежнасці ад характару сістэмы заявак. Ступень цяжкасці звычайна класіфікуецца і класіфікуецца на 4 ці 5 узроўняў, у залежнасці ад вызначэння арганізацыі.

  • S1 - крытычны: Гэта азначае, што дэфект уяўляе сабой корак з вялікай патэнцыяльнай шкодай і не мае спосабу абыйсціся, каб пазбегнуць дэфекту. Прыкладам можа служыць прыкладанне, якое наогул не запускаецца і выклікае адключэнне аперацыйнай сістэмы. Гэта патрабуе неадкладнай увагі і дзеянняў і выпраўлення.
  • S2 - сур'ёзна: Гэта азначае, што некаторыя асноўныя функцыянальныя магчымасці прыкладанняў альбо адсутнічаюць, альбо не працуюць, і няма абыходных шляхоў. Напрыклад, прыкладанне для прагляду малюнкаў не можа прачытаць некаторыя распаўсюджаныя фарматы малюнкаў.
  • S3 - Нармальны: Гэта азначае, што некаторыя асноўныя функцыянальныя магчымасці не працуюць, але існуе абыходны шлях, які выкарыстоўваецца ў якасці часовага рашэння.
  • S4 - Касметыка / Палепшэнне: Гэта азначае, што няспраўнасць прычыняе нязручнасці і прыкрасці. Прыкладам можа служыць усплывальнае паведамленне кожныя 15 хвілін, альбо заўсёды трэба двойчы націснуць кнопку GUI, каб выканаць дзеянне.
  • S5 - Прапанова: Звычайна гэта не дэфект і прапанова палепшыць функцыянальнасць. Гэта можа быць графічны інтэрфейс альбо налады прагляду.

Прыярытэт

Пасля вызначэння ступені цяжкасці варта даведацца, як вызначыць прыярытэтнае рашэнне. Прыярытэт вызначае, наколькі хутка трэба выправіць дэфект. Прыярытэт звычайна тычыцца значэння бізнесу, напрыклад, уздзеяння на праект і верагоднага поспеху прадукту на рынку. Як і сур'ёзнасць, прыярытэт таксама класіфікуецца на 4 ці 5 узроўняў.

  • P1 - Тэрмінова: Значыць надзвычай тэрмінова і патрабуе неадкладнага дазволу
  • P2 - высокі: Патрабаванне дазволу для наступнага знешняга выпуску
  • P3 - Сярэдні: Дазвол, неабходны для першага разгортвання (а не для ўсіх разгортванняў)
  • P4 - нізкі: Патрабуецца дазвол для першага разгортвання альбо наступных будучых выпускаў

Больш падрабязна пра цяжар у параўнанні з прыярытэтам


Важна адзначыць, што дэфект, які мае высокую ступень цяжкасці, таксама мае высокі прыярытэт, гэта значыць сур'ёзны дэфект патрабуе высокага прыярытэту, каб вырашыць праблему як мага хутчэй. Ніколі не можа быць дэфектаў высокай ступені цяжкасці і нізкага прыярытэту. Аднак дэфект можа мець нізкую ступень цяжкасці, але мець высокі прыярытэт.

Прыкладам можа служыць назва кампаніі, якая пры запуску прыкладання няправільна пішацца на пачатковым экране. Гэта не наносіць сур'ёзнай шкоды навакольнаму асяроддзю альбо жыццю людзей, але можа нанесці шкоду рэпутацыі кампаніі і нанесці шкоду прыбытку бізнесу.

Дата і час

Таксама важныя дата і час узнікнення альбо паведамлення пра дэфект. Звычайна гэта карысна, калі вы хочаце знайсці дэфекты, якія былі выяўлены для пэўнага выпуску праграмнага забеспячэння альбо з моманту пачатку этапу тэставання.

Версія і зборка выпрабаванага праграмнага забеспячэння

Гэта таксама вельмі важна. У большасці выпадкаў існуе мноства версій праграмнага забеспячэння; кожная версія мае шмат выпраўленняў і больш функцыянальных магчымасцей і ўдасканаленняў папярэдніх версій. Таму вельмі важна адзначыць, у якой версіі праграмнага забеспячэння выяўлены збой, пра які мы паведамляем. Мы заўсёды можам звярнуцца да гэтай версіі праграмнага забеспячэння для прайгравання няспраўнасці.


Паведаміў

Зноў жа, гэта важна, бо калі нам можа спатрэбіцца звярнуцца да чалавека, які ўзнік дэфект, мы павінны ведаць, з кім звязацца.

Звязанае патрабаванне

Па сутнасці, усе функцыі праграмнага прыкладання можна прасачыць у адпаведнасці з адпаведнымі патрабаваннямі. Такім чынам, калі назіраецца збой, мы можам убачыць, на якія патрабаванні гэта паўплывала.

Гэта можа дапамагчы ў скарачэнні дублікатаў справаздач пра дэфекты, таму што калі мы можам вызначыць патрабаванне крыніцы, то, калі іншы дэфект рэгіструецца з тым самым нумарам патрабавання, нам можа не спатрэбіцца паведамляць пра яго зноў, калі дэфекты маюць аналагічны характар.

Укладанні / Доказы

Любыя доказы няспраўнасці павінны быць зафіксаваны і прадстаўлены разам са справаздачай пра дэфект. Гэта візуальнае тлумачэнне апісання дэфекту і дапамагае рэцэнзенту і распрацоўшчыку лепш зразумець дэфект.


Выснова

У гэтым артыкуле мы даведаліся, якую інфармацыю мы звычайна павінны ўключаць у справаздачу пра памылкі. Стварэнне добрага справаздачы пра памылку паскарае аналіз асноўнай прычыны і выпраўленне памылкі.