40+ популарних тестова за КА аналитичаре Интервју са питањима и одговорима [2021 ЛИСТ]

40 popular test qa analyst interview questions

Питања и одговори за интервју са аналитичаром теста / осигурања квалитета који се најчешће постављају:

Док одлучујете о каријери у којој желите бити, одлучујући фактор није само онај за који мислите да може уживати у раду.

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

Иако се горе поменуте особине не постижу тренутно, очигледно је потребно и искуство и дани напорног рада.

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

Популарна питања о интервјуу за аналитичаре КА теста

П # 1) Које су одговорности КА аналитичара?

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

Главне одговорности КА аналитичара могу се навести на следећи начин:

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

П # 2) Какво је ваше разумевање у вези са планом теста?

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

План испитивања је евиденција процеса који укључују:

• Задаци тестирања
• Окружје за тестирање
• Технике дизајна
• Критеријуми за улазак и излазак
• Било који ризик итд.

3. питање: Наведите приоритет задатака тестирања дефинисаних од стране КА тима у развоју производа.

Одговор: Приоритет задатака тестирања дефинисан је на следећи начин:

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

П # 4) Наведите неке од кључних изазова са којима се суочавају током тестирања софтвера.

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

У наставку је наведено неколико кључних изазова:

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

П # 5) Дефинишите тестирање случајева употребе.

Одговор: Усе Цасе тестирање може се дефинисати као функционална техника тестирања црне кутије која бележи низ интеракција које су се догодиле између „актера“ и „система“. Овде „глумце“ представљају корисници и њихове интеракције.

Карактеристике испитивања случаја употребе наведене су у наставку:

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

П # 6) Дефинишите стратегију испитивања.

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

Прате се различити приступи испитивању засновани на факторима попут природе и домена производа, ризика од неуспеха производа, стручности у раду са предложеним алатима итд.

Ови приступи су даље категорисани на следећи начин:

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

П # 7) Објасните разлику између контроле квалитета и осигурања квалитета.

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

Хајде да схватимо разлику уз помоћ доње табеле.

П # 8) Према вама, када је право време за покретање КА у пројекту?

Одговор: Према животном циклусу развоја софтвера (СДЛЦ), фаза тестирања се извршава након завршетка фазе „Имплементација и кодирање“. Али у данашњем сценарију, за постизање најбољих резултата, потребно је започети КА пројекта или производа на почетку пројекта.

Слеђење овог приступа ће довести до главних предности датих у наставку:

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

П # 9) Разликовање процеса верификације и валидације.

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

Да видимо другу разлику између ова два процеса у доњој табели:

П # 10) Објасните предности деструктивног испитивања.

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

У наставку су наведене предности деструктивног испитивања:

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

П # 11) По чему се тестирање разликује од тестирања регресије?

Одговор: Постоји неколико разлика између поновног тестирања и тестирања регресије.

То се лако може разумети из доње табеле:

П # 12) Шта знате о тестирању на основу података?

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

Тестирање на основу података долази овде у слику, где желимо да апликација ради како се очекује за било коју врсту улазних вредности. У ту сврху подаци потребни за тестирање на основу података нису кодирани, али тест скрипте узимају своје податке из извора података као што су ЦСВ датотеке, ОДБЦ извори итд.

Да резимирамо, тестирање на основу података изводи следеће радње у петљи:

• Узима податке пробних података из меморије.
• Подаци унети у апликацију за обављање радњи.
• Проверите стварне резултате са очекиваним.
• Поновите исте кораке са новим улазним тест подацима.

П # 13) Шта је матрица сљедивости? Да ли је потребно за сваки пројекат?

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

Матрица сљедивости захтјева састоји се од доље наведених параметара који су заправо према документу о спецификацији захтјева.

Параметри матрице сљедивости захтјева укључују:

• Сваки одељак документа о захтеву је тачка коју треба обрадити у РТМ (Матрица следљивости захтева).
• Наслов сваке тачке је наслов сваког одељка у спецификацији захтева.
• Одговарајући свакој тачки, помињу се ИД-ови тест случајева који су написани за тај одређени одељак.
• БУГ / ИД нове функције је такође наведен у сваком одељку.
• Најважнија ствар је да се одржава и праћење функције у којој је имплементирана изградња пројекта и његове карактеристике.
• Други параметар укључује да ли је одељак у потпуности тестиран или је још увек у статусу тестирања.

П # 14) Опишите предности агилног тестирања.

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

