Меню

Софтуерно ръчно тестване Интервю въпроси за опитни професионалисти

software manual testing interview questions

Опитайте Нашия Инструмент За Премахване На Проблемите

Най-често задаваните на базата на сценарии ръчно тестване въпроси за интервю за опитни професионалисти с подробни отговори:

Наскоро имах това уникално преживяване на QA треньор (10 години опит), за да присъства на интервю за тестване на клиент с водеща компания за забавления в Лос Анджелис. Сайтът, който трябва да бъде тестван, беше прост уебсайт, насочен към клиентите (нещо като онлайн телевизионен канал), който имаше както уеб, така и мобилни компоненти.

Въпроси за интервю за софтуерно тестване

Консултантска компания проектира профили на този клиент за тестер на място + позиция на координатора но никой от тях не успя да премине през процеса на тестово интервю. Затова решиха да съберат Въпроси за QA интервю от предишните присъстващи и ми дадоха въпросник.

как да напиша добър тест

Искаха да дам отговорите на следващия кандидат и треньор човек, който да бъде успешен в тестовото QA интервю.

Ръчно тестване на въпроси за интервю за опитни

Когато получих списъка с въпроси, бях изненадан и ‘не-изненадан’ едновременно. Изненадан - защото въпросите бяха наистина основни и 10 години опитният QA трябваше да може да отговори лесно на тях. Не толкова изненадан, защото QA е сферата на ИТ, която има най-много плевели според мен - но нека не навлизаме в него.

След като приключих с упражнението, помислих, че би било хубаво да споделя този опит с читателите на STH. За начинаещи това ще бъде добра експозиция на живо. За други това ще бъде приятелско напомняне колко е важно основи са без значение колко опитни сме.

Препоръчително четене=> 101+ Тестване на софтуер Интервю Въпроси и отговори.

Ето го ...

Ръчно тестване Въпроси за интервю за опитни

9 най-често срещани QA софтуерни тестове за интервю за начинаещи, както и за опитни кандидати:

#Q 1) Какъв е процесът за създаване на тестов скрипт?

Отговор:

Етап 1: е да се получи задълбочено разбиране на AUT:

  • Това може да стане чрез четене на документите с изисквания.
  • При липса на документи можем да се опитаме да разберем всяка отправна точка, която имаме - предишна версия на приложението или телени рамки или екранни снимки

Стъпка 2: След като разберем изискванията, ние правим списък кои са областите в това приложение, които ще трябва да бъдат тествани. С други думи, ние идентифицираме изискванията на теста. Фокусът в тази стъпка е да се идентифицира „Какво“ да се тества. Резултатът от тази стъпка е списък с Тестови сценарии .

Стъпка 3: След като имаме тестовите сценарии, ние се концентрираме върху „Как“, за да ги тестваме. Тази фаза включва писане на подробни стъпки за това как да тествате определена функция, какви данни да въведете ( Данни от теста ) и какъв е очакваният резултат.

След като тези 3 стъпки са готови, ние сме готови за тестване.

#Q 2) Какви са полетата в отчета за грешки?

Отговор: Следните важни полета трябва да бъдат включени в a добър доклад за грешка :

  1. Уникален идентификационен номер
  2. Описание на дефекта: кратко описание на грешката.
  3. Стъпки за възпроизвеждане: подробности за това как да стигнем до грешката, точни данни от теста, времето, в което е открит дефект (ако е приложимо) среда: всяка информация, която ще помогне да се срещне отново проблема
  4. Модул / раздел на приложението (ако е приложимо)
  5. Тежест
  6. Екранна снимка
  7. Отговорно QA: в случай на последващи въпроси по този въпрос

#Q 3) Как да тестваме софтуер, насочен към клиентите?

Отговор: С всяко приложение, което тестваме, ние се опитваме да видим дали даден набор от изисквания отговаря на приложението или не. Но когато става въпрос за сайт, ориентиран към потребителя, освен да се концентрираме върху функционалността, ние също трябва да разгледаме няколко функции за използваемост, може би аспекти на производителността и сигурността също до известна степен.

Първото ниво на тестване е : Удовлетворява ли сайтът своите функционални изисквания.

Например, ако това е сайт за управление на заеми, трябва да разгледаме - дали новият клиент е в състояние да кандидатства за кредит, дали съществуващият клиент има достъп до информацията си за кредит, правилно ли е% лихвата, приложен към сумата на кредита и т.н.

Следващото ниво на тестване е :колко лесно е да използвате сайта, имат ли опциите логичен смисъл и отговарят ли на очакванията на потребителя или не.

кое от следните е пример за извличане на данни

Например, ако потребителят трябва да премине 3-4 екрана, за да подаде основната информация, той ще бъде раздразнен, така че такива проблеми трябва да бъдат разгледани.

Друг пример, след въвеждане на потребителско име и парола потребителят може да щракне върху раздела - което означава, че контролата трябва да отиде на бутона „Вход“, вместо това, ако ще се отмени, потребителят ще бъде наистина раздразнен и опитът от използването на сайта е ще бъде компрометиран. Такива проблеми трябва да бъдат уловени.

