when opt automation testing
Да ли бисмо требали размотрити аутоматско тестирање за пројекат? Када треба ићи на аутоматско тестирање?
Тестирање се врши како би се крајњем кориснику обезбедили квалитетни производи. Фаза тестирања је један од главних аспеката СТЛЦ .
Било која компанија се више фокусира на тестирање софтвера, јер њен квалитет доноси оптимално задовољство купаца, али многи од њих и даље се боре у одабиру врсте тестирања, било аутоматским или ручним.
Овај чланак помаже читаоцу да разуме шта је испитивање аутоматизације, када се за то може одлучити и што је најважније, када не треба. Такође научите оптимално коришћење Алати за аутоматизацију за испитивање .
Шта год да се ради, требало би да се обавља ефикасно, а мора бити и исплативо. Штавише, требало би да има смисла тако да се купац осећа срећним због резултата.
Шта ћете научити:
- Тестирање софтвера и користи од трошкова
- Интелигенција иза тестирања софтвера
- Аутоматизација - да ли је заиста битна?
- Зашто аутоматизација?
- Фактор ризика
- Када аутоматизација не би требала бити пожељнија?
- Трошак у односу на повраћај улагања за аутоматизацију
- Где аутоматизација може смањити СВЕЂЕЊЕ минималног и БЕЗ трошка?
- Закључак
- Препоручено читање
Тестирање софтвера и користи од трошкова
Тестирање софтвера обично врши Тестер софтвера. Разлика између тестера и стварног корисника је у томе што ће потоњи знати само делимичну употребу софтвера који се користи за њихово пословање или за њихове задатке и неће знати софтвер у потпуности. С друге стране, тестер ће бити свестан свих техничких и функционалних захтева софтвера. На основу захтева које пружа клијент, мораће се припремити планови испитивања и тестови.
План испитивања није ништа друго до детаљан план начина на који ће се спровести поступак испитивања. Овде ће се наћи потпуни детаљи о броју ресурса и извора који су укључени у тестирање, шта треба урадити и када то учинити, шта се неће радити и окружење у којем ће се спроводити итд.
Тест случајеви треба да се припреме након јасног разумевања функционалног и техничког аспекта софтвера. Тестер мора да поседује истанчан посматрачки капацитет и потпуно знање о софтверу.
Штавише, трошак овде игра ефикасну улогу. Купци радије прихватају софтвер максималног квалитета уз минималне трошкове. Када кренемо на ручно тестирање, процес је заморнији и дуготрајнији јер га све ручно ради тестер.
На пример , када нам треба ‘н’ број тестера извршити регресијско тестирање , можда ће требати скоро 50 сати да се изврше сви тестови. А на основу доступности ресурса, извршиће се тест случајеви. Али са мање времена за аутоматизовано тестирање, врши се оптимално коришћење ресурса, уз максимално покривање тест случајева у поређењу са ручним тестирањем.
Интелигенција иза тестирања софтвера
Веома је важно за било коју организацију да зна када да започне процес тестирања и када да напусти поступак тестирања. Требало би да знамо када да започнемо са тестирањем, јер је бескорисно започети тестирање када је фаза развоја завршена и када захтевани критеријуми нису испуњени. Увек је најбоља пракса започети са фазом дизајна теста док је развој у току.
Доље су наведени критеријуми за улазак и излазак из софтверског тестирања:
Критеријуми за улазак
Једном када је пројектни документ потписан, планови испитивања морају се припремити у фази планирања. План испитивања игра виталну улогу. Потребан хардвер мора бити правилно инсталиран и конфигурисан, а функционалност хардвера треба проверити. Функционални захтеви морају бити јасни и одобрени. Развијени код програмери морају бити јединствено тестирани и одјављени.
Тест случајеви и подаци о тестовима морају бити припремљени и одобрени. Подаци о тестирању и апликација треба да буду доступни. Тестер мора да поседује значајно и довољно знања о апликацији. Ресурси би требали бити добро обучени о алатима и морају бити разјашњени са свим потребним функционалностима.
Тестер мора бити доступан. Када се не постигне неки од критеријума, ускраћују се критеријуми за испитивање.
(Белешка: Кликните на било коју слику за увећани приказ)
Излазни критеријуми
Тек када је најмање 95% обавезних тест случајева закључано са „положеним“ резултатом, можемо изаћи из фазе тестирања производа. Међутим, није тако лако утврдити када тестирање софтвера може бити заустављено или треба још извршити. А таква ситуација се често такође јавља.
Главни критеријуми су дати у наставку:
- Када се исправе све грешке.
- Када се рок достигне.
- Када се буџет исцрпи или исцрпи.
- Када прођу сви тестови.
- Када се уговор потпише.
- Када се изврши одређени проценат испитивања.
- Када Алфа и Бета тестирање завршава.
Критеријуми за излазак могу се извести чисто на основу фактора као што су ризик, трошкови итд. Када је постигнуто тестирање главних функционалних захтева, тада ће се тестирање обично зауставити и никада неће тражити мање грешке, што ће створити проблеме у каснији периоди.
Пример: Софтвер АБЦ је у фази дизајнирања. Развој и испитивање конструкције углавном се одвијају истовремено. Након замрзавања дизајна, започиње развој софтвера. Завршетак развоја софтвера, како је договорено, указује на критеријуме за улазак. Ово су резултати од развојног тима. Садржи напомене о издању и познате проблеме.
Након неколико итерација тестирања, када ниједан главни / блокатор / схов стоперс не чека решавање и 95% тестирања резултира пролазом, тада се то назива излазним критеријумима.
Аутоматизација - да ли је заиста битна?
Када треба да одлучимо да ли је потребно Техника аутоматизованог испитивања или не, овде се поставља питање расположивих ресурса. Разлози које требамо аутоматизовати су у провери да ли проток података и развијена функционалност раде према очекивањима без ручне интервенције или не. Углавном се користи на местима где ће софтвер имати промене у облику више издања / циклуса итд.
модел животног циклуса у софтверском инжењерству
На крају развоја сваког циклуса извршиће се тестирање тренутно додате функционалности. Поред тога, извршиће се тестирање старе функционалности како би се осигурало да старе функционалности нису сломљене. Ово је главни део који има могућност аутоматизације.
Приликом верификације логике вођене кодом и захтева за ГУИ, може се одабрати аутоматско тестирање, под условом да је фактор ризика висок.
Пример: За софтвер АБЦ честе су надоградње, ажурирања која тражи клијент, а пружају их програмери. Стога се као део тестирања врши регресија за софтвер који је већ у погону и ради у производњи. Без обзира на било који број издања, надоградњи и ажурирања, тренутна верзија ће бити важећа.
Рецимо да је за покривање регресионим испитивањем потребно 10 дана ручних напора, а затим се мора предузети највећа пажња за њихову аутоматизацију. Може да уштеди најмање 60% напора и ручни рад од 10 * 8 = 80 сати.
Аутоматизација може завршити само 80/24 = 3,33 дана. Ово уштеде приближно 6,67.
Зашто аутоматизација?
Аутоматизација се може одабрати само када:
- Апликација има врло велико подручје са високим степеном улагања напора у регресију.
- До оптимизације трошкова дошло је због ручних грешака.
- Софтвер има више верзија и издања.
- Исплативо је дугорочно.
- Фактор ризика је већи за шири опсег извођења теста.
- Подаци о трошковима и математички прорачуни су укључени у функционалност софтвера.
- Постоји већи пораст темпа извршавања, ефикасности заједно са квалитетом софтвера.
- Време је мање, чак и за високо ризична тестирања софтвера.
Фактор ризика
Фактор ризика постаје доминантно уобичајен у послу где постоји много зависности од временског фактора. Софтвер који ради на основу трансакционих система и који ради у више апликација захтеваће да софтвер делује идеално према дизајну софтвера. У овом случају постоје многи ризици повезани са постизањем исправног функционалног понашања.
Овде ће аутоматизација бити од велике помоћи у обављању функционалних трансакција бољим темпом према софтверском механизму.
На пример , у случају индикатора Форек тржишта, временски фактор је веома важан и критичан. Промене у залихама и робама се дешавају с обзиром на време, понекад и мање од секунди. Овде аутоматизација може помоћи у тестирању таквог софтвера са високим ризиком.
Пример: Софтвер АБЦ има вишеструка ажурирања и надоградње. Да би се уштедели ручни напори и смањило време обраде за фазу тестирања, основна верзија или старе функционалности могу се аутоматизовати. Ово може постати валидно само када основне функције остану непромењене.
Предност аутоматизације је што се њима може управљати без икаквих ручних интервенција. Чак се и ово може изводити паралелно са тестирањем новијих функционалности. Стога аутоматизација штеди много труда и много времена.
Када аутоматизација не би требала бити пожељнија?
Међу неколико организација постоји питање које гласи - Зашто 100% аутоматизација није могућа?
Одговор стручњака је НЕМОЈ јер су од квалификованих корисника потребна аутоматизована испитивања и они такође морају бити добро обучени. Аутоматизација се не може извршити током почетне фазе критеријума и захтеви апликација неће бити јасни.
Обично се даје предност аутоматизацији од друге итерације било ког издања софтвера. Кориснички интерфејс се може променити, што је скупље, а одржавање скрипте такође скупље. Када трошкови потребни за алат за аутоматизацију премашују буџет пројекта, можемо рећи не.
Пример: Софтвер КСИЗ је врста веб локације за е-трговину на којој се захтеви клијента не замрзавају и стално се мењају када клијенти то захтевају.
Овде, у овом случају, аутоматизација не може помоћи регресији. То је зато што старе функционалности које нису важеће не би требало тестирати, па их зато треба ручно радити. На пример, клијент мора да има све оквире са списком у основном софтверу да би их променио у падајуће оквире.
Трошак у односу на повраћај улагања за аутоматизацију
РОИ је врло низак када у почетку кренемо у аутоматизацију, јер је аутоматизација први пут скупа. РОИ се повећава како се ручни напор у тестирању софтвера смањује у односу на поновљене верзије другог издања. Морамо бити свесни очекиваног исхода било ког тест случаја пре аутоматизације.
Размислите о дизајну тест случајева који су важнији при одабиру аутоматизације и било ког алата како бисте били сигурни да неће повећати трошкове.
Где аутоматизација може смањити СВЕЂЕЊЕ минималног и БЕЗ трошка?
Чак и аутоматизација кошта јер потребан алат за тестирање мора бити купљен. Ресурси се морају обучити помоћу одређеног алата. Одабрани алат мора бити изводљив за тестирање свих области софтвера.
Дакле, стручњаци за испитивање аутоматизације треба пажљиво да изврше избор алата.
Пример: Размотрите производ КСИЗ који се бави осигурањем. Да би смањила фактор трошкова, компанија је користила само ручно тестирање, али када је у питању осигурање, фактор ризика је висок и може коштати фирму када било који од израчунавања премије пође по злу. Читав губитак биће или за менаџмент или крајњем кориснику. Крајњи корисник неће сносити губитак, док компанија мора.
Када се израчунати износ премије не подудара са оригиналном премијом (тј. Када постоји разлика у обрачуну премије за предњи и задњи крај), тада настаје велики проблем између купца и продавца производа. Може садржати много модула попут аутомобила, куће и других.
Кад нешто крене по злу, то је потпуни губитак. Разлика у прорачуну може имати смисла за испитивача и може створити грешке. У овом пројекту, ручно испитивање може да се уради за основни кориснички интерфејс, као што је верификација ТИН броја, друштвеног ИД-а и других информација повезаних са корисничким портфељем, па се стога може ручно тестирати тамо где је фактор ризика низак. Њих или би компанија профитирала, што више воле аутоматизацију за тестирање свог софтвера.
Закључак
И аутоматизација и ручно тестирање имају предности и недостатке. Тек када будемо јасни са концептима и захтевима, моћи ћемо да изаберемо какву врсту тестирања да спроведемо.
Ниједан пројекат се не може тестирати само ручним или аутоматским тестирањем. То зависи од дизајна, платформе и технологије са којом је софтвер развијен. Дакле, приликом доношења одлуке мора бити опрезан у избору методе испитивања и користити се саветима стручњака.
У горњем чланку можда смо пропустили неколико фактора, љубазно поделите факторе за које сматрате да су важни приликом одабира аутоматизације или чак алата за аутоматизацију.
У међувремену, слободно поделите своје коментаре / предлоге у вези са овим чланком.
Препоручено читање
- Најбољи алати за тестирање софтвера 2021. године (КА Тест Аутоматион Тоолс)
- Изазови ручног и аутоматизованог испитивања
- Топ 10+ најбољих књига за тестирање софтвера (књиге за ручно тестирање и аутоматизацију)
- Посао за КА помоћника за тестирање софтвера
- 11 најбољих алата за аутоматизацију за тестирање Андроид апликација (Андроид Тоолс Тестинг Тоолс)
- Да ли сте стручњак за ручно или аутоматско тестирање? Радите скраћено за нас!
- Курс за тестирање софтвера: Који институт за тестирање софтвера да се придружим?
- Одабир тестирања софтвера за вашу каријеру