Мени

Ад-хоц тестирање: Како пронаћи недостатке без формалног поступка тестирања

ad hoc testing how find defects without formal testing process

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

Сам појам ад-хоц подразумева недостатак структуре или нешто што није методично. Кад говориш о ад-хоц тестирање , то значи да је то облик а Црна кутија или тестирање понашања извршено без икаквог формалног процеса.

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

Ад-хоц тестирање

Ово се углавном ради са циљем покушаја откривања недостатака или недостатака који се не могу открити традиционалним или формалним процесима који се прате током циклуса испитивања.

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

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

Препоручено читање=> Истраживачко тестирање - како размишљати даље од традиционалних граница тестирања?

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

Почнимо са ад-хоц примером тестирања

Ево примера како можемо да извршимо ово тестирање када је у питању УИ Визард.

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

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

Да би тестирао овог тестера врши редовно тестирање, као што су:

која врста теста се користи за проверу да ли сви програми у апликацији правилно функционишу
  • Успешно попуните чаробњак са свим важећим подацима и креирајте план.
  • Откажите чаробњака на средини.
  • Измените креирани план помоћу чаробњака.
  • Избришите креирани план и уверите се да од њега нема остатака.
  • Унесите негативну вредност у чаробњак и погледајте одговарајуће поруке о грешкама.

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

  • Покушавајући да додате негативне податке, додајте одређене посебне знакове који нису ограничени да бисте видели да ли се њима правилно рукује. На пример, понекад чаробњаци не ограничавају {или (заграде, али у одређеним ситуацијама то може доћи у сукоб са кодом на основу језика на којем је написан и проузроковати врло непоуздано понашање.
  • Други тест се односи посебно на искачуће прозоре. Корисник може изазвати покретање искачућег прозора, а затим покушати да притисне дугме за повратак на тастатури. Много пута сам приметио да на тај начин чаробњак за позадину потпуно нестаје и губе се целокупни кориснички подаци који су унесени до тренутка покретања искачућег прозора!

Карактеристике ад-хоц тестирања:

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

Су:

  • Они су увек у складу са циљем теста. Међутим, то су одређени драстични тестови изведени са намером да се систем сруши.
  • Тестер треба да има потпуно знање и свест о систему који се тестира. Резултат овог тестирања проналази грешке које покушавају да истакну рупе у процесу тестирања.
  • Такође, гледајући горња два теста, природна реакција на њих би била таква - ова врста теста се може извршити само једном, јер поновни тест није изводљив уколико није повезан дефект.

Када радимо ад-хоц тестирање?

Питање од милион долара заиста!

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

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

Будући да је ад-хоц тестирање више техника тестирања „дивље дете“ која не мора да буде структурисана, општа препорука је да се оно мора извршити након извршавања тренутног сегмента теста. Друга тачка гледишта је да би се то могло учинити када се детаљна испитивања не могу извршити због мање времена.

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

Када не извршити?

Ако је претходно питање вредело милион долара, ово би требало вредети милијарду!

Иако смо утврдили колико ефикасно и плодно може бити ад-хоц тестирање, као вешт и способан испитивач такође морамо да дешифрујемо када не треба улагати у ову врсту тестирања. Иако је то према нахођењу тестера, ево их неке препоруке / примери када то можда није потребно.

  • Избегавајте ово испитивање када постоји тест случај за који постоји недостатак. У таквој ситуацији постоји потреба да се документује тачка отказа тест случаја, а затим верификује / поново тестира квар када је отклоњен. Стога овде неће бити примењиво.
  • Такође могу постојати одређени сценарији у којима се могу позвати купци или клијенти тестирајте бета верзију софтвера . У таквим случајевима ово тестирање не би требало да се спроводи.
  • Други сценарио је када се дода врло једноставан екран корисничког интерфејса. Традиционална позитивна и негативна испитивања овде би требала бити довољна да би се открили максимални недостаци.

Врсте ад-хоц тестирања

Ад-хоц тестирање може се сврстати у три категорије у наставку:

# 1) Бади тестирање

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

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

# 2) Тестирање парова

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

# 3) Испитивање мајмуна

Ово тестирање се углавном врши на нивоу јединичног тестирања. Тестер рашчлањује податке или тестове на потпуно случајан начин како би осигурао да систем може да издржи било какве падове. Ово испитивање се даље може класификовати у две категорије:

како написати случајеве регресионих тестова

Предности ад-хоц тестирања

Тестирање гарантује да тестер има пуно снаге да буде креативан колико је потребно.

Ово повећава квалитет и ефикасност испитивања као што је приказано у наставку:

  • Највећа предност која се истиче је што испитивач може пронаћи број недостатака него у традиционалном тестирању због различитих иновативних метода које могу применити за тестирање софтвера.
  • Овај облик тестирања може се применити било где у СДЛЦ; није ограничен само на тим за тестирање. Програмери такође могу да спроведу ово тестирање, што ће им помоћи да боље кодирају и предвидети који би се проблеми могли појавити.
  • Може се спојити са другим испитивањем да би се добили најбољи резултати који понекад могу скратити време потребно за редовно тестирање. То би омогућило генерисање квалитетнијих тест случајева и бољи квалитет производа у целини.
  • Не налаже да се уради било која документација која спречава додатно оптерећење тестера. Тестер се може концентрисати на стварно разумевање основне архитектуре.
  • У случајевима када нема довољно времена за тестирање, ово се може показати веома корисним у погледу покривености и квалитета испитивања.

Ад-хоц тестирање недостатака

Ад-хоц тестирање такође има неколико недостатака. Погледајмо неке од недостаци који су изражени:

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

  • Ако се прати из прве тачке, ово би такође резултирало тиме да се не могу поново створити недостаци у следећим покушајима ако се затраже информације.
  • Још једно веома важно питање које се ово открива је одговорност за напоре. Будући да ово није планирано / структурирано, не постоји начин да се узме у обзир време и труд уложени у ову врсту тестирања.
  • Ад-хоц тестирање мора да изводи само врло упућен и вешт тестер у тиму, јер захтева проактивност и интуицију у погледу предвиђања потенцијалних кварова превожених подручја.

Најбоље праксе како би ово тестирање било ефикасније

Опширно смо разговарали о предностима и недостацима повезаним са овим тестирањем.

У идеалном случају, ад-хоц тестирање би требало да нађе своје место у СДЛЦ-у, међутим, ако му се не приступи на одговарајући начин, може се показати скупо и губљење драгоценог времена за тестирање. Дакле, у наставку је дато неколико упутстава како би ад-хоц тестирање било ефикасно:

# 1) Идентификујте подручја која су склона оштећењима:

Када будете имали добру контролу над тестирањем одређеног дела софтвера, сложићете се да ће постојати одређене функције које су склоније грешкама од осталих. Ако сте нови у систему, наставите и проверите функције в / с дефекте отворене према њима.

Број дефеката на одређеној функцији показаће вам да је осетљив и требало би да прецизно одаберете баш то подручје за обављање ад-хоц тестирања. Ово се показало као врло ефикасан начин откривања неких озбиљних недостатака.

# 2) Стручност у изградњи:

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

Да, искусни тестери имају предност јер им вештине изграђене током година добро дођу, али нови тестери би ово требало да користе као платформу за стицање што више знања за дизајнирање бољих ад-хоц сценарија.

# 3) Направите категорије за тестирање:

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

Тада бисте могли да их категоризујете према функционалности / приоритету и тестирате по сегментима.

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

# 4) Имајте оквирни план:

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

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

# 5) Алати:

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

Они могу бити чак и озбиљни. Стога нам је веома важно да научимо и алате који ће вам помоћи да то одмах одредимо.

# 6) Документ за више недостатака:

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

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

Закључак

Детаљно смо разговарали о ад-хоц техникама тестирања - његовим снагама, слабостима, ситуацијама у којима би то било и не би било корисно.

Ово је једна техника тестирања која гарантује максимално задовољење и задовољење креативности тестера. У целој мојој тест каријера , Стекнем највеће задовољство ад-хоц тестирањем, јер нема ограничења за иновације, а ви на крају постајете више упућени.

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

О аутору: Ово је гостујући чланак Снехе Надиг. Ради као пробни вођа са преко 7 година искуства у пројектима ручног и аутоматизованог тестирања.

Да ли вршите ад-хоц тестирање на вашем пројекту? Који су ваши предлози за успешно ад-хоц тестирање?

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

^