3 worst defect reporting habits
Дефекти су озбиљан посао, а мале грешке могу бити скупе.
Знате шта треба да урадите када нађете квар. Ви то пријавите; било у а Трацкер за недостатке / Алат за управљање недостацима или у Екцел листу. Основни принципи су исти за обе методе.
Алати за управљање недостацима не гарантују боље извештавање. Добра пракса је та која штеди дан.
Да бисмо ценили добро, морамо препознати шта није.
Шта ћете научити:
- 3 најгоре навике пријављивања недостатака и како их сломити
- # 1) лењост
- # 2) Журба
- # 3) Недостатак креативности
- Препоручено читање
3 најгоре навике пријављивања недостатака и како их сломити
Ево иде:
# 1) лењост
Не одвајајући време за најбоље што можете.
Ово је процес праћења дефеката праћен у већини тимова:
(Белешка- кликните на било коју слику за увећани приказ)
Као што видите, тест олово прегледа недостатке пре него што их пошаље из КА тимова.
Овај преглед укључује потврду:
- Валидност - Да ли је грешка?
- Комплетност - наслов, кораци, подаци, снимак екрана итд.
- Дупликати
- Репродуцибилно или не ... итд.
Из прве руке знам да је немогуће да КА потенцијални клијент буде 100% темељан.
Дакле, став: „Пријавићу проблем онако како желим. КА потенцијални клијент може поново проверити. Он може да одлучи да ли је квар валидан / потпун или не “крај је вашег КА тима и ваша веродостојност.
Да ли сте знали да неки клијенти имају СЛА за број прихватљивих неважећих недостатака? Једном када број пређе, почињу да кажњавају добављаче за сваки пријављени неваљани квар?
Лек: Пазите и будите одговорни за свој резултат. Вратио се квар због недовољне информације или због тога што није грешка? Можда није увек крив развојни тим. Није да они не желе да поседују проблеме у апликацији. То би могло бити право забрљавање КА тима. Не дозволите да се то догоди.
# 2) Журба
Урадимо то сапример.
Испод је снимак екрана ОпенЕМР екран за стварање пацијента. То је систем управљања болницом отвореног кода.
Овај екран омогућава кориснику да унесе датум рођења пацијента путем функције календара. Оно што не ради је да ограничи улазак на избор из календара. Мислим на то, можете одабрати ДОБ као што је рецимо, „31. март 1983.“ из календара. Касније га промените у „31. фебруар 1983.“.
Зашто 31. фебруара? Имплементирати погађање грешке и покушајте са негативним подацима на терену; што је цела поента тестирања, зар не?
Када завршим, кликните на „Направи пацијента“. Будући да је датум неважећи, очекујем да систем прикаже грешку и да не креира пацијента. Али то се не дешава. Ствара пацијента као доле.
Забележите поља Доб и Датум рођења на доњем екрану:
Током тестирања можете покушати неколико пута и одлучити да:
- То је грешка.
- Може се поновити.
- Није дупликат (проверите са својим тимом да бисте потврдили)
- Знате тачан опис проблема
- Такође, знате тачне кораке који то чине.
Сад кад имате сировину, спремни сте за полазак.
Почнете да пријављујете. Додељивање тежине грешке је обавезан корак и ваш тим можда користи нешто слично као следећа табела за референцу:
Озбиљност | Утицај |
---|---|
1 (критично) | • Ова грешка је довољно критична да сруши систем, проузрокује оштећење датотека или потенцијални губитак података • Узрокује абнормални повратак у оперативни систем (пада или се појављује порука о квару система). • Узрокује заустављање апликације и захтева поновно покретање система. |
2 (високо) | • Узрокује недостатак виталне програмске функционалности. |
3 (средња) | • Ова грешка ће погоршати квалитет система. Међутим, постоји интелигентно решење за постизање жељене функционалности - на пример путем другог екрана. • Ова грешка спречава тестирање других делова производа. Међутим, друга подручја се могу независно тестирати. |
4 (ниско) | • Постоји недовољна или нејасна порука о грешци која има минималан утицај на употребу производа. |
5 (козметичка) | • Постоји недовољна или нејасна порука о грешци која нема утицаја на употребу производа. |
Будући да ова неисправност не руши систем, не блокира виталну функционалност или не спречава тестирање других подручја апликације, могли бисмо да прихватимо „Ниско“.
Изгледа отприлике?
ПОГРЕШНО. Према подацима о пацијенту, све имунизације и други подсетници су каснили. Ово може и не мора бити тачно. Такође, за пацијента њихова старост одређује да ли ће видети педијатра или општег лекара итд.
Утиче на дозе лекова и многа друга подручја лечења за која можда и не знамо.
Дакле, идем са „Хигх“. Слажем се да је мало вероватно да ће болничко особље погрешно унети ДОБ пацијента. Али нека то буде фактор који утиче на приоритет када треба решити проблем.
Мој посао испитивача је да осигурам да што боље саопштим озбиљност проблема.
Лек: Не журите са извештавањем. Будите сигурни да 100% разумете утицај проблема из више углова. То је најбоља додата вредност коју тестери могу да пруже. Не кажемо само: „Нешто не иде“. Такође кажемо: „Ево шта ће се догодити ако ово и даље не буде функционисало.“ Тоне разлике, зар не?
# 3) Недостатак креативности
Тестери имају дивну прилику да дају предлоге за побољшање софтвера.
У вашем Алат за управљање недостацима такође, можете послати недостатак типа „Предлог за побољшање“. Овде можете постати креативни.
Лек: Размишљају ван оквира. Ако мислите да одређеној функцији недостаје фактор „вау“ и знате како да је унесете, представите идеју. У најгорем случају, може бити одбијено и то је у реду. Важно је покушати.
Такође, ову супер моћ користите опрезно. Покушајте да не дајете коментаре попут „Мрзим боју банера, молим вас, промените је.“
Ево доброгпримерпредлога за побољшање на који сам наишао: Замените „Пошаљите е-пошту дилеру“ опцијом „Разговарајте са дилером“ на сајту ауто куће. Предвиђа се да ће већи промет претворити у продају.
Волео бих да сам толико креативан! Али, можда сви можемо радити на томе.
Ево вам бонуса. Контролна листа за ослобађање од ових лоших навика:
1. Да ли мој наслов јасно и сажето преноси проблем?
На пример:„Стварање пацијента не ради“ није добар наслов. „Креирање пацијента не успева чак и када сва поља за унос садрже тачне вредности“.
два. Колика је стопа поновљивости?
Другим речима, да ли се то увек догоди? Да ли знам тачан редослед корака који ће поновити проблем?
3 Да ли је овај проблем специфичан за платформу, прегледач или корисника?
Четири. Да ли су кораци завршени и довели сте до вашег проблема?
5 . Да ли имам укључен снимак екрана?
6. Да ли треба да означим свој снимак екрана да бих истакнуо нека одређена подручја?
7. Да ли је назив приложене датотеке слике описан?
Не користите нешто попут „Унтитлед.јпг“. Дајте му описно име.
8. Да ли сам укључио податке о тесту?
На пример:Укључите их за квар у администраторском модулу којем су потребни акредитиви за ауторизацију. Развојни тим може или не мора имати приступ КА окружењу. Не желите одлагање и праћење нечег тако основног.
9. Могу ли да дам неке друге детаље да бих учврстио свој недостатак?
(Пример:референца на ФРД или разговор са клијентом итд.)
10. Да ли разумем колико је тежак проблем из различитих перспектива?
Једанаест. Да ли знам основни узрок проблема? Ако је одговор да, да ли имам доказе (можда датотеке евиденције) и могу ли их укључити? Имајте на уму да ово можда нећете увек знати или требате знати. Али ако то учините, не штети ако га укључите.
12. Да ли у извештају о недостацима нема проблема са граматиком, форматом, правописом и интерпункцијом?
иоутубе у мп3 дуже од 90 минута
13. Да ли знам како да побољшам производ?
Мислите ли да је ово дуготрајно? Па, једном када то постане навика, то више неће бити.
Корење за боље пријављивање квара рутине!
О аутору: Овај чланак написао је члан СТХ тима Свати.
Слободно објавите своје упите / коментаре у наставку.
Препоручено читање
- Зашто је пријављивање грешака уметност коју би требало да научи сваки тестер?
- Шта је животни циклус оштећења / грешака у тестирању софтвера? Водич за животни циклус оштећења
- Узорци извештаја о грешкама за веб и производе
- Шта је техника испитивања заснована на недостацима?
- Процес управљања недостацима: Како ефикасно управљати недостацима
- Поступак троструке неисправности и начини за руковање састанком са оштећеним дефектима
- Како написати добар извештај о грешци? Савети и Трикови
- 3 стратегије за решавање недостатака блокера