Тестване на производителността в пълна степен може да не е в обхвата, но прости ситуации като, колко време отнема резултатите от търсенето, за да се покажат и колко време отнема на системата да извлече информация за клиент в пиковия час - това са някои примери за неща, които бихме искали да държим под око.

Сигурност - за сайтове, където има защитен вход за достъп до сайта, трябва да се тества минималната функционалност около него. Например, ако оставя сайта неактивен за повече от 10 минути, автоматично излизане ли е или не. Нещо толкова основно, колкото това трябва да се фокусира.

#Q 4) Как да преодолеем предизвикателството да нямаме входна документация за тестване?

Отговор: АКО подробната стандартна документация като BRD и FSD не е налична, тестерът ще трябва да зависи от някаква отправна точка.

  • Снимки на екрана
  • Предишна версия на приложението
  • Рамки и др

Друг фактор, който помага изключително много, е да разговаряме с разработчиците или бизнес анализаторите (когато има такива), за да получим потвърждение за нашето разбиране или разяснения в случай на съмнения.

Когато нито една от тези ситуации не работи, можем просто да концептуализираме приложението въз основа на предишния ни опит в ИТ приложенията и да създадем основния набор от тестови скриптове. Когато настъпи фазата на тестване, можем да настроим част от времето на тестовия цикъл и да направим известно управление на тестовите случаи (да направим вече създадените скриптове перфектни), за да имаме документацията за следващите фази.

#Q 5) Как да стигнем максимална производителност от офшорни отбори?

Отговор: Ключът е да се уверите, че всички тестери знаят за всички модули и че няма концентрация на знания на едно място. Включването на всички в партньорски проверки на тестови скриптове, дефектни срещи и KT сесии ще гарантира, че всеки е запознат с приложението във възможно най-добрата степен.

Също така, насърчавайки концепцията за работа в екип, можем да накараме членовете на екипа да си сътрудничат, да си помагат и да си помагат за по-добра производителност.

Редовните последващи срещи също много помагат на процеса.

#Q 6) Какви са ролите и отговорностите на координатора на място? Тества ли и той / тя?

Отговор: Координаторът на място е контактна точка за офшорния екип и за клиента за всяка информация относно ангажимента за тестване.

Тази работа включва:

  • KT от и до офшорни и клиенти
  • Подготовка на средата за тестване на всички
  • Проверка на здравословното състояние, изпитване на дим
  • Тестване - ключовата функционалност.
  • Преглед на грешки - открит от офшорния екип
  • Присвояване на грешки на съответната разработка
  • Представяне на метрики
  • Предоставяне на подписване

Да, дори локален координатор трябва да тества.

#Q 7) Несъгласувани грешки - Защо на място може да го намери, но офшорните не могат и обратно - Как да се справим с тази ситуация?

Отговор: Всяка грешка трябва да бъде отбелязана и анализирана - независимо дали се среща на място или в офшорка, независимо дали е повторяема или не. Истинска добавена стойност към работата на тестера е, когато се включим в процеса на анализ на основната причина за грешка, а не просто да я докладваме.

Някои от начините, по които можем да се справим с тази ситуация, са:

  • Всички местни и офшорни членове на екипа трябва да следват насоки, според които трябва да се правят скрийншотове за всяка грешка, която срещнем - повторяема или не.
  • Ако има регистрационни файлове, системни файлове или нещо подобно, това може да ни помогне да намерим доказателства за проблема - трябва да се опитаме да го намерим.
  • Въпреки всички тези стъпки, ако все още не можем да разберем защо и кога възниква проблемът, трябва все пак да докладваме на разработчика - с възможно най-много информация.

#Q 8) Тестване, свързано с видео / аудио - Какво включва това?

Отговор: Как да тествате приложение с видео или аудио?

Ето важните моменти, които трябва да имате предвид:

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

#Q 9) ​​Тестване на мобилни приложения - Какво включва за кратко?

Отговор: Тестване на мобилни приложения Важни сценарии за тестване:

  • Проверете дали приложението работи добре с множество оператори и множество устройства.
  • Използваемост на функциите на мобилен екран.
  • Тествайте го на различни мобилни платформи - като Android и iOS.
  • Инсталации, деинсталиране, стартиране на приложението с мрежа и без мрежа, тестване на функционалност.
  • Мрежови връзки - Wi-Fi, 2G и др.
  • Дневниците в помощната програма за конфигуриране на iOS iPhone за Android Monitor.bat могат да се използват за отстраняване на грешки.

Това беше. Сега не беше толкова просто.

Като последна бележка повтарям философията в STH - познавайте добре основите, останалото автоматично следва.

В заключение се надявам, че тези усилия ще бъдат полезни и значими за нашите читатели. Моля, уведомете ни по-долу в раздела за коментари за това как се справихме.

как да отворите .eps файлове

Автор: Тази публикация е написана от нашия член на екипа на STH Swati Seela.

Препоръчително четене

^