Мени

Уметност пријављивања грешака: Како пласирати на тржиште и поправити грешке?

art bug reporting

Испробајте Наш Инструмент За Елиминисање Проблема

Зашто постоји потреба за маркетингом грешке?

Прве ствари које ми падну на памет кад почнем да пишем овај чланак су речи од Цем Канер - „Најбољи тестер није онај који пронађе највише грешака или који осрамоти већину програмера. Најбољи испитивач је онај који исправи највише грешака. “

Сад - у чему је разлика проналажење већине грешака и поправљање већине грешака ?

Није ли очигледно да је било која грешка пријављена у систем за управљање грешкама треба да поправи програмер? Одговор је не. Чимбеници попут времена за пласирање производа на тржиште, времена за завршетак пројекта по распореду и програмера који раде у њему непрактични уски распореди итд. приморава компаније да пусте производ са неколико грешака које неће у великој мери утицати на кориснике.

Уметност пријављивања грешака

(слика извор )

Ко даје поверење менаџменту наводећи да грешке присутне у производу неће утицати на поверење, поузданост и интерес заинтересованих страна? - Инжењер за тестирање или тим за тестирање - дужност сваког инжењера за испитивање је да поправи грешке које би могле имати негативан утицај на квалитет производа.

Приоритет грешке , по мом мишљењу, у великој мери зависи од тога како испитивач презентира проблем тимовима за развој и управљање.

Схватите то као оглашавање или маркетинг овог издања - ово укључује 2 корака:

  1. Напиши или правилно пријави грешке
  2. Знајте све о грешци, тако да се даљи детаљи могу боље објаснити

Шта ћете научити:

Уметност извештавања о грешкама

Да, пријављивање грешака је уметност . Начин на који је грешка написана показује техничку вештину, стручност у домену и комуникационе могућности инжењера теста.

Типично, грешка треба да садржи следеће информације:

  • Резиме грешке
  • Кораци за репродукцију
  • Прилози (снимак, датотеке евиденције итд.,)
  • Репродуктивност грешака
  • Буг Северити
  • Верзија софтвера, Информације о окружењу
  • Остале информације засноване на организационим захтевима.

Важна напомена: Увек копајте дубље да бисте пронашли основни узрок проблема и пријавили га. На пример, једноставан неуспех пријаве са правилном комбинацијом корисничког имена и лозинке може бити повезан из различитих разлога као што су:

  1. Акредитиви за пријаву уопште нису потврђени
  2. Проблеми са мрежним истеком у случају удаљених пријава
  3. Систем може све ЦАПС сматрати не-ЦАПС.

Дакле, као Тестер требали бисте бити у стању да дешифрујете разлике док пратите резимее грешака:

  • „Није могуће пријавити се са исправним корисничким именом и лозинком“
  • „Не могу да се пријавим са исправним корисничким именом и лозинком када корисничко име или лозинка садрже комбинацију ЦАПС и не-ЦАПС абецеда.“

Потоњи је врло јасан опис проблема и недвосмислен је. Овим не само да повећавате кредибилитет тестера, већ пријављујете стварни проблем уместо симптома.

Сада, погледајмо свако поље укључено у извештај о грешкама и разговарајмо о важним аспектима сваког од њих:

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

Резиме грешке треба да пружи брзи снимак у чему је тачно проблем. Мора бити прецизан и добро усмерен.

Пример :

Осим теорије, покушаћу да објасним на примерима.

Претпоставимо да је то једноставан модул за пријављивање. Претпоставимо да је проблем у томе што нови корисник који посећује веб локацију не може да се пријави помоћу своје подразумеване лозинке. Када сам представио исти сценарио многим студентима које сам тренирао током почетне фазе обуке, било је неколико одговора као резиме грешака. У наставку је дато неколико примера како је резиме изгледао:

како играти .мкв датотеке на Виндовсима

' Нови корисник није у могућности да се пријави ”

„Пријава корисника не ради како се очекивало“

„Корисник није у могућности да се пријави тачном лозинком“

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

Можете ли из горњих узорака одабрати једну изјаву која заправо описује проблем? Мислим да није. Сажетак увек треба да садржи комплетне информације о неуспелом сценарију.

Размотрите следећу изјаву:

„Нови корисник није у могућности да се пријави са подразумеваном лозинком достављеном путем е-поште или СМС-а“

Као што видите, из горње изјаве програмер може јасно да разуме шта је проблем и где је проблем.

Дакле, покушајте да пронађете праве речи за опис резимеа који би директно давали информације. Морају се избјегавати генеричке изјаве попут „не ради исправно“, „не ради како се очекује“ итд.

# 2. Кораци за репродукцију и прилоге

Непродуктивне грешке увек заостају иако су можда значајне. Због тога пазите да правилно и описно напишете кораке.

Кораци би требали бити тачни и потпуно исти као они који су довели до проблема. За грешке повезане са функционалношћу, следећи пример је најбољи пример.

Пример :

Размотрите исто питање наведено у претходном одељку.

  1. Направите новог корисника помоћу опције Регистрација на почетној страници. (Пример корисничког имена: ХеллоУсер)
  2. Е-маил и СМС ће бити примљени са подразумеваном лозинком. ИД е-поште и мобилни број за СМС пружају се приликом креирања корисника у кораку # 1. (Пример е-маила: ХеллоУсер@хелло.цом , Узорак мобилног броја: 444-222-1123)
  3. Изаберите опцију Пријава на почетној страници.
  4. У текстуалном пољу корисничког имена наведите Пример корисничког имена наведен у кораку # 1.
  5. У поље за лозинку наведите подразумевану лозинку примљену е-поштом или СМС-ом.
  6. Кликните на дугме Пријави се
  7. Очекивани резултат: Корисник би требао бити у могућности да се пријави са наведеним корисничким именом и лозинком и да оде до странице корисничког налога.
  8. Прави резултат: Приказује се порука „Неважеће корисничко име / лозинка“.

кораци за пријаву квара

Ако било која од информација није наведена у горњем узорку, онда ће бити резултирају комуникацијским празнинама а програмер неће моћи да репродукује проблем. Кораци морају бити специфични и детаљни са примерима података које користите током тестирања.

Ако је могуће или где год је то могуће, наведите а снимак онога што тачно видите на екрану. На овај начин програмерима ће пружити не само добар увид у проблем, већ и доказ вашег резултата теста.

Тхе нефункционалан тестови као што су стрес, стабилност или тестови перформанси, поред горе наведених детаља, информације о сценарију који узрокује стрес у систему могу се пријавити такви какви јесу. Поред тога, мало је система који пријављују дневнике за сваку операцију која се изврши. Евиденције су обично исписи за штампу које програмери пружају у свом коду. Кад год се модул изврши, одговарајући дневници ће се исписати или приказати. Када су евиденције доступне, то би програмерима у великој мери помогло у репродукцији проблема.

# 3. Репродуктивност грешака

Питање које је велико или мало имаће приоритет на основу поновљивости. Може се видети увек, понекад, ретко или чак само једном. Издање које се репродукује као „увек“ имаће приоритет више од осталог.

не могу репродуковати квар

Дакле, дужност је инжењера испитивања да прати тачно сценарио за проблем који се увек репродукује. Понекад може постојати неколико проблема који су ван контроле инжењера, што би резултирало репродукцијом проблема само неколико пута, али у више покуса. У таквим случајевима, увек наведите број суђења, изврши се одређени сценарио заједно са бројем пута колико се проблем види током тих суђења.

То би, заузврат, додало веродостојност извештају о грешкама који сте поменули. Опет, ово би побољшало вашу репутацију тестера. Касније ћу вам рећи разлоге добре репутације.

# 4. Буг Северити

Озбиљност је несумњиво један од највећих утицаја на давање приоритета Бугу.

Следе различите категорије озбиљности. Имајте на уму да су ово само општи узорци и они се разликују од компаније до компаније.

  1. Озбиљност 1 - Прикажи заустављач - за грешке које су катастрофалне, без поправљања, корисник неће моћи да настави да користи софтвер и нема могућег решења
  2. Северити 2 - Хигх - за грешке сличне Северити 1, али постоји заобилазно решење
  3. Озбиљност 3 - средња
  4. Озбиљност 4 - ниска
  5. Озбиљност 5 - тривијално.

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

У нашим сет-топ боксовима, мало добављача услуга пружа информације о фреквенцији услуге како су тренутно подешене. Претпоставимо да се фреквенција приказује као 100 МХз уместо као 100,20 МХз. То можда неће утицати на корисников преглед услуга, али може утицати на надгледање дијагностике постављених врхова. Стога се ово може представити као питање озбиљности 3.

Под претпоставком сличног проблема у банкарском домену: Ако је стање на вашем рачуну приказано као 100 УСД, уместо 100,20 УСД, замислите утицај проблема. Ово мора бити грешка озбиљности -1. Као што можете видети у оба случаја, проблем је врло сличан томе што кориснички интерфејс не приказује цифре након децималне тачке. Али, утицај се разликује у зависности од домена.

Ефикасно учешће на састанцима за контролу верзије софтвера

Обично свака организација има свој поступак за испитивање грешака и њихово утврђивање приоритета. Генерално, током пројекта би се одржавао састанак у одређеним интервалима како би се разговарало о грешкама и давање приоритета истим.

Процес током таквих састанака је следећи:

  1. Испитајте листу грешака из система за управљање грешкама према тежини.
  2. Погледајте резиме и разговарајте о утицају грешке на корисничко искуство у коришћењу софтверског производа.
  3. На основу процене ризика и утицаја поставите приоритет и доделите грешку одговарајућем програмеру за њено исправљање.

Током корака 2 неопходно је да сваки инжењер теста заступа утицај грешке на корисничко искуство ако грешка не добије приоритет који заслужује. Напокон, ми смо инжењери који тестирају тачку гледишта корисника да напише тест случајеве и да тестира производ.

Размотрите горњи пример проблема не приказивања цифара након децималне запете у банкарском домену. Програмеру то може изгледати као мање озбиљан проблем. Могао би тврдити да би уместо да променљиву прогласи целим бројем, прогласио то покретном тачком за решавање проблема и самим тим мање озбиљним.

Али као испитивач, ваша улога објашњава ситуацију купца. Ваша поента би требала бити како би се корисник жалио у овом сценарију. Тестер треба да каже да ће то изазвати панику међу корисницима јер купац новац губи у центи.

Утицај неправилног маркетинга грешке

Ако се грешка не пласира правилно, створиће проблеме попут:

  • Нетачан приоритет квара
  • Кашњење у решавању важних проблема
  • Пуштање производа са озбиљним недостацима
  • Негативне повратне информације купаца
  • Девалвирање вредности бренда

Утицај неправилног маркетинга грешке

Поред свих горе наведених разлога, веома је важно да изградите свој репутација инжењера испитивања . То је више попут развијања вредности бренда за себе.

Ако у почетној фази своје каријере будете могли да задржите свој број „Не може се репродуковати“ или „Треба више информација“ или „Није важећа грешка“ или промене озбиљности што је могуће ниже, у једној фази ваше грешке неће бити под надзором и они би били директно додељени одговарајућем програмеру да би се поправио.

Да бисте развили такву вредност бренда и стекли поверење свог тима и развојних / или менаџерских тимова, морате да развијете неке техничке вештине у смислу тестирања знања, домена и вештина комуникације.

Закључак

Било који производ или услуга било велики или мали увек ће пропасти без одговарајућег оглашавања. Једном када се бренд успостави, било који мали производ може бити супер хит за публику.

Уз то, претјерано оглашавање производа такође може наштетити репутацији.

Дакле, грешка увек треба бити написана на јасан, сажет и прецизан начин тако да даје тачну локацију грешке на опсежној / исцрпној софтверској мапи. Понављам да ово не само да побољшава квалитет софтвера, већ у великој мери смањује трошкове тестирања и развоја софтвера.

Сада није прекасно! Хајде да одмах поправимо грешке!

Питања и одговори за испитивање софтверског тестирања

Препоручено читање

^