20 selective qa interview questions clear interview 2021
Најчешће постављана питања о КА интервјуу за осигурање квалитета која ће вам помоћи да се припремите за интервју:
Ево неких питања која бих поставио приликом интервјуисања инжењера за осигурање квалитета.
Питања ће више нагласити процесе квалитета и стратегију и неће се постављати за тестирање.
двоструко повезана листа ц ++
КА инжењери су углавном људи који су провели неко време у индустрији тестирања, јер када креирате мапе пута и стратегију, увек је корисно имати неку изложеност у индустрији.
Почнимо!!
Често постављана питања о КА интервјуу
Почнимо!!
П # 1) Која је разлика између осигурања квалитета, контроле квалитета и тестирања?
Одговор: Осигурање квалитета је процес планирања и дефинисања начина праћења и спровођења процеса квалитета (теста) унутар тима и организације. Ова метода дефинише и поставља стандарде квалитета пројеката.
Контрола квалитета је поступак проналажења недостатака и давања предлога за побољшање квалитета софтвера. Методе које користи Контрола квалитета обично се успостављају осигурањем квалитета. Примарна одговорност тима за тестирање је да спроведе контролу квалитета.
Тестирање је поступак проналажења недостатака / грешака. Проверава да ли софтвер који је израдио развојни тим испуњава захтеве које је поставио корисник и стандарде које је поставила организација.
Овде је главни фокус на проналажењу грешака, а тимови за тестирање раде као квалитетан вратар.
П # 2) Када мислите да КА активности треба да почну?
Одговор: КА активност би требала започети на почетку пројекта. Што раније започне, то је корисније поставити стандард за постизање квалитета.
Трошкови, време и напори су веома изазовни у случају да се КА активности одложе.
П # 3) Шта је разлика између плана и стратегије испитивања ?
Одговор: Стратегија тестирања је на вишем нивоу, углавном је креирана од стране руководиоца пројекта који демонстрира укупан приступ тестирања за цео пројекат, док план теста приказује како тестирање треба извршити за одређену апликацију која потпада под пројекат.
П # 4) Можете ли објаснити животни циклус тестирања софтвера?
Одговор: Животни циклус тестирања софтвера односи се на поступак испитивања који има одређене кораке који се изводе у одређеном низу како би се осигурало да су циљеви квалитета испуњени.
П # 5) Како дефинишете а формат писања доброг тест случаја ?
Одговор: Формат тест случаја укључује:
- ИД тест случаја
- Опис тест случаја
- Озбиљност
- Приоритет
- Животна средина
- Верзија верзије
- Кораци за извршење
- Очекивани резултати
- Стварни резултати
П # 6) Шта је добар тест случај?
Одговор: Једноставним речима, добар тест је онај који пронађе недостатак. Али сви тест случајеви неће пронаћи недостатке, па добар тест случај може бити и онај који има све прописане детаље и покривеност.
П # 7) Шта бисте урадили ако имате велики пакет за извршење за врло кратко време?
Одговор: У случају да имамо мање времена и морамо да извршимо већи обим тест случајева, требало би да дамо приоритет тест случају и прво извршимо тестове високог приоритета, а затим пређемо на ниже приоритете.
На овај начин можемо бити сигурни да су важни аспекти софтвера тестирани.
Као алтернативу, такође можемо тражити преференције купаца оно што је најважнија функција софтвера по њиховом мишљењу, и требало би да започнемо тестирање из тих области, а затим постепено пређемо на она подручја која су мање важна.
П # 8) Да ли мислите да КА такође могу да учествују у решавању производних проблема?
Одговор: Дефинитивно !! Била би добра крива учења да КА учествују у решавању производних проблема. Много проблема са производњом времена могло би се решити брисањем дневника, подешавањем неких подешавања регистра или поновним покретањем услуга.
Овакве еколошке проблеме би КА тим могао врло добро решити.
Такође, ако КА има увид у решавање проблема са производњом, они их могу укључити током писања тест случајева и на тај начин могу допринети побољшању квалитета и покушати да минимизирају производне недостатке.
П # 9) Претпоставимо да нађете грешку у производњи, како бисте били сигурни да иста грешка неће поново бити представљена?
Одговор: Најбољи начин је одмах написати тест случаја за производни недостатак и укључити га у регресиони пакет. На овај начин осигуравамо да се грешка више не уводи.
Такође, можемо смислити алтернативне тест случајеве или сличне врсте тест случајева и укључити их у планирано извршење.
П # 10) Која је разлика између функционалног и нефункционалног тестирања?
Одговор:
Функционално испитивање бави се функционалним аспектом апликације. Ова техника испитује да ли се систем понаша према захтевима и спецификацијама. Они су директно повезани са захтевима купаца. Проверавамо тест случајеве према наведеном захтеву и резултате тестова пролазимо у складу са њима.
Примери укључују регресију, интеграцију, систем, дим итд
Нефункционално испитивање , с друге стране, тестира нефункционални аспект апликације. Не фокусира се на захтеве, већ на факторе животне средине попут перформанси, оптерећења и стреса. Они нису изричито наведени у захтеву, али су прописани у стандардима квалитета. Дакле, као КА морамо бити сигурни да се и овим испитивањима даје довољно времена и приоритета.
П # 11) Шта је негативно тестирање? По чему се разликује од позитивног тестирања?
Одговор: Негативно тестирање је техника којом се потврђује да се систем понаша грациозно у случају неваљаних уноса. На пример, у случају да корисник унесе нетачне податке у оквир за текст, систем треба да прикаже исправну поруку уместо техничке поруке коју корисник не разуме.
Негативно тестирање разликује се од позитивног тестирања на начин да позитивно тестирање потврђује да наш систем ради како се очекивало и упоређује резултате теста са очекиваним резултатима.
Већина временских сценарија негативног тестирања нису наведени у документима о функционалним захтевима. Као осигурање квалитета морамо идентификовати негативне сценарије и треба да имамо одредбе за њихово тестирање.
П # 12) Како бисте били сигурни да је ваше тестирање завршено и да има добро покриће?
Одговор: Матрица сљедивости захтјева и матрице покривености теста помоћи ће нам да утврдимо да ли наши тест случајеви имају добру покривеност.
Матрица следљивости захтева помоћи ће нам да утврдимо да ли су услови испитивања довољни да буду покривени сви захтеви. Матрице покривености ће нам помоћи да утврдимо да су тест случајеви довољни да задовоље све идентификоване услове испитивања у РТМ-у.
Ан РТМ изгледаће отприлике:
Слично томе, Матрице покривености теста ће изгледати овако:
П # 13) На које се различите артефакте позивате када пишете тест случајеве?
Одговор: Главни артефакти који се користе су:
- Спецификација функционалних захтева
- Документ о разумевању захтева
- Користите случајеве
- Вирефрамес
- Приче корисника
- Кретеријум
- Много пута УАТ тестови
П # 14) Да ли сте икада успели да напишете тест случајеве без икаквих докумената?
Одговор: Да, има случајева када имамо ситуацију да морамо да пишемо тест случајеве без конкретних докумената.
У том случају, најбољи начин је:
- Сарађујте са БА и развојним тимом.
- Копајте по мејловима који имају неке информације.
- Копајте по старијим тест случајевима / регресионом пакету
- Ако је функција нова, покушајте да прочитате вики странице или помоћ апликације да бисте имали идеју
- Седите са програмером и покушајте да разумете промене које се уносе.
- На основу вашег разумевања, идентификујте стање теста и пошаљите га БА или заинтересованим странама да их прегледају.
П # 15) Шта се подразумева под Верификација и валидација ?
Одговор:
Валидација је поступак процене коначног производа ради провере да ли софтвер задовољава пословне потребе. Извршење теста које радимо у свакодневном животу је активност валидације која укључује испитивање дима, функционално испитивање, регресијско испитивање, испитивање система итд.
Верификација је процес оцењивања посредничких радних производа животног циклуса развоја софтвера како би се проверило да ли смо на правом путу стварања коначног производа.
П # 16) Које су различите технике верификације које знате?
Одговор: Технике верификације су статичне. Постоје 3 технике верификације.
Они се објашњавају на следећи начин:
(и) Преглед - Ово је метода којом код / тест случајеве испитује појединац који није аутор који га је произвео. То је један од једноставних и најбољих начина да се осигура покривеност и квалитет.
(ии) Инспекција - Ово је технички и дисциплиновани начин за испитивање и исправљање недостатака у тестном артефакту или коду. Будући да је дисциплинован, има различите улоге:
- Модератор - Омогућава читав инспекцијски састанак.
- Снимач - Биљежи записник са састанка, настале недостатке и друге расправљене тачке.
- Реадер - Прочитајте документ / код. Вођа такође води целом инспекцијском састанку.
- Продуцент - Аутор. Они су на крају одговорни за ажурирање свог документа / кода према коментарима.
- Рецензент - Сви чланови тима могу се сматрати рецензентима. Ову улогу могу играти и неке групе стручњака, а то су захтеви пројекта.
(иии) Водич за употребу - Ово је поступак у којем аутор документа / кода чита садржај и добија повратне информације. Ово је углавном врста ФИИ (Фор Иоур Информатион) сесије, а не тражење исправки.
П # 17) Која је разлика између Испитивање оптерећења и напрезања ?
Одговор:
Тестирање напрезања је техника која потврђује понашање система када се извршава под стресом. Да бисмо објаснили, смањујемо ресурсе и проверавамо понашање система. Прво разумемо горњу границу система и постепено смањујемо ресурсе и проверавамо понашање система.
У Испитивање оптерећења, валидирамо понашање система под очекиваним оптерећењем. Оптерећење може бити истовремено присуство корисника или ресурса који истовремено приступају систему.
П # 18) У случају да сумњате у свој пројекат, како приступити?
Одговор: У случају било каквих сумњи, прво покушајте да га уклоните читајући доступне артефакте / помоћ за апликацију. У случају да сумње потрају, питајте непосредног руководиоца или старијег члана вашег тима.
Пословни аналитичари такође могу бити добар избор за постављање сумњи. Такође можемо пренети своја питања са развојним тимом у случају било каквих других недоумица. Последња опција била би праћење менаџера и коначно заинтересованих страна.
П # 19) Да ли сте користили неки алат за аутоматизацију?
Одговор: Одговор на ово питање је у великој мери искључив за појединца. Одговорите на све алате и стратегије аутоматизације које сте користили у пројекту.
П # 20) Како одредити који део софтвера захтева колико тестирања?
Одговор: Овај фактор можемо знати сазнавањем Цикломатична сложеност .
Т. техника помаже да се идентификују доња 3 питања за програме / функције
- Да ли је својство / програм могуће тестирати?
- Да ли функцију / програм разумеју сви?
- Да ли је функција / програм довољно поуздана?
Као КА, можемо користити ову технику да идентификујемо „ниво“ нашег тестирања.
Пракса је да, ако је резултат цикломатске сложености већи или већи број, сматрамо да је тај део функционалности сложене природе и стога закључујемо као испитивач; да део кода / функционалности захтева детаљно тестирање.
С друге стране, ако је резултат цикломатске сложености мањи број, као КА закључујемо да је функционалност мање сложена и у складу с тим одлучујемо о опсегу.
Веома је важно разумети целокупан животни циклус тестирања и треба да буде у стању да предлаже промене у нашем процесу ако је потребно. Циљ је испорука висококвалитетног софтвера и на тај начин би КА требало да предузме све неопходне мере за побољшање процеса и начина на који тим за тестирање извршава тестове.
Надам се да ће ова питања и одговори за КА интервју помоћи да се припреми интервју за осигурање квалитета.
Препоручено читање
- Питања и одговори за интервјуе
- Нека занимљива питања за испитивање софтверског тестирања
- Питања и одговори за испитивање ЕТЛ-а
- 20 најважнијих питања и одговора за интервјуисање АПИ испитивања
- Како се припремити за интервју за тестирање софтвера
- Софтверско ручно тестирање Интервју питања за искусне професионалце
- 25 најбољих питања о агилном тестирању за интервјуе и одговоре
- 200 главних питања о интервјуу за тестирање софтвера (обавезно прочитајте да бисте очистили БИЛО КОЈИ интервју за тестирање)