Ад-хоц тестирање је врста тестирања софтвера коју програмери и софтверске компаније спроводе приликом провере тренутне итерације софтвера. Овај облик тестирања даје већи ниво увида у програм, лоцирајући проблеме које конвенционално тестирање можда не може да истакне.
Најважније је да тимови за тестирање имају потпуно разумевање ад хок процеса тестирања како би знали како да заобиђу његове изазове и да се постарају да тим може успешно да примени ову технику.
Познавање тачно како функционише ад-хоц тестирање и који алати могу олакшати његову примену, омогућава предузећу да континуирано унапређује сопствене процедуре обезбеђења квалитета. Формални процес тестирања прати врло специфична правила, што може довести до тога да тим пропусти одређене грешке – ад-хоц провере могу заобићи ове слепе тачке и брзо тестирати сваку софтверску функцију.
У овом чланку помно испитујемо ад-хоц тестирање и како га можете користити у своју корист када развијате софтверски производ.
Ад-хоц тестирање Значење: Шта је Ад-хоц тестирање?
Ад-хоц тестирање је процес осигурања квалитета који избегава формална правила и документацију – помажући тестерима да пронађу грешке у својој примени које конвенционални приступи не могу да идентификују. Ово обично захтева свеобухватно познавање софтвера пре почетка тестирања – укључујући разумевање унутрашњег рада програма. Ове ад-хоц провере имају за циљ да разбију апликацију на начине који одражавају унос корисника, узимајући у обзир различите потенцијалне ситуације како би програмери могли да закрпе све постојеће проблеме.
Недостатак документације је кључан за ову технику, која не укључује контролну листу или тест случајеве који би водили тестере кроз функције апликације. Ад-хоц тестирање се у потпуности односи на тестирање софтвера на који год начин тим одлучи да је ефикасан у том конкретном тренутку. Ово би могло узети у обзир постојеће формалне тестове, али би такође могло једноставно укључити спровођење што је могуће више тестова у (вероватно ограниченом) времену које је додељено за ову технику.
1. Када и зашто је потребно да урадите Ад-Хоц тестирање у тестирању софтвера?
Главни разлог због којег компаније спроводе ад-хоц тестирање је његова способност да открије грешке које традиционални приступи не могу пронаћи. Ово може бити из више разлога, као што су конвенционални тестни случајеви који прате посебно стандардизован процес који не може да објасни идиосинкразије апликације.
Сваки тип тестирања може понудити нове перспективе и занимљиве приступе осигурању квалитета – ово такође показује проблеме са уобичајеном стратегијом тестирања. На пример, ако ад-хоц тестирање може да идентификује забринутост коју тест случајеви тима не решавају, то сугерише да би могли имати користи од поновног калибрације своје методологије тестирања.
Тестери могу да спроведу ад хоц провере у било ком тренутку у процесу тестирања. Ово обично служи као допуна традиционалном (и формалнијем) обезбеђењу квалитета и, имајући то на уму, тестери могу да обављају ад-хоц инспекције док њихове колеге спроводе формалнија испитивања. Међутим, они могу уместо тога радије сачувати ад-хоц провере док не заврше формални процес тестирања као наставак који посебно циља на потенцијалне слепе тачке.
Ад-хоц тестирање такође може бити корисно када је време посебно ограничено због недостатка документације – право време зависи од компаније и њеног преферираног приступа.
2. Када не морате да радите Ад-Хоц тестирање
Ако нема довољно времена за обављање и ад-хоц и формалног тестирања, важно је да тим даје предност овом последњем, јер то осигурава значајну покривеност тестом – чак и ако неке празнине и даље постоје.
Ако формални тестови тима пронађу грешке које захтевају поправку, генерално је боље сачекати док програмери не заврше неопходне промене да би спровели ад хоц провере. У супротном, резултати које дају могли би ускоро да застаре, посебно ако се тестови односе на компоненту која већ има грешке.
Поред тога, ад-хоц тестирање мора да се деси пре фазе бета тестирања.
3. Ко је укључен у ад-хоц тестирање?
Постоји неколико кључних улога укључених у процес ад-хоц тестирања, укључујући:
• Тестери софтвера су главни чланови тима који спроводе ад хоц провере. Ако спроводите тестирање пријатеља или у пару, онда ће неколико ових тестера радити заједно на истим компонентама.
• Програмери могу независно да користе ове провере пре формалне фазе обезбеђења квалитета како би брзо прегледали сопствени софтвер, иако је то мање дубоко од наменског ад-хоц тестирања.
• Вође тима или одељења одобравају општу стратегију тестирања – помажући тестерима да одреде када да започну ад-хоц тестирање и како да га изврше без ометања других провера.
Предности ад-хоц тестирања
Предности ад-хоц тестирања у тестирању софтвера укључују:
1. Брзе резолуције
Пошто ови тестови не укључују честу документацију пре, током или после провера, могуће је да тимови много брже идентификују проблеме. Ова једноставност нуди огромну слободу тестерима.
На пример, ако тестирају компоненту и не могу да идентификују ниједну грешку, тим може једноставно да пређе на следећи тест, а да то не забележи у документу.
2. Допуњује друге типове тестирања
Ниједна стратегија тестирања није савршена, а 100% покривеност је обично немогуће постићи – чак и уз свеобухватан распоред. Увек ће постојати празнине у конвенционалном тестирању, тако да је важно да компаније интегришу више приступа.
Ад-хоц тестирање посебно има за циљ да пронађе питања која формално тестирање не може да покрије – гарантујући ширу укупну покривеност тестом.
3. Флексибилно извршење
Ад-хоц тестирање се може десити у било ком тренутку у процесу осигурања квалитета пре бета тестирања, омогућавајући компанијама и тимовима да одлуче када је најбоље извршити ове провере. Они могу изабрати да изводе ад-хоц тестове у тандему са конвенционалним тестирањем или могу да сачекају до касније – без обзира на све, тим има користи од избора који су им на располагању.
4. Већа сарадња
Програмери су више укључени у овај процес од многих других облика тестирања – посебно ако компанија користи тестирање пријатеља и парова.
Као резултат тога, програмери добијају бољи увид у сопствене апликације и можда ће моћи да адресирају грешке на вишим стандардима. Ово помаже да се још више побољша укупни квалитет софтвера.
5. Различите перспективе
Ад-хоц тестирање може да прикаже апликацију из нових углова, помажући тестерима да се ангажују са овим функцијама на нове начине. Додатне перспективе су критичне током тестирања јер формалне провере често имају барем мање празнине.
Ако ад-хоц тестери користе софтвер са специфичном намером да га разбију, моћи ће лакше да одреде ограничења програма.
Изазови ад-хоц тестирања
Ад-хоц процес тестирања такође има неколико изазова, као што су:
1. Потешкоће са извештавањем
Недостатак документације чини ад-хоц тестирање много бржим, али такође може отежати извештавање за било шта осим великог проблема.
На пример, једна претходно спроведена провера може касније постати релевантнија иако у почетку није довела до значајних резултата. Без свеобухватне документације, тим можда неће моћи да објасни ове тестове.
2. Мање поновљиво
На сличан начин, тестери можда нису у потпуности свесни тачног стања неопходног да изазове реакције које примећују. На пример, ад-хоц провера која враћа грешку можда неће имати довољно информација да би тим предузео акцију. Можда нису свесни како да понове овај тест и добију исти резултат.
3. Захтева софтверско искуство
Пошто је брзина кључна током ад-хоц тестирања и обично укључује покушај да се разбије апликација, важно је да ови тестери добро разумеју овај програм.
Познавање начина на који функционише омогућава тестерима да разбију и манипулишу софтвером на више начина, али то би могло значајно повећати захтеве за вештинама за ад-хоц тестирање.
4. Ограничена одговорност
Недостатак документације може изазвати више проблема него само лоше извештавање; такође може ненамерно да продужи процес тестирања, утичући на корисност брзих појединачних ад-хоц тестова.
Тестери могу да се боре да прате свој напредак без довољно документације током сваке фазе. Ово може чак довести до тога да понове проверу коју су други тестери већ завршили.
5. Можда не одражава корисничко искуство
Циљ практично сваког типа тестирања је да се узму у обзир грешке које на неки начин утичу на крајње кориснике. Ад-хоц тестирање се првенствено ослања на искусног тестера који покушава да опонаша неискусног корисника и то би требало да буде доследно током сваке провере, укључујући и њихове покушаје да разбију апликацију.
Карактеристике ад-хоц тестова
Главне карактеристике успешних ад-хоц тестова укључују:
1. Истражни
Главни приоритет ад-хоц тестирања је да се идентификују грешке у апликацији користећи технике које конвенционалне провере не узимају у обзир. Ад-хоц прегледи претражују овај софтвер у сврху проналажења рупа у процедури тестирања тима, укључујући покривање њихових тест случајева.
2. Неструктуриран
Ад хоц провере обично немају утврђени план осим спровођења што је могуће више тестова ван типичних граница формалног обезбеђења квалитета. Тестери обично групишу провере по компонентама ради практичности, али чак ни то није неопходно – можда чак и осмисле провере док их изводе.
3. На основу искуства
Ад-хоц тестери користе своје постојеће софтверско искуство да би проценили који тестови би донели највише користи и адресирали уобичајене слепе тачке у формалном тестирању.
Иако је процес тестирања још увек потпуно неструктуриран, тестери примењују своје знање о претходним ад-хоц проверама, између осталог, док одлучују о својој стратегији.
4. Широког опсега
Не постоје тачни водичи за које провере тим треба да спроводи током ад-хоц тестирања, али они обично покривају низ компоненти – вероватно са већим фокусом на осетљивије аспекте апликације. Ово помаже тестерима да гарантују да су њихови прегледи у стању да у потпуности допуне формално тестирање.
Шта тестирамо у ад-хоц тестовима?
Тимови за осигурање квалитета обично тестирају следеће током ад-хоц тестирања:
1. Квалитет софтвера
Ове провере имају за циљ да идентификују грешке у апликацији које конвенционално тестирање не може да открије; то значи да процес углавном тестира опште здравље апликације.
Што више грешака које ад-хоц тестирање може да лоцира, то више побољшања програмери могу да примене пре истека рока.
2. Тест случајеви
Ад-хоц тестирање генерално не примењује тестне случајеве – а то је посебно да би тим могао да истражи колико је ефикасан у обезбеђивању довољно покривености. Тестни случајеви су вероватно неадекватни ако ад-хоц провере могу пронаћи грешке које конвенционални процеси тестирања не могу.
3. Особље за тестирање
Циљ би такође могао да буде провера вештина и знања тима за тестирање, чак и ако су тестни случајеви адекватни. На пример, њихова методологија имплементације случајева може бити недовољна и ад-хоц тестирање може бити критично за решавање насталих недостатака у покривености тестовима.
4. Софтверска ограничења
Ад-хоц тестирање такође настоји да разуме ограничења апликације – на пример како она реагује на неочекиване уносе или велика оптерећења система. Тестери би могли посебно да истражују поруке о грешци програма и колико добро ова апликација ради када је под великим притиском.
Рашчишћавање неке забуне:
Ад-хоц тестирање и истраживачко тестирање
Неки људи сматрају ад-хоц и истраживачко тестирање синонимима, иако је истина компликованија од ове.
1. Шта је истраживачко тестирање?
Експлораторно тестирање се односи на процедуре осигурања квалитета које истражују софтвер са холистичке тачке гледишта и посебно комбинују процесе откривања и тестирања у једну методу. Ово је обично средина између потпуно структурисаног тестирања и ад-хоц провера у потпуности слободног облика.
Истраживачко тестирање најбоље функционише у специфичним сценаријима, на пример када је неопходна брза повратна информација или ако тим мора да се позабави крајњим случајевима. Ова врста тестирања обично достиже свој пуни потенцијал када тим уз њега користи тестирање скриптова.
2. Разлике између истраживачког тестирања
и ад-хоц тестирање
Највећа разлика између ад-хоц и истраживачког тестирања је употреба документације за снимање и олакшавање провера, док ад-хоц тестирање ово у потпуности избегава. Експлораторно тестирање ставља већи нагласак на слободу тестирања, али никада на истом нивоу као ад-хоц приступ који је потпуно неструктуриран.
Истраживачко тестирање такође укључује учење о апликацији и њеном унутрашњем раду током ових провера – ад-хоц тестери уместо тога често имају свеобухватно знање о функционалности софтвера пре него што почну.
Врсте ад-хоц тестова
Постоје три главна облика ад-хоц тестирања у тестирању софтвера, укључујући:
1. Тестирање мајмуна
Можда најпопуларнији тип ад-хоц тестирања, тестови на мајмунима су они који укључују тим који насумично посматра различите компоненте.
Ово се обично дешава током процеса јединичног тестирања и спроводи серију провера без икаквих тест случајева. Тестери независно истражују податке на потпуно неструктурисане начине, дозвољавајући им да испитају шири систем и његову способност да се одупре интензивном напрезању корисничких уноса.
Посматрање резултата ових нескриптованих техника помаже тиму за тестирање да идентификује грешке које су други тестови јединица пропустили због недостатака у конвенционалним методама тестирања.
2. Пријатељско тестирање
У ад-хоц контексту, другарски тестови користе најмање два члана особља – обично тестер и програмер – и првенствено се одвијају након фазе тестирања јединице . ‘Пријатељи’ раде заједно на истом модулу како би утврдили грешке. Њихове разноврсне вештине и свеобухватно искуство чине их ефикаснијим тимом, који помаже у ублажавању многих проблема који настају услед недостатка документације.
Програмер би чак могао да предложи неколико самих тестова, дозвољавајући им да идентификују компоненте којима је можда потребно више пажње.
3. Тестирање у пару
Тестирање у пару је слично по томе што укључује два члана особља, али то су обично два одвојена тестера, од којих један извршава стварне тестове док други води белешке.
Чак и без формалне документације, вођење белешки може омогућити тиму да неформално прати појединачне ад-хоц провере. Улоге тестера и писара се могу мењати у зависности од теста или би пар могао да задржи своје додељене улоге током целог процеса.
Тестер који има више искуства је обично онај који обавља стварне провере – иако они увек деле посао једни са другима.
Ручни или аутоматизовани ад-хоц тестови?
Аутоматско тестирање може помоћи тимовима да уштеде још више времена током фазе осигурања квалитета; што омогућава тестерима да у свој распоред уклопе више провера. Чак и без одређене структуре, неопходно је да тестери раде на максимизирању покривености, а аутоматизација подстиче детаљније провере овог софтвера.
Аутоматске ад-хоц провере су генерално тачније од ручних тестова због своје способности да избегну људску грешку током задатака напамет – ово је посебно корисно када се исти тестови примењују на различитим итерацијама. Успех ове процедуре обично зависи од аутоматизованог алата за тестирање који тим одабере и његове функционалности.
Међутим, аутоматизовано тестирање има одређена ограничења. На пример, главна снага ад-хоц тестирања је његова способност да опонаша кориснички унос и спроведе насумичне провере како их тестер смисли. Ови тестови би могли изгубити своју насумицу ако се програм тестирања организације бори са сложеним провјерама.
Време које је потребно за аутоматизацију ових веома специфичних задатака такође може ограничити типичне уштеде времена овог процеса. Важно је да тимови темељно истраже доступне алате за аутоматизацију како би пронашли онај који одговара пројекту њихове компаније.
Шта вам је потребно да започнете ад-хоц тестирање?
Ево главних предуслова за ад-хоц тестирање:
1. Квалификовано особље
Пошто су ад-хоц тестови брзи, насумични прегледи унутрашњег рада софтвера, обично помаже да се тестери са искуством са софтвером. Такође би требало да имају радно знање о кључним принципима тестирања – то им омогућава да лако идентификују најефикасније провере.
2. Неструктурирани приступ
Тестери морају бити спремни да напусте своје уобичајене стратегије за ад-хоц тестирање; овај начин размишљања је једнако критичан као и саме провере квалитета. Овај метод може успети само без структуре или документације и од виталног је значаја да тестери то упамте у свакој фази.
3. Софтвер за аутоматизацију
Иако се ад-хоц тестирање више ослања на тестирање насумичних улаза и услова, аутоматизација је и даље веома ефикасна техника у било ком контексту.
Из тог разлога, ад-хоц провере би и даље требало да примењују аутоматизоване алате за тестирање где је то могуће, пошто права апликација може значајно да поједностави процес.
4. Други облици тестирања
Ад-хоц тестови најбоље функционишу заједно са другим проверама које имају формалнији приступ – помажући тиму да гарантује значајну покривеност софтвера. Од виталног је значаја да тестери мешају различите технике, мада то може бити пре, током или након што заврше ад-хоц тестирање.
Ад-хоц процес тестирања
Уобичајени кораци које тестери треба да прате када врше ад-хоц тестирање у тестирању софтвера су:
1. Дефинисање ад-хоц циљева теста
Ова фаза је ограничена због недостатка документације и структуре, али је и даље најважније да тим има јасан фокус. Тестери могу да почну да деле нејасне идеје о томе које предстојеће тестове да покрећу и компонентама да дају приоритет.
2. Избор ад-хоц тест тима
Док тим размишља о бројним потенцијалним ад-хоц проверама, они такође откривају који би тестери били најбољи за ову врсту тестирања. Обично бирају тестере који добро разумеју апликацију и такође их могу упарити са програмером.
3. Извођење ад-хоц тестова
Након што одлуче који су тестери прави за ову фазу, ови чланови тима почињу своје провере на договореној тачки тестирања. Њихов циљ је да изврше што је могуће више ад-хоц провера – које тестери можда неће смислити до ове фазе.
4. Вредновање резултата теста
По завршетку тестова (или чак између појединачних провера) тестери ће проценити резултате, али без формалног документовања у тест случају. Ако открију проблеме са апликацијом, неформално их снимају и разговарају о следећим корацима тима.
5. Пријављивање свих откривених грешака
Када процене резултате, тестери морају обавестити програмере о грешкама присутним у софтверу како би имали довољно времена да их поправе пре објављивања.
Тим за тестирање такође користи информације да одреди како да побољша своје формалне процесе тестирања.
6. Поновно тестирање по потреби
Тим за тестирање ће вероватно поновити ад-хоц процес за нове итерације апликације како би проверио колико добро обрађује ажурирања. Пошто ће тестери поправити многе од претходно идентификованих недостатака у својим тестним случајевима, будуће ад-хоц провере могу захтевати другачији приступ.
Најбоље праксе за ад-хоц тестирање
Постоје одређене праксе које би тимови за тестирање требало да примењују током ад-хоц тестирања, укључујући:
1. Циљајте потенцијалне празнине у тестирању
Док ад-хоц тестирање укључује много мање планирања од других типова, тим и даље има за циљ да реши недостатке у осигурању квалитета. Ако ад-хоц тестери посумњају на било какве специфичне проблеме са тест случајевима тима, требало би да дају предност овоме приликом вршења својих провера.
2. Размотрите софтвер за аутоматизацију
Стратегије аутоматизације као што је хипераутоматизација могу понудити многе предности компанијама које желе да спроводе ад-хоц тестове.
Успех овога зависи од неколико кључних фактора, укључујући алат који предузеће изабере, као и општу сложеност њихових ад-хоц тестова.
3. Водите свеобухватне белешке
Недостатак документације у ад-хоц тестирању је углавном да би се овај процес још више поједноставио – тим би могао имати користи од вођења неформалних белешки како напредују. Ово даје тестерима јасну евиденцију ових провера и њихових резултата, повећавајући њихову укупну поновљивост.
4. Наставите да усавршавате тестове
Ад-хоц тестери континуирано усавршавају свој приступ како би узели у обзир промене у стратегији тестирања тима. Када гледају новије верзије софтвера компаније, на пример, они би могли да прилагоде ове провере као одговор на новије и инклузивније формалне тестне случајеве.
7 грешака и замки у имплементацији
Ад-хоц тестови
Као и код сваког процеса тестирања, постоји широк спектар потенцијалних грешака на којима тим треба да ради да би избегао, као што су:
1. Неискусни тестери
Да би одржао очекивани темпо ад-хоц тестирања, вођа тима мора да додели тестере на основу знања и вештина које имају. Док многи облици тестирања могу да приме особље за обезбеђење квалитета на почетним нивоима, ад-хоц провере захтевају чланове тима који у потпуности разумеју софтвер; пожељно са искуством у вођењу ових тестова.
2. Нефокусиране провере
Ад-хоц тестирање може значајно побољшати покривеност тестом због бржег темпа – тим не мора да попуњава обимну документацију пре и после сваке провере.
Међутим, ад-хоц тестери и даље морају задржати снажан фокус; на пример, могли би да одлуче да дају приоритет одређеним компонентама са већим ризиком од отказа.
3. Без планирања
Избегавање било каквог плана може ограничити ефикасност ад-хоц тестирања. Упркос неструктурираној природи овог приступа, важно је да тим има грубу идеју о томе које тестове треба да спроведе пре него што почну.
Време је ограничено током овог процеса и знање како да се настави може понудити многе предности.
4. Превише структуриран
На супротном крају спектра, овај приступ се обично ослања на недостатак планирања јер то помаже тестерима да активно подвргну тест случајеве и пронађу скривене грешке.
Ад хоц тестирање је такође познато као насумично тестирање и присиљавање структуре на њу може спречити ове провере да лоцирају грешке.
5. Нема дугорочних промена
Сврха ад-хоц тестирања је да се идентификују све слабости у тест случајевима тима; ово испитује њихову укупну стратегију исто колико и сам софтвер.
Међутим, то значи да су ад-хоц тестови генерално ефикасни само ако тим користи ове информације да побољша своје формалне провере током времена.
6. Некомпатибилни скупови података
Практично сваки облик тестирања захтева облик симулираних података да би се проценило како апликација реагује; неки алати омогућавају тестерима да аутоматски попуне програм лажним подацима .
Међутим, ово можда не одражава начин на који би се корисник ангажовао са софтвером – ад хоц провере захтевају скупове података са којима ће софтвер вероватно наићи.
7. Информациони силоси
Од суштинског је значаја да су тестери и програмери у сталној међусобној комуникацији, чак и ако ово друго није део ад-хоц процеса тестирања.
Ово помаже свима да разумеју који су тестови спроведени – показујући следеће радње које треба предузети, а истовремено спречава тестере да беспотребно понављају одређене провере.
Типови излаза из ад-хоц тестова
Ад-хоц провере производе неколико различитих излаза, укључујући:
1. Резултати испитивања
Појединачни тестови дају различите резултате специфичне за тачну компоненту и приступ који је укључен – то може имати различите облике.
Обично је одговорност тестера да утврди да ли резултати представљају грешку, иако недостатак документације отежава упоређивање овога са њиховим очекивањима. Тим прослеђује ове резултате програмерима ако примете било какве проблеме.
2. Тест евиденције
Сам софтвер користи компликован систем интерних евиденција да надгледа уносе корисника и истакне низ проблема са датотекама или базама података који се могу појавити.
Ово може указивати на интерну грешку, укључујући одређени део софтвера који узрокује проблем. Са овим информацијама, ад-хоц тестери и програмери могу много лакше да реше проблеме које открију.
3. Поруке о грешци
Многе ад-хоц провере имају за циљ да разбију софтвер и разоткрију његове границе, што значи да су поруке о грешци апликације један од најчешћих излаза из ових тестова.
Намерним изазивањем порука о грешци, тим може да покаже шта просечни крајњи корисник види кад год неочекиване радње које предузму имају негативан утицај на рад програма.
Примери ад-хоц тестирања
Ево три ад-хоц сценарија тестирања који показују како би тим могао да га примени за различите апликације:
1. Веб апликација за е-трговину
Ако компанија жели да тестира веб апликацију засновану на е-трговини, могла би да користи ад-хоц тестирање – посебно тестирање мајмуна – да види колико добро платформа подноси неочекиване интеракције корисника.
Тестери могу имати за циљ да гурну сваку функцију до својих граница, на пример додавањем артикала у своју корпу у нереалним количинама или покушајем куповине производа који нису на залихама. Они нису ограничени тимским тест случајевима и постоји неколико ограничења на које провере могу да изврше; тестери могу чак покушати да доврше куповину користећи застареле УРЛ адресе.
2. Десктоп апликација
Ад-хоц тестери такође могу да примене ове технике за десктоп апликације са могућим фокусом на различите машине и колико добро свака од њих прилагођава програм.
Чланови тима могу да врше ове провере више пута да виде како промена хардверских или софтверских поставки утиче на укупне перформансе апликације. На пример, одређена графичка картица може имати проблема да прикаже интерфејс.
Алтернативно, ови тестери могу једноставно да дају свом програму немогуће улазе и виде како он реагује, на пример да ли може исправно да прикаже поруке о грешци које крајњем кориснику објашњавају проблем на адекватан начин.
3. Мобилна апликација
Један од начина на који би ад-хоц тестери могли да испитају мобилну апликацију је да тестирају њене безбедносне протоколе – могли би да покушају да директно приступе развојним алатима апликације, на пример.
Тим може покушати да види да ли су у стању да изврше неовлашћене радње тако што ће пронаћи уобичајене рупе и подвиге; могли би посебно замолити чланове особља са искуством у безбедности апликација да то олакшају.
Ово такође може укључивати тестирање у пару са програмерима због њиховог увида у дизајн апликације, дозвољавајући тестеру да разбије софтвер и покаже где тачно недостаје његова безбедност.
Откривене врсте грешака и грешака
путем ад-хоц тестирања
Ад-хоц провере могу открити многе проблеме са програмом, као што су:
1. Функционалне грешке
Коришћење ад-хоц тестирања за испитивање основних карактеристика апликације може открити озбиљне грешке које утичу на начин на који крајњи корисници могу да комуницирају са њом.
На пример, мајмунско тестирање опција плаћања сајта за е-трговину ће илустровати услове који спречавају трансакцију.
2. Питања перформанси
Тестери могу посебно да раде на стварању проблема са перформансама у програму – као што је попуњавање базе података различитим улазима за нежељену пошту.
Ово би се могло манифестовати као значајно време кашњења или чак општа нестабилност софтвера, што ће вероватно довести до (потенцијално на нивоу система) пада.
3. Проблеми употребљивости
Ове провере такође могу да истакну грешке у интерфејсу и опште корисничко искуство. Кориснички интерфејс мобилне апликације , на пример, може да се представи другачије на другом оперативном систему или резолуцији екрана. Лош интерфејс може довести до тога да се корисници боре да раде са овом апликацијом.
4. Безбедносни недостаци
Насумична природа ад-хоц тестирања омогућава му да покрије низ уобичајених и ретких безбедносних проблема; тестер би могао да користи ове провере да пронађе административна позадинска врата програма.
Алтернативно, њихова инспекција може показати да софтвер нема шифровање података.
Уобичајене метрике ад-хоц тестирања
Ад-хоц тестирање користи различите метрике да би олакшало своје резултате, укључујући:
1. Ефикасност откривања кварова
Ова метрика посматра колико је ефикасан процес тестирања у проналажењу недостатака у сваком облику тестирања, укључујући ад-хоц тестирање. Ефикасност откривања дефекта је проценат откривених недостатака подељен укупним бројем проблема – који показује колико су тестови ефикасни.
2. Стопа покривености тестом
Помоћна функција ад-хоц тестирања је повећање покривености провјеравањем компоненти на начин који тестни случајеви не узимају у обзир. То значи да ће тестери такође имати за циљ да радикално повећају покривеност тестом за сваку проверу колико год могу.
3. Укупно трајање теста
Ад-хоц тестирање је много брже од других процеса осигурања квалитета – и од суштинског је значаја да тестери раде на одржавању ове предности. Показатељи трајања теста показују члановима тима како могу да уштеде време и још више увећају предности ад-хоц стратегија.
4. Стопа пада
Ови тестови често имају за циљ да покваре софтвер и изазову пад или озбиљну грешку – дозвољавајући им да превазиђу типичне стратегије тестирања и пронађу неочекиване проблеме. У том циљу, може вам помоћи да сазнате колико често се софтвер руши и шта узрокује ове проблеме.
5 најбољих алата за ад-хоц тестирање
Постоји много бесплатних и плаћених алата за тестирање доступних за ад-хоц тестирање у тестирању софтвера – пет најбољих су следећи:
1. ЗАПТЕСТ Фрее & Ентерприсе Едитион
ЗАПТЕСТ је свеобухватан програм за тестирање софтвера који пружа висок ниво функционалности теста + РПА иу својим бесплатним и пословним верзијама.
Овај комплет за аутоматизацију софтвера + РПА Суите омогућава потпуно тестирање на различитим десктоп и мобилним платформама; Технологија софтвера 1СЦРИПТ такође омогућава корисницима да с лакоћом извршавају исте провере више пута. Поврх овога, алат користи врхунску компјутерску визију , што омогућава ЗАПТЕСТ-у да изводи ад-хоц тестове из људске перспективе.
2. БровсерСтацк
БровсерСтацк је платформа у облаку која може олакшати тестирање на преко 3000 различитих машина, уз додатну функцију аутоматизације Селениум скрипти. Иако пружа снажну покривеност софтверским пројектима, најбоље функционише са претраживачима и мобилним апликацијама .
БровсерСтацк решења за тестирање такође укључују бесплатну пробну верзију са 100 минута аутоматског тестирања – иако ово може имати ограничену употребу.
Иако приступ заснован на облаку може бити од помоћи, он такође негативно утиче на време одговора платформе.
3. ЛамбдаТест
ЛамбдаТест на сличан начин користи технологију засновану на облаку и ставља снажан нагласак на тестирање претраживача што може ограничити његову ефикасност за друге апликације – иако се и даље добро уклапа са иОС и Андроид програмима. Ово је корисна платформа када је скалабилност проблем и интегрише се са многим другим услугама хостинга за тестирање.
Међутим, неки корисници имају помешане реакције на цене апликације у различитим непробним опцијама које су доступне, што потенцијално ограничава доступност за мање организације.
4. ТестРаил
ТестРаил је генерално прилично прилагодљив због потпуног покретања у претраживачу и, упркос снажном фокусу на ефикасне тест случајеве, такође се може похвалити директном ад-хоц функционалношћу. Аналитика коју пружа након сваког теста такође може помоћи тимовима који активно избегавају прављење сопствене независне документације док им и даље дозвољавају да валидирају свој процес тестирања.
Међутим, већи пакети могу имати проблема са форматом заснованим на претраживачу, што може значајно ограничити уштеду времена ад-хоц тестирања.
5. Зепхир
Зепхир је СмартБеар платформа за управљање тестирањем која помаже тимовима за осигурање квалитета да побољшају своју видљивост тестирања док се такође добро интегрише са другим софтвером за праћење грешака.
Међутим, ова функција је ограничена на одређене апликације, при чему су Цонфлуенце и Јира оне које имају највише користи од Зепхир-а – ово можда нису најефикаснија решења за свако пословање. Постоји неколико скалабилних програма доступних под брендом Зепхир по различитим ценама.
Контролна листа за ад-хоц тестирање, савети и трикови
Ево додатних савета за тимове које треба узети у обзир приликом спровођења ад-хоц тестирања:
1. Дајте приоритет осетљивим компонентама
Неке функције или компоненте су природно више изложене ризику од грешке од других, посебно ако су важне за целокупну функцију програма.
Сваки приступ тестирању треба да идентификује делове апликације који могу имати користи од детаљније пажње. Ово је посебно корисно када је укупно време за тестирање ограничено.
2. Истражите различите алате за тестирање
Алат који организација примењује да олакша своје тестове може утицати на покривеност и поузданост ових провера.
Са ад-хоц тестирањем, вреди погледати што више програма како бисте пронашли оне који одговарају аспекту усмереном на корисника. Софтвер који користи технологију компјутерског вида, као што је ЗАПТЕСТ, може приступити ад-хоц тестовима користећи стратегију налик човеку.
3. Усвојите ад-хоц начин размишљања
Ад-хоц тестирање нуди огромну слободу током фазе осигурања квалитета, али тим се мора посветити томе да би добио кључне предности стратегије.
На пример, ад-хоц тестери би требало да избегавају све своје уобичајене документе осим основног вођења белешки и морају да прегледају софтвер из потпуно нове перспективе.
4. Инстинкти тестирања поверења
Искуство са ад-хоц тестирањем или општим проверама софтвера може помоћи да се истакну уобичајене тачке квара и то помаже тестерима да одреде како да уоче грешке свих врста.
Од виталног је значаја да тестери верују својим инстинктима и увек користе ово знање у своју корист – они могу интуитивно да предвиде које би ад хоц провере биле од највеће помоћи.
5. Потпуно евидентирајте откривене грешке
Иако ад-хоц тестирање нема формалну документацију и углавном се ослања на неформалне белешке, и даље је неопходно да тим може да идентификује и саопшти узрок софтверске грешке.
Морају да евидентирају све информације које тест пружа, а које су релевантне за програмере, као што су потенцијални узроци ових проблема.
6. Увек рачунајте на корисника
Сваки облик тестирања има за циљ да у одређеној мери прилагоди целокупно искуство корисника – и ад-хоц тестирање није изузетак. Иако се често дубље сагледава унутрашњи рад апликације, па чак и њен интерни код, ад-хоц тестери би требало да покушају да разбију овај софтвер на начине на које би корисници теоретски могли.
7. Континуирано побољшавајте процес
Тимови за тестирање треба да усаврше свој приступ ад-хоц тестирању између више итерација истог софтвера и од једног пројекта до другог.
Они могу да прикупе повратне информације од програмера да виде колико су њихови ад-хоц тестови помогли у фази обезбеђења квалитета и да ли су успели да значајно повећају покривеност тестом.
Закључак
Ад-хоц тестирање може помоћи организацијама свих врста да аутентификују своју стратегију тестирања софтвера, али начин на који примењују ову технику може бити значајан фактор у њеној ефикасности.
Балансирање различитих типова тестирања је кључ за добијање највеће користи од ад-хоц провера – посебно зато што овај облик тестирања има за циљ да допуни остале попуњавањем стратешке празнине.
Уз апликацију као што је ЗАПТЕСТ, могуће је да тимови спроводе ад-хоц тестове са већим самопоуздањем или флексибилношћу, посебно ако примењују аутоматизацију. Без обзира на специфичан приступ тима, њихова посвећеност ад-хоц тестирању могла би да револуционише цео програм или пројекат.