У наставку су наведене предности агилног тестирања:

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

П # 15) Шта је негативно тестирање?

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

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

П # 16) Разликовање ад-хоц тестирања и истраживачког тестирања?

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

Погледајмо разлике у доњој табели:

П # 17) Зашто је аутоматско тестирање пожељније од ручног?

Одговор: Па, и аутоматизовано тестирање и ручно тестирање имају свој значај и постојање у свету тестирања.

У наставку су дати неки важни аспекти због којих се аутоматизацијско тестирање даје предност над ручним:

назив оперативног система у рачунару

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

Иако још неки фактори одређују да се аутоматизацијским тестовима даје предност над ручним. Горе поменути су главни фактори.

П # 18) Шта разумете под појмом „ефикасност теста“ и „ефикасност теста“?

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

То се може утврдити формулом:

Ефикасност теста = (Број отклоњених недостатака / укупан број пријављених недостатака) * 100

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

То се може утврдити формулом:

Учинковитост теста = (Број пронађених недостатака / Број извршених тест случајева)

П # 19) Објасните процес кројења пројеката.

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

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

Неколико аспеката према организационим циљевима у оквиру процеса кројења су:

• Пројектни приступ
• Стратегије
• Укључене контроле и процеси
• Улоге и одговорности

П # 20) Како разликујете приоритет и тежину квара у пројекту?

Одговор: И „Приоритет“ и „Озбиљност“ додељени су грешци за категоризацију проблема / грешака по редоследу којим ће се узимати ради исправљања. Они се заснивају на разним факторима.

Да схватимо више заједно са њиховим разликама у доњој табели:

П # 21) Зашто је за било коју апликацију потребно извршити тестирање перформанси?

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

Разлози за тестирање перформанси могу се разумети из следећих тачака:

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

П # 22) Шта је тестирање на основу спецификација?

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

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

П # 23) Објасните ЦММИ.

Одговор: ЦММИ је скраћеница од Интеграција модела зрелости способности. Овај модел је развио Институт за софтверско инжењерство (СЕИ). Заснован је на принципу да процеси укључени у управљање и развој производа или система одређују квалитет.

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

ЦММИ је подељен на 5 нивоа како је наведено у наставку:

• Ниво 1: Инитиал
• Ниво 2: Манагед
• Ниво 3: Дефинисано
• Ниво 4: Квантитативно управљано
• Ниво 5: Оптимизовано

П # 24) Објасните предности примене ЦММИ.

Одговор: Постоји неколико предности примене ЦММИ.

Они су наведени на следећи начин:

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

П # 25) Наведите неке алате за тестирање аутоматизације.

Одговор: Неки од алата за тестирање аутоматизације наведени су у наставку:

• Селен
• воде
• Ветрењача
• САПУН
• Телур

П # 26) Да ли можемо да извршимо регресијско тестирање у јединственом тестирању?

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

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

К # 27) Која је разлика између тестирања дима и испитивања здраве исправности?

Одговор:

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

К # 28) Које су ваше дневне активности ручног испитивача у вашој канцеларији?

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

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

К # 29) Које су ваше свакодневне активности као члана тестера аутоматизације у вашој канцеларији?

Аутоматизација: Мој дан започиње дневним састанком о статусу који расправља о јучерашњим резултатима аутоматизације, у случају да сам испалио серију тест случајева на новој верзији.

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

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

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

П # 30) Како разликујете захтев и недостатак од побољшања?

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

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

К # 31) Шта радите када ваш програмер негира исправљање грешке коју сте пријавили?

Одговор : Важан фактор који одлучује о отклањању квара је „Приоритет“ који му је додељен. Ако је квар високог приоритета, приказни чеп, који блокира главну функционалност и непрекидно се репродукује, тада је потребно поправити га у изради.

Исто се мора ефикасно пренети програмерима, јер заједно тестери и програмери доприносе квалитету производа који се испоручује.

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

К # 32) Шта радите када ваш програмер порекне да је оно што сте поднели ГРЕШКА?

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

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

К # 33) Шта је прво Поновно тестирање или Регресијско тестирање?

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

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

К # 34) Шта је алтернатива бета тестирању?

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

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

К # 35) Који су недостаци Агиле имплементације / методологије са којом сте се суочили?

Одговор : Недостаци су следећи:

1. Спринт је обично ограничен крајњим роком.
2. Документација није приоритет
3. Пребацивање између ПБИ-а (ставки заосталих производа) може бити често.

К # 36) Зашто је анализа утицаја важна?

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

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

К # 37) Уз помоћ примера сваког испитивања перформанси, испитивања напрезања и испитивања оптерећења?

Одговор : Најбољи случај који овде можемо предузети је веб локација уживо.

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

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

Стрес тестирање је врста испитивања перформанси која се изводи стављањем софтвера у екстремне услове (велика и нераспоређена оптерећења, ограничени рачунски ресурси, велика истовременост).

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

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

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

На пример, време за преузимање расположивих места за воз се постепено повећава када се приближи време резервације Таткал квоте, јер се број корисника који су тада пријављени у систем повећава са временом резервације Таткал које се приближава 10 или 11 сати.

К # 38) Шта је био један од ваших највећих изазова током регресијског тестирања?

Одговор : Током извођења регресивног тестирања могу бити различити изазови.

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

К # 39) Ако се од вас затражи да документујете сценарије тестирања, случајеве испитивања, планове испитивања, стратегију тестирања, са чим ћете почети и којим редоследом ће следити остало?

Одговор : Редослед ће бити Стратегија тестирања, План испитивања, Сценарији тестирања и коначно Тест случајеви.

К # 40) Шта ако пропустим да документујем било шта од наведеног? Рецимо да ми недостаје документовање плана испитивања које ће бити последице?

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

К # 41) Како бисте започели тестирање верзије коју сте недавно добили: Да ли постоји неки приступ који следите нпр. прво започните тестирање дима, а затим тестирање здраве памети?

Одговор : Испитивање дима> Испитивање исправности> Истраживачко испитивање> Испитивање функционалности> Испитивање регресије и валидација финалног производа.

К # 42) Објасните формат извештаја о грешкама који сте пратили?

Одговор :

Извештај о грешци треба да садржи следеће информације:

• Ид грешке
• Мапирање према захтеву / побољшању / постојећој грешци
• Резиме грешке / наслов
• Верзија производа
• Приоритет
• Конфигурација (системске спецификације)
• Предуслови
• Кораци
• Очекивани исход
• Стварни исход
• Трупци. Снимке, видео клипови
• Статус
• Остале примедбе

К # 43) Како одабирете случајеве регресионих тестова или формирате пакет за регресијски тест?

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

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

К # 44) Можете ли добити пример следећих недостатака

• Квар високе тежине ниског приоритета
• Квар високог приоритета и мале тежине

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

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

К # 45) Напишите један ефикасан тест случај да бисте тестирали да ли је дати папир бели папир?

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

Белешка: Постоји много других одговора на ово питање. Можете смислити било који такав валидан одговор са основном логиком.

К # 46) Шта је Цхартер тестирање?

Одговор: Тестирање сесије изведено на основу циљева и агенде наведених у повељи пре почетка тестирања познато је као тестирање повеље.

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

К # 47) Какав је ваш приступ када имате издање високог приоритета које треба да буде испоручено у врло кратком времену?

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

Следеће се може учинити као помоћ у тестирању у сценарију недостатка времена: -

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

К # 48) Написати тест случајеве на било који уређај / предмет присутан у околини (Пример: столица)?

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

У овом случају:-

• Каква је врста столице? Канцеларијска столица, радна столица, столица на софи, трпезаријски сто, столица за удобност?
• Од ког се материјала израђује столица - дрво, челик, пластика, тапацирунг?
• Распитајте се за димензије (висина, тежина на основу врсте столице).
• Питајте за доступност. И на основу тога започните са израдом својих случајева.

Тест случајеви би се разликовали за сваку врсту столице, што је боље оставити за вашу способност размишљања ( На пример, намена столице, димензије према врсти столице, преносни-не-за пиће, лагани, опције куповине).

За сваку столицу, а Случај теста перформанси може бити: да се добије затезна чврстоћа или максимална носивост.

К # 49) Може ли се све аутоматизовати?

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

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

Закључак

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

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

Хвала и сретно са интервјуима!

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

• Интервјуирајте питања и одговоре
• 25+ најпопуларнијих питања и одговора за интервју за АДО.НЕТ
• 25 најбољих агилних тестова за интервју и питања и одговори
• Споцк интервју питања са одговорима (најпопуларније)
• Питања и одговори за испитивање ЕТЛ-а
• 20 најпопуларнијих питања и одговора у интервјуу за ТестНГ
• Топ 30+ популарних питања и одговора за интервју са краставцима
• Топ 50 најпопуларнијих питања и одговора за интервју са ЦЦНА