Мени

Софтверско ручно тестирање Интервју питања за искусне професионалце

software manual testing interview questions

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

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

Недавно сам доживео ово јединствено искуство КА цоацхинг (10 година искуства) да присуствује интервјуу са клијентом за тестирање софтвера са водећом компанијом за забаву у Лос Ангелесу. Веб локација која се тестирала била је једноставна веб локација окренута купцима (некако попут мрежног ТВ канала) која је имала и веб и мобилне компоненте.

Питања за интервју са софтверским приручником за тестирање

Консултантска компанија је пројектувала профиле овом клијенту за испитивач на лицу места + позиција координатора али нико од њих није прошао кроз процес интервјуа за тестирање. Зато су одлучили да сакупе Питања за КА интервју од претходних полазника и дали су ми упитник.

најбољи софтвер за копирање ДВД-а на чврсти диск

Желели су да одговорим следећем кандидату и да то тренирам особа која ће бити успешна у тестирању КА интервјуа.

Питања за ручно тестирање интервјуа за искусне

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

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

Препоручено читање=> 101+ Питања и одговори за испитивање софтвера.

Ево ...

Ручно тестирање Интервју питања за искусне

9 најчешћих питања о КА испитивању софтвера за интервјуе за почетнике као и за искусне кандидате:

#К 1) Који је поступак за креирање тест скрипте?

Одговор:

Корак 1: је да се темељно разуме АУТ:

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

Корак 2: Након разумевања захтева, правимо списак подручја у овој апликацији која ће морати да се тестирају. Другим речима, идентификујемо захтеве за испитивање. Фокус у овом кораку је идентификовање „Шта“ за тестирање. Исход овог корака је листа Тест сценарији .

Корак 3: Једном када имамо сценарије тестирања, концентришемо се на „Како“ да их тестирамо. Ова фаза укључује писање детаљних корака о томе како тестирати одређену карактеристику, које податке унети ( Тест подаци ) и који је очекивани резултат.

Када обавимо ова 3 корака, спремни смо за тестирање.

#К 2) Која су поља у извештају о грешкама?

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

  1. Јединствена лична карта
  2. Опис дефекта: кратки опис шта је грешка.
  3. Кораци до репродукције: детаљи о томе како доћи до грешке, тачни подаци о тестирању, време у којем је пронађена неисправност (ако је применљиво) окружење: све информације које ће вам помоћи да поново наиђете на проблем
  4. Модул / одељак апликације (ако је применљиво)
  5. Озбиљност
  6. Снимак екрана
  7. Одговорно КА: у случају било каквих додатних питања у вези са овим питањем

#К 3) Како тестирати софтвер окренут купцу?

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

Први ниво тестирања је : Да ли локација задовољава своје функционалне захтеве.

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

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

На пример, ако корисник мора да прође 3-4 екрана да би предао основне информације, он ће бити изнервиран, па се такви проблеми морају решавати.

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

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

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

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

Одговор: АКО детаљна стандардна документација попут БРД и ФСД није доступна, испитивач ће морати да зависи од неке референтне тачке.

како отворити кмл датотеке у ворд-у
  • Снимке екрана
  • Претходна верзија апликације
  • Жичани оквири итд

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

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

#К 5) Како доћи максимална продуктивност из офшор тима?

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

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

Редовни накнадни састанци такође веома помажу процесу.

#К 6) Које су улоге и одговорности координатора на лицу места? Да ли и он / она тестира?

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

Овај посао укључује:

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

Да, чак и локални координатор мора да тестира.

#К 7) Неконзистентне грешке - Зашто их онсите може пронаћи, а оффсхоре не може и обрнуто - Како се носити са овом ситуацијом?

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

Неки од начина на које можемо да решимо ову ситуацију су:

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

#К 8) Тестирање повезано са видео / аудио - Шта ово укључује?

Одговор: Како тестирати апликацију која има видео или аудио?

алгоритам стабла одлучивања у рударству података

Ево важних тачака које треба узети у обзир:

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

#К 9) Тестирање мобилних апликација - Шта укључује накратко?

Одговор: Тестирање мобилних апликација Важни сценарији теста:

  • Проверите да ли апликација добро функционише са више носача и више уређаја.
  • Корисност функција на мобилном екрану.
  • Тестирајте га на различитим мобилним платформама - попут Андроид-а и иОС-а.
  • Инсталације, деинсталација, покретање апликације са мрежом и без мреже, тестирање функционалности.
  • Мрежне везе - Ви-Фи, 2Г итд.
  • Евиденције у услужном програму за конфигурацију иОС-а иПхоне за Андроид Монитор.бат могу се користити за отклањање грешака.

То је било то. Сада то није било тако једноставно.

За крај, понављам филозофију СТХ - добро познајте основе, остало аутоматски следи.

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

Аутор: Овај пост је написао члан нашег СТХ тима Свати Сеела.

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

^