Шта је Буг?
Грешка је последица / исход грешке у кодирању.
Дефект у тестирању софтвера
Дефект у тестирање софтвера је варијација или одступање од софтверске апликације од захтева крајњих корисника или оригиналним пословним захтевима. Софтверска неисправност је грешка у кодирању која узрокује нетачне или неочекиване резултате софтверског програма који не испуњава стварне захтеве. Испитивачи би могли наићи на такве недостатке током извршавања тест случајева.
Ова два појма имају врло танку линију разлике. У индустрији су грешке које треба отклонити и тако их међусобно користе неки од тимова за тестирање.
Када тестери изврше тест случајеве, могли би наићи на такве резултате испитивања који су у супротности са очекиваним резултатима. Ова варијација резултата испитивања назива се софтверским недостатком. Ови недостаци или варијације се називају различитим именима у различитим организацијама, попут проблема, проблема, грешака или незгода.
У овом упутству ћете научити-
- Извештај о грешкама
- Процес управљања недостацима
- Откриће
- Категоризација
- Резолуција
- Верификација
- Затварање
- Извештавање
- Важне метрике дефеката
Извештај о грешкама у тестирању софтвера
Извештај о грешкама у тестирању софтвера је детаљан документ о грешкама пронађеним у софтверској апликацији. Извештај о грешкама садржи сваки детаљ о грешкама, као што је опис, датум проналаска грешке, име тестера који га је пронашао, име програмера који га је отклонио итд. Извештај о грешкама помаже у идентификовању сличних грешака у будућности, тако да се могу избећи.
Док пријављујете грешку програмеру, ваш извештај о грешци треба да садржи следеће информације
- ИД квара - јединствени идентификациони број квара.
- Опис дефекта - детаљан опис дефекта, укључујући информације о модулу у којем је дефект пронађен.
- Верзија - Верзија апликације у којој је пронађен недостатак.
- Кораци - детаљни кораци заједно са снимцима екрана помоћу којих програмер може да репродукује недостатке.
- Повећани датум - датум када је квар подигнут
- Референца - где у вама Наведите референцу на документе попут. захтеви, дизајн, архитектура или можда чак и снимци екрана грешке који помажу у разумевању недостатка
- Откривено именом - именом / личношћу тестера који је подигао квар
- Статус - Статус квара, више о томе касније
- Исправио - Име / ИД програмера који га је поправио
- Датум затварања - Датум затварања квара
- Озбиљност која описује утицај недостатка на апликацију
- Приоритет који се односи на хитност отклањања кварова. Приоритет озбиљности могао би бити висок / средњи / низак на основу хитности удара при којем би недостатак требало отклонити
Кликните овде ако видео снимку није доступан
Ресурси
Преузмите пример шаблона за извештавање о недостацима
Сматрајте следеће као тест менаџера
Ваш тим је пронашао грешке током тестирања пројекта Гуру99 Банкинг.
После недељу дана програмер одговара -
Следеће недеље тестер одговара
Као и у горњем случају, ако се комуникација са недостатком врши усмено, ствари се врло комплицирају. За контролу и ефикасно управљање грешкама потребан вам је животни циклус квара.
Шта је процес управљања недостацима?
Управљање недостацима је систематски поступак за идентификовање и исправљање грешака. Циклус управљања недостацима садржи следеће фазе 1) Откривање недостатака, 2) Категоризација недостатака 3) Исправљачи недостатака од стране програмера 4) Верификација од стране тестера, 5) Затварање кварова 6) Извештаји о недостацима на крају пројекта
Ова тема ће вас упутити како да примените поступак управљања недостацима на веб локацији пројекта Гуру99 Банк. Можете следити кораке у наставку за управљање недостацима.
Откриће
У фази откривања, пројектни тимови морају открити што је могуће више недостатака , пре него што их крајњи купац може открити. Каже се да је квар откривен и промењен у статус прихваћен када га програмери признају и прихвате
У горњем сценарију, тестери су открили 84 недостатка на веб локацији Гуру99.
Погледајмо следећи сценарио; ваш тим за тестирање открио је неке проблеме на веб локацији Гуру99 банке. Сматрају их недостацима и пријављују развојном тиму, али постоји сукоб -
У том случају, шта ћете радити као менаџер теста?
А) Договорите се са тест тимом да је то недостатак
Б) Руководилац теста преузима улогу судије да одлучи да ли је проблем дефект или не
Ц) Договорите се са развојним тимом који није дефект. Исправи Нетачно
У том случају, за решавање сукоба треба применити поступак решавања, ви преузимате улогу судије да одлучите да ли је проблем на веб локацији квар или не.
Категоризација
Категоризација оштећења помаже програмерима да дају предност својим задацима. То значи да овакав приоритет помаже програмерима да прво отклоне оне недостатке који су изузетно битни.
Дефекте обично категорише менаџер теста -
Направимо малу вежбу као што следи Повлачење и испуштање приоритета доле испод
- Критичан
- Хигх
- Средње
- Ниска
| 1) Учинак веб странице је преспор |
|
| 2) Функција пријаве на веб локацији не ради исправно |
|
| 3) ГУИ веб странице се не приказује правилно на мобилним уређајима |
|
| 4) Веб локација није могла да се сети сесије пријаве корисника |
|
| 5) Неке везе не раде |
|
Ево препоручених одговора
| Не. | Опис | Приоритет | Објашњење |
|---|---|---|---|
| 1 | Учинак веб странице је преспор | Хигх | Грешка у перформансама може узроковати велике непријатности кориснику. |
| 2 | Функција пријаве на веб локацији не функционише исправно | Критичан | Пријављивање је једна од главних функција банкарске веб странице ако ова функција не ради, то су озбиљне грешке |
| 3 | ГУИ веб локације се не приказује правилно на мобилним уређајима | Средње | Квар утиче на корисника који користи паметни телефон за преглед веб странице. |
| 4 | Веб локација није могла да се сети сесије пријаве корисника | Хигх | Ово је озбиљан проблем јер ће корисник моћи да се пријави, али неће моћи да изврши било какве даље трансакције |
| 5 | Неке везе не раде | Ниска | Ово је лако решење за развојне момке, а корисник и даље може приступити веб локацији без ових веза |
Решавање недостатака
Решавање проблема у тестирању софтвера корак је по корак поступак отклањања недостатака. Процес решавања кварова започиње додељивањем недостатака програмерима, затим програмери планирају да се квар поправи према приоритету, затим се отклањају недостаци и коначно програмери шаљу извештај о решавању менаџеру теста. Овај поступак помаже у лако отклањању и праћењу недостатака.
Можете следити следеће кораке да бисте отклонили квар.
- Задатак : Додељен програмеру или другом техничару ради поправљања и променио статус у Одговара .
- Поправљање распореда : У овој фази одговорност преузима програмер. Они ће створити распоред за отклањање ових недостатака, зависно од приоритета дефекта.
- Отклоните квар : Док развојни тим отклања недостатке, Тест Манагер прати поступак отклањања квара у поређењу са горњим распоредом.
- Пријави резолуцију : Затражите извештај о резолуцији од програмера када се отклоне недостаци.
Верификација
Након што је развојни тим отклонио и пријавио квар, тим за тестирање потврђује да су кварови заиста решени.
На пример, у горе наведеном сценарију, када је развојни тим известио да је већ отклонио 61 квар, ваш тим би поново тестирао да ли су ти кварови заиста отклоњени или не.
Затварање
Једном када се квар реши и верификује, квар се мења као статус затворен . Ако не, послали сте обавештење развојном тиму да поново провери квар.
Извештавање о недостацима
Извештавање о недостацима у тестирању софтвера је поступак у којем руководиоци испитивања припремају и шаљу извештај о недостацима менаџерском тиму ради повратних информација о процесу управљања недостацима и статусу недостатака. Тада менаџмент тим проверава извештај о квару и шаље повратне информације или пружа даљу подршку ако је потребно. Извештавање о недостацима помаже у бољој комуникацији, детаљном праћењу и објашњавању недостатака.
Управни одбор има право да зна статус квара. Морају да разумеју поступак управљања недостацима како би вас подржали у овом пројекту. Стога им морате пријавити тренутну ситуацију квара да бисте од њих добили повратне информације.
Важне метрике дефеката
Вратите се горе наведеном сценарију. Тимови програмера и теста имају преглед пријављених недостатака. Ево резултата те расправе
Како измерити и оценити квалитет извршења теста?
Ово је питање које сваки менаџер теста жели да зна. Постоје 2 параметра која можете сматрати следећим
У горе наведеном сценарију можете израчунати коефицијент одбијања дефекције (ДРР) је 20/84 = 0,238 (23,8%).
Још један пример, претпоставља се да веб локација банке Гуру99 има укупно 64 недостатка, али ваш тим за тестирање открива само 44 недостатка, односно пропустио је 20 недостатака. Према томе, можете израчунати коефицијент цурења квара (ДЛР) је 20/64 = 0,312 (31,2%).
Закључак, квалитет извођења теста процењује се помоћу следећа два параметра
Што је мања вредност ДРР и ДЛР, то је бољи квалитет извршења теста. Који је опсег односа који је прихватљив ? Овај опсег може бити дефинисан и прихваћен као основа у циљу пројекта или можете упутити метрику сличних пројеката.
У овом пројекту препоручена вредност прихватљивог односа је 5 ~ 10%. То значи да је квалитет извршења теста низак. Требали бисте пронаћи противмеру за смањење ових односа као што су
- Побољшати вештине тестирања члана.
- Проведите више времена за извршавање тестирања, посебно за преглед резултата извршења теста.