40+ Популярні тестові запитання та відповіді на запитання аналітика (2021 СПИСОК)

40 popular test qa analyst interview questions

Запитання та відповіді на питання співбесіди, які найчастіше задають аналітики тестування / забезпечення якості:

Вирішуючи кар’єру, якою ви хочете стати, вирішальним фактором є не тільки той, над яким, на вашу думку, може сподобатися працювати.

Але потрапляння до цієї категорії вимагає багато навичок, розуміння відповідальності, а також необхідних службових обов’язків для обраної вами кар’єри. Те саме стосується вибору професії аналітика з контролю якості. Це вимагає не тільки хорошого тестувача, швидкого навчання, надзвичайного мислителя, але також вимагає вирішення складних проблем.

Незважаючи на те, що вищезазначені якості не досягаються миттєво, очевидно, що це вимагає досвіду та днів напруженої роботи.

Ця стаття висвітлить усі аспекти, знання яких є обов’язковим для роботи аналітика з контролю якості. Запитання та відповіді на інтерв’ю, які найчастіше задаються аналітиком QA, дадуть вам чітке уявлення про підготовку співбесіди.

Популярні запитання співбесіди аналітика QA

Питання 1) Які обов'язки аналітика з контролю якості?

Відповідь: Аналітик контролю якості - це той, хто гарантує, що були вжиті всі можливі заходи для тестування кожної функції програмного рішення як функціонально, так і технічно.

Основні обов'язки аналітика з контролю якості можуть бути перелічені наступним чином:

• Виконувати та керувати всіма діями для досягнення цілей плану випробувань.
• Виберіть процеси високої якості для розробки продукту.
• Повинна аналізувати вимоги та оформлювати документи.
• Задокументуйте та перевірте всі дефекти. Встановіть пріоритет і тяжкість дефектів.
• Вони повинні мати можливість створювати, документувати та вести тестові кейси.
• Аналіз результатів випробувань.

Q # 2) Яке ваше розуміння щодо плану тестування?

Відповідь: Коли ви чітко уявляєте, що, коли, як і хто, тоді справи стають простішими. Те саме стосується і тестування програмного забезпечення, де план тестування - це документ, що складається із обсягу, підходу, ресурсів та конспекту проекту тестування, а також діяльності з відстеження прогресу проекту.

План випробувань - це запис процесів, які включають:

• Тестові завдання
• Середовище тестування
• Техніка проектування
• Критерії входу та виїзду
• Будь-які ризики тощо.

Запитання №3) Вкажіть пріоритет завдань тестування, визначених командою контролю якості при розробці продукту.

Відповідь: Пріоритет завдань тестування визначається наступним чином:

• Готується план випробувань, що складається із схеми та обсягу проекту випробувань.
• Тестові кейси підготовлені для охоплення всіх основних та другорядних функціональних можливостей даними, необхідними для тестування.
• Виконання тестових кейсів відповідно до функціональних можливостей, реалізованих з наступними збірками проекту тестування в циклі тестування.
• Звітування про дефекти з повторною перевіркою, а також відстеження його прогресу.
• Підготовка підсумкового звіту про виконання тесту.

Q # 4) Перелічіть деякі ключові проблеми, з якими стикаються під час проведення тестування програмного забезпечення.

Відповідь: Оскільки ми говоримо, що повного тестування ніколи неможливо досягти, у ньому є кілька проблем. Будь то невеликий чи складний, є деякі проблеми, з якими стикається тестування програмного забезпечення будь-якого проекту.

Нижче наведено кілька ключових проблем:

• Відсутність кваліфікованого тестувальника, який зазвичай стикається з проблемою обізнаності суб’єкта, а також недостатня кількість знань про бізнес замовника.
• Час також розглядається як фактор, оскільки зазвичай тестувальники зосереджуються головним чином на охопленні завдань, а не на випробуванні за допомогою тестування якості, коли існує величезний перелік завдань, які потрібно виконати.
• Вирішити, який тестовий випадок слід виконати першим і з пріоритетом. Зазвичай це досягається досвідом роботи.
• Правильне розуміння вимог, які можуть спричинити до нуля всі ваші зусилля щодо тестування, якщо вимога неправильно зрозуміла.
• Недоступність найкращих інструментів, необхідних для завершення тестування з меншим часом та більшою ефективністю.
• Управління стосунками між тестувальниками та розробниками з хорошими навичками спілкування та аналізу.

Q # 5) Визначте тестування випадків використання.

Відповідь: Тестування Case Use можна визначити як функціональну техніку тестування чорної скриньки, яка фіксує низку взаємодій, що відбулися між «акторами» та «системою». Тут „актори” представлені користувачами та їх взаємодією.

Характеристики тестування випадків використання наведені нижче:

• Функціональні вимоги проекту організовані.
• Записує шлях або сценарії від початку до кінця.
• Може охоплювати дефекти інтеграції, тобто дефекти, що виникли в результаті взаємодії між різними компонентами.
• Він описує основні потоки, а також винятковий потік подій.
• Будь-які попередні умови, необхідні для роботи випадку використання, повинні бути вказані раніше.

Q # 6) Визначте стратегію тестування.

Відповідь: Набір керівних принципів або підходів до тестування, які зазвичай виконує керівник проекту для визначення проекту тестування та загального підходу до тестування, визначається як Тестова стратегія. Він знаходиться як невеликий розділ плану випробувань і використовується у кількох проектах.

Дотримуються різних підходів до тестування, заснованих на таких факторах, як природа та область виробництва, ризик виходу з ладу, досвід роботи з запропонованими інструментами тощо.

Ці підходи далі класифікуються наступним чином:

• Проактивний підхід , де підхід до тестового проектування починається до створення збірки. Таким чином, це допомагає знайти та виправити помилки перед збіркою.
• Реактивний підхід , де підхід до тестування розпочинається після завершення проектування та кодування випробувань.

Q # 7) Поясніть різницю між контролем якості та забезпеченням якості.

Відповідь: 'Контроль якості' і 'Гарантія якості' це два основні терміни, що використовуються стосовно будь-якого проекту випробування чи продукту. Зазвичай тестери, які не є новими в цій галузі, не розуміють фактичної різниці між ними.

Давайте зрозуміємо різницю за допомогою таблиці нижче.

Q # 8) Як ви вважаєте, коли настав час розпочати перевірку якості в проекті?

Відповідь: Відповідно до Життєвого циклу розробки програмного забезпечення (SDLC), фаза тестування виконується після завершення фази «Впровадження та кодування». Але в сьогоднішньому сценарії для досягнення найкращих результатів необхідно розпочати перевірку якості проекту або продукту на початку проекту.

Дотримання цього підходу призведе до основних переваг, наведених нижче:

• Раннє планування процесу, щоб задовольнити очікування замовника.
• Гарне та здорове спілкування між командами.
• Дає достатньо часу, необхідного для налаштування середовища тестування.
• Дозволяє ранню перевірку та затвердження планів випробувань.

Q # 9) Диференціюйте процеси перевірки та перевірки.

Відповідь: Процеси перевірки та перевірки зазвичай визначаються двома відомими питаннями, тобто ' Ми правильно будуємо систему? ' і 'Ми будуємо правильну систему?' .

Давайте побачимо іншу різницю між цими двома процесами в таблиці нижче:

Q # 10) Поясніть переваги руйнівного контролю.

Відповідь: Випробування на руйнування визначається як форма випробувань, яку проводить команда випробувань, щоб визначити точку руйнування виробу при різних навантаженнях, тобто для оцінки конструктивних характеристик застосування, щоб визначити його міцність, в'язкість, твердість або сказати міцність.

Нижче перераховані переваги руйнівного контролю:

• Визначено слабкість дизайну програми.
• Визначте термін служби програми.
• Це допомагає зменшити витрати та невдачі.

Q # 11) Чим тестування відрізняється від тестування на регресію?

Відповідь: Існує кілька відмінностей між повторним тестуванням та тестуванням на регресію.

Це легко зрозуміти з таблиці нижче:

Q # 12) Що ви знаєте про тестування на основі даних?

Відповідь: Кожному тестувальнику автоматики дуже ясно, що сценарії тестування автоматизації охоплюють лише область програми, що перевіряється, із записаною послідовністю дій користувача. Зазвичай ці дії не призводять до помилок, оскільки лише вхідні дані беруться за умов, які ми ввели під час запису.

Тестування, кероване даними, вступає в картину тут, де ми хочемо, щоб програма працювала належним чином для будь-якого типу вхідних значень. Для цього дані, необхідні для тестування на основі даних, не кодуються жорстко, але тестові скрипти беруть свої дані з джерел даних, таких як файли CSV, джерела ODBC тощо.

Підводячи підсумок, тестування на основі даних виконує такі дії в циклі:

найкращий блокувальник реклами для mac chrome -

• Бере вхідні дані тесту з сховища.
• Дані, що вводяться в заявку для виконання дій.
• Перевірте фактичні результати з очікуваними.
• Знову повторіть ті самі дії з новими вхідними тестовими даними.

Q # 13) Що таке матриця простежуваності? Це потрібно для кожного проекту?

Відповідь: Матриця простежуваності в будь-якому проекті - це засіб відстеження прогресу проекту щодо впровадження нових функціональних можливостей, вдосконалення існуючих функціональних можливостей тощо. Завдяки матриці простежуваності ви завжди можете стежити за прогресом проекту з кожним аспектом, який підтримується відповідно до Дата.

Матриця простежуваності вимог складається із зазначених нижче параметрів, які насправді відповідають документу специфікації вимог.

Параметри матриці простежуваності вимог включають:

• Кожен розділ документа з вимогами є пунктом, який повинен охоплювати RTM (матриця простежуваності вимог).
• Заголовок кожного пункту - це заголовок кожного розділу в специфікації вимог.
• Відповідно до кожного пункту згадуються ідентифікатори тестових кейсів, які написані для цього конкретного розділу.
• ПОМИЛКА / Ідентифікатор нової функції також згадується в кожному розділі.
• Найважливішим моментом є те, що відстеження об’єкта також підтримується, в якому реалізована збірка проекту та його особливість.
• Інший параметр включає, чи розділ повністю протестований, чи все ще перебуває у стані тестування.

Q # 14) Опишіть переваги гнучкого тестування.

Відповідь: Будучи випробувачем, основна увага стає доставкою якісного продукту за менший час, розуміючи вимоги кінцевого споживача, а головне, відсутність дефектів з боку кінцевого користувача. Тут тестування Agile представлене на малюнку, який відповідає принципу гнучкої розробки програмного забезпечення та швидко підтверджує вимоги клієнта.

Нижче згадані переваги тестування Agile:

• У тестування включається багатофункціональна спритна команда, яка, у свою чергу, забезпечує результати через часті інтервали.
• Економить багато часу та грошей.
• Включає менше документації та час від часу відгуки кінцевого користувача.
• Не тільки тестувальник, але і вся команда, включаючи менеджера, замовника та розробника, бере участь у спілкуванні віч-на-віч.
• В результаті щоденних зустрічей питання можна чітко визначити заздалегідь.
• Збільшення продуктивності команди та краще розуміння технічних аспектів проекту.

Q # 15) Що таке негативне тестування?

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

Ця форма тестування також відома як 'Тестування на відмову' або 'тестування на помилку' і його основною метою є перевірка надійності функції програми за негативних сценаріїв. Він також виявляє слабкість програмного забезпечення, виявляє несправності та дає чітке уявлення про пошкодження даних.

Q # 16) Диференціювати спеціальне тестування та пошукове тестування?

Відповідь: Існує кілька відмінностей між тимчасовим та дослідницьким тестуванням.

Давайте побачимо відмінності в таблиці нижче:

Q # 17) Чому тестуванню автоматизації віддають перевагу перед тестуванням вручну?

Відповідь: Ну, і автоматичне тестування, і ручне тестування мають своє значення і існують у світі тестування.

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

• Один і той же сценарій тесту можна використовувати щоразу для запуску тесту, тому тестування автоматизації вважається найбільш надійним та ефективним.
• Переважно переважно у разі регресійного тестування та повторного виконання.
• Тестування автоматизації вважається економічно вигідним у разі тривалого виконання, що забезпечує кращу якість програмного забезпечення.
• Тестові сценарії можна використовувати багаторазово, швидко, і кожен може бачити результати.
• Інструменти, що використовуються для автоматичного тестування, є більш швидкими та надійними порівняно з ручним підходом.

Хоча ще деякі фактори визначають, що тестуванню автоматизації надають перевагу перед тестуванням вручну. Вищезазначені є основними факторами.

Q # 18) Що ви розумієте під поняттями 'Ефективність тесту' та 'Ефективність тесту'?

Відповідь: Ефективність тесту може бути визначено як обчислення кількості ресурсів і тестового коду, що споживаються для виконання або сказування виконання певної функції. Він також визначає кількість ресурсів, використаних при створенні програмного продукту.

Це можна визначити за формулою:

Ефективність тесту = (Кількість усунутих дефектів / загальна кількість поданих дефектів) * 100

Ефективність тесту можна визначити як міру оцінки тестового середовища та його впливу на програмне забезпечення. Тут відгук замовника оцінюється, коли вимога заявки виконана.

Це можна визначити за формулою:

Ефективність тесту = (Кількість виявлених дефектів / Кількість виконаних тестів)

Q # 19) Поясніть процес пошиття проектів.

Відповідь: Пошиття проектів - це послідовний і постійний процес, який гарантує правильність виконання проекту та його відповідність вимогам бізнесу. Весь процес включає перегляд та модифікацію проектних даних відповідно до поточних операційних потреб організації.

Процес перегляду здійснюється на організаційному рівні, але реалізація адаптаційних планів здійснюється на рівні проекту. Основною метою та вимогами організації, а також взаємовідносинами із клієнтами та користувачами є два основні фактори, які слід враховувати в процесі.

Кілька аспектів, що відповідають організаційним цілям у процесі пошиття, це:

• Проектний підхід
• Стратегії
• Засоби управління та процеси
• Ролі та обов'язки

Запитання №20) Як розрізнити пріоритет та важкість дефекту в рамках проекту?

Відповідь: І 'Пріоритет', і 'Серйозність' присвоюються помилці для класифікації проблем / помилок у порядку, в якому вони повинні бути прийняті для виправлення. Вони базуються на різних факторах.

Давайте зрозуміємо більше разом із їх відмінностями в таблиці нижче:

Q # 21) Чому для будь-якої програми необхідно проводити тестування продуктивності?

Відповідь: Простою мовою тестування продуктивності проводиться для визначення поведінки та реакції програми в різних ситуаціях. Це допомагає збирати інформацію про стабільність програми, масштабованість, швидкість тощо.

Причини проведення тестування продуктивності можна зрозуміти з наведених нижче пунктів:

• Він визначає час відгуку та продуктивність компонента програми під робочим навантаженням.
• Розраховується час відгуку на активність користувача.
• Потрібні досвідчені програмісти з розгалуженою технічною мовою.
• Визначає поведінку програми під навантаженням, тобто коли кількість користувачів миттєво збільшується.

Q # 22) Що таке тестування на основі специфікацій?

Відповідь: Як випливає з назви, тестування на основі специфікацій проводиться на основі специфікації вимог програми, де функціональні специфікації служать основою проведених тестів.

Ця форма тестування така ж, як і «тестування чорної скриньки», коли користувач вводить кілька даних, а потім спостерігається результат. Це доцільно на всіх рівнях випробувань із специфікацією та планом випробувань.

Q # 23) Поясніть CMMI.

Відповідь: CMMI розшифровується як інтеграція моделі зрілості можливостей. Ця модель була розроблена Інститутом програмного забезпечення (SEI). Він базується на принципі, що процеси, що беруть участь в управлінні та розробці продукту чи системи, визначають якість.

Він також містить вказівки щодо вдосконалення процесу для товару або навіть для всієї організації.

CMMI розділений на 5 рівнів, як зазначено нижче:

• Рівень 1: Початковий
• Рівень 2: Керований
• Рівень 3: Визначений
• Рівень 4: Кількісно керований
• Рівень 5: Оптимізовано

Q # 24) Поясніть переваги впровадження CMMI.

Відповідь: Існує кілька переваг впровадження CMMI.

Вони перелічені наступним чином:

• Він забезпечує детальне висвітлення та звітування про життєвий цикл товару і, таким чином, допомагає у вдосконаленні процесу.
• Існуючі стандарти організації, їх процеси та процедури вдосконалюються як частина впровадження CMMI.
• В результаті впровадження CMMI спостерігається збільшення своєчасної доставки, а також задоволеності споживачів.
• Це також призводить до ефективного управління та збільшення економії коштів, оскільки раннє виявлення помилок відбувається.

Q # 25) Залучіть деякі засоби автоматизації тестування.

Відповідь: Деякі засоби автоматизації тестування перелічені нижче:

• Селен
• води
• Вітряк
• МИЛО
• Теллур

Q # 26) Чи можемо ми зробити регресійне тестування в модульному тестуванні?

Відповідь: Безумовно. Регресійне тестування полягає у тестуванні небажаного дефекту, який міг бути введений в код як побічний ефект виправлення інших дефектів. Модульне тестування - це тестове виконання запуску невеликої незалежної та окремої частини коду.

Регресійне тестування можна проводити на будь-якому рівні, починаючи від модульного тестування, закінчуючи інтеграційним тестуванням і закінчуючи прийнятним тестуванням. Регресійне тестування - це тестування на основі перспективи, тоді як модульне тестування - це підхід рівня (знизу вгору, зверху вниз).

Q # 27) У чому різниця між тестуванням на дим та тестуванням на розум?

Відповідь:

• Тестування на дим - це тестування старих відомих особливостей або існуючих особливостей збірки, тоді як тестування Sanity - це перевірка нещодавно доданих модулів, виправлених дефектів у збірці.
• Спочатку відбувається тестування на дим, а потім - тестування на розум.
• Тестування на дим охоплює тестування важливих функціональних можливостей, забезпечених програмним забезпеченням, тому воно поширюється на все програмне забезпечення. З іншого боку, перевірка розумності звужується лише до нещодавно доданих модулів і перевіряється поглиблено.

Q # 28) Якою є ваша щоденна робота в якості ручного тестера у вашому офісі?

Довідник: Перше, що я перевіряю у своїй системі, - це оновити інформаційну панель для стану вимог / удосконалень чи помилок у поточній ітерації. Далі слідують щоденні дзвінки та звітування, обговорення та мозковий штурм для визначення сценаріїв тестування та тестових випадків.

Потім ці справи виконуються після переробки їх відповідно до огляду. Зв'язок з клієнтами щодо нефункціональних вимог - також одне з основних напрямків моєї роботи.

Q # 29) Яка ваша щоденна діяльність у складі тестера автоматизації у вашому офісі?

Автоматизація: Мій день починається з щоденної зустрічі про стан, на якій обговорюються вчорашні результати автоматизації, на випадок, якщо я випустив пакет тестових випадків для нової збірки.

Цикл виконання можна назвати перевіркою працездатності, щоб побачити, наскільки здоровою є збірка.

Потім слід повідомляти про дефекти на основі несправностей сценарію, зміни дизайну функціональних можливостей; підтримувати сценарії / бібліотеки або функції, автоматизувати та реєструватись у новому сценарії для нових вимог і, якщо потрібно, нову функцію у бібліотеці функцій.

Іноді тестові скрипти потрібно повторно виконувати окремо, щоб знайти дефекти регресії за допомогою автоматизації та також додати їх до набору тестів.

Q # 30) Як розрізнити вимогу від дефекту та вдосконалення?

Відповідь : ДО вимога це історія користувача, яка є важливою для впровадження, тестування та доставки.
Ан вдосконалення - це додана або імпровізована функція до існуючої.
ДО дефект швидше є повним відхиленням від очікуваних історій користувачів.

Крім того, якщо дефект виявляє певну область вимоги, яка не зазначена, якщо інше не зазначено в специфікації, це також може бути названо вимогою або її частиною.

Q # 31) Що ви робите, коли ваш розробник заперечує виправлення вашої помилки?

Відповідь : Важливим фактором, який вирішує проблему виправлення дефекту, є 'Пріоритет', призначений йому. Якщо дефект має високий пріоритет, показ пробки, яка блокує основну функціональність і послідовно відтворюється, тоді її потрібно виправити у збірці.

Те саме слід донести до розробників ефективно, оскільки разом тестувальники та розробники сприяють підвищенню якості товару, що відвантажується.

Іншими аспектами, які можуть допомогти переконати розробника виправити помилку протягом короткого періоду, є якісне звітування про помилку та змушення розробників зрозуміти той факт, що виправлення помилки має першочергове значення у випуску.

Q # 32) Що ви робите, коли ваш розробник заперечує, що те, що ви подали, є помилкою?

Відповідь : Найважливішою фазою життєвого циклу дефекту є 'Відхилено', що означає, що зареєстрований звіт про інцидент не є дійсним. Документ про бізнес-вимоги, в якому зазначаються вимоги, може допомогти зрозуміти програмне забезпечення, а отже і характер інциденту, про який повідомляється.

Проаналізуйте помилку та розкрийте її висновки щодо розробника та команди. Якщо це дефект, ніколи не реєструйте його. Іноді тестерам доводиться проводити аналіз прогалин і представляти те ж саме розробникам. Якщо це не вирішує конфлікти, тоді старші люди в команді повинні вступити.

Q # 33) Що спочатку повторне тестування або регресійне тестування?

Відповідь : Повторне тестування є першим, оскільки воно повторно запускає код, простіше кажучи, це повторне виконання заздалегідь визначених кроків. Це не повинно бути необхідним після виправлення коду. Але регресійний тест - це оцінка побічних ефектів вирішеного дефекту.

Звичайно, вирішення одного дефекту та додавання іншого в код не є метою процесу тестування. Найкращі знахідки та найкращий улов тестувальників - це, як правило, дефекти регресії. Збірка ніколи не повинна випускатися без перевірки регресії.

Q # 34) Що є альтернативою бета-тестуванню?

Відповідь : Бета-тестування проводиться на сайті клієнта з найменшим залученням розробників, фіксуючи збої в реальному виробничому середовищі. Якщо така практика не проводиться фірмою, то більш безпечною ідеєю може бути доставка товару спочатку тим клієнтам, які не в черзі, щоб отримати останню версію.

Протягом декількох днів певні консультанти з обслуговування клієнтів можуть використовувати програмне забезпечення, реєструвати та контролювати діяльність, що забезпечує стабільність випуску в їх середовищі, так що навіть якщо серйозна помилка залишається для виправлення, вона може бути протестована перед доставляючи його цільовому клієнту. Іншим підходом є замінене тестування вимог у команді на неупереджене тестування.

Q # 35) Які недоліки реалізації / методології Agile вам доводилось стикатися?

Відповідь : Недоліки такі:

1. Спринти зазвичай дуже обмежені.
2. Документація не є пріоритетом
3. Переключення між PBI (елементи відставання товару) може бути частим.

Q # 36) Чому аналіз впливу важливий?

Відповідь : Для практики на основі оцінки ризиків необхідно провести аналіз впливу. Завдяки цьому тестові випадки можуть бути розроблені таким чином, щоб усі серйозні помилки, критичні з точки зору замовника, могли бути вирішені до часу. Слід подбати про гарне вивчення бізнесу, потреб клієнта та використання ними програмного забезпечення.

Наприклад, найважливішим ризиком, пов'язаним із програмним забезпеченням у банківській області, є безпека. Будь-яка нова форма, додана до вже існуючого програмного забезпечення, може бути вразливою. Бажано перевірити безпеку, додавши відповідні посилання, переспрямування та навігацію до відповідної сторінки, встановивши проксі-сервер за необхідності.

Q # 37) За допомогою прикладу кожне тестування продуктивності, стрес-тестування та тестування навантаження?

Відповідь : Найкращий випадок, який тут можна взяти, - це веб-сайт у реальному часі.

Тестування продуктивності виконується для перевірки збоїв у системі при переведенні в стан, подібний до сценарію реального часу. Не потрібно проводити в напружених умовах. Результати тестування продуктивності допомагають встановити, чи готова система до запуску у виробництво.

Для простого процесу бронювання квитків проблема продуктивності могла спричинити повільність. Наприклад, деякі запити з використанням об’єднань є дещо повільнішими, що застосували непотрібні пропозиції або зберігання даних неналежним чином у базі даних.

Стрес-тестування - це тип перевірки продуктивності, який проводиться шляхом встановлення програмного забезпечення в екстремальних умовах (великі та нерозподілені навантаження, обмежені обчислювальні ресурси, висока паралельність).

Якщо система виявляє певну поведінку, як-от втрачені або пошкоджені дані, ресурс, який використовується навіть після зняття стресу, безвідповідальність або не оброблені винятки, це означає, що вона не виконала стрес-тестування. Іноді наслідком може бути збій диска, непотрібне збільшення кількості GDI.

Наприклад, Якщо веб-сайт, розміщений на машині, яка вже споживає величезну пам'ять або бомбардує її повторними запитами, не повинен зависати або виходити з системи.

Тестування навантаження спостерігає за поведінкою системи, постійно збільшуючи навантаження на систему до досягнення порогового значення. Моделі навантаження, показники та рівні навантаження, як правило, є вхідними даними для тестування навантаження.

Наприклад, час отримання місць для поїзда поступово збільшується, коли час бронювання квитків Tatkal наближається, оскільки кількість користувачів, що ввійшли в систему, збільшується із часом бронювання Tatkal до 10 ранку або 11 ранку.

Q # 38) Що було одним із ваших найбільших випробувань під час проведення регресійного тестування?

Відповідь : Під час проведення регресійного тестування можуть виникати різні проблеми.

• Повторне повторне тестування може стати не таким цікавим для тестувальників.
• Займає багато часу, оскільки іноді таке тестування потребує нестандартного мислення.
• Компрометована цінність бізнесу.
• Неправильний вибір випадків регресійних тестів може пропустити значний дефект регресії.
• Відтворення дефекту на виробництві, отже, стає непослідовним.
• Великий люкс для виконання.

Q # 39) Якщо вас попросять задокументувати сценарії тестування, тестові кейси, плани тестування, стратегію тестування, з чого ви почнете і в якій послідовності дотримуватиметься решта?

Відповідь : Послідовністю буде Тестова стратегія, План випробувань, Сценарії випробувань і, нарешті, Тестові кейси.

Q # 40) Що робити, якщо я пропускаю документування будь-якого із перерахованих вище? Скажімо, я пропускаю документування плану тестування, які будуть наслідки?

Відповідь : Якщо ми пропустимо документування плану тестування, буде недійсним обсяг тестування, його об'єктивний підхід та акцент на тестуванні. Тоді буде важко визначити особливості, що підлягають тестуванню, методики тестування, проходження або невдачі критеріїв і, зрештою, великий ризик, пов'язаний з тестуванням.

Q # 41) Як би ви почали тестувати збірку, яку нещодавно отримали: чи є якийсь підхід, якого ви дотримуєтесь, наприклад спочатку розпочати тестування на дим, потім тестування на розум?

Відповідь : Тестування диму> Тестування на розумність> Дослідницьке тестування> Тестування функціональності> Регресійне тестування та перевірка кінцевого продукту.

Q # 42) Поясніть формат звіту про помилки, якого ви дотримувались?

Відповідь :

Звіт про помилку повинен містити таку інформацію:

• Ідентифікатор помилки
• Прив'язка до вимоги / вдосконалення / наявної помилки
• Короткий зміст помилки / заголовок
• Версія продукту
• Пріоритет
• Конфігурація (технічні характеристики системи)
• Передумови
• Кроки
• Очікуваний результат
• Фактичний результат
• Журнали. Знімки, відеокліпи
• Статус
• Інші зауваження

Q # 43) Як ви обираєте тести регресії або формуєте набір тестів регресії?

Відповідь : Так. Це результат аналізу впливу. Це просте відображення функцій, які використовуються або доступні в різних областях, які ви тестуєте, їх інтеграція з іншими функціями, а також як тестування системи від кінця до кінця або потоку.

Ви також можете виявити дефекти, раніше подані для тієї самої функціональності в попередніх збірках. В ідеалі, один дефект повинен бути перевірений на регресію з використанням принаймні п'яти різних тестових випадків, що використовують цю функціональність.

Q # 44) Чи можете ви навести приклад таких дефектів

• Дефект високої серйозності низького пріоритету
• Дефект високого пріоритету та низької тяжкості

Відповідь : Дефектом, який призводить до аварійного завершення роботи програми при відтворенні лише в певний час на певній операційній системі, може бути дефектом високої серйозності та низьким пріоритетом.

Дефект, поданий проти подання, яке не відкривається подвійним клацанням, а відкривається клацанням правою кнопкою миші, може бути дефектом високого пріоритету та низької серйозності.

Q # 45) Напишіть один ефективний тестовий приклад, щоб перевірити, чи є даний папір білим папером?

Відповідь: Якщо колір вихідного чорнила, яким ви пишете на білому папері, залишається незмінним, тоді папір білий. Наприклад, якщо ви пишете на білому папері червоним чорнилом, колір чорнила залишається червоним у ручці, а також відображається червоним на папері.

Примітка: Є багато інших відповідей на це питання. Ви можете придумати будь-яку таку слушну відповідь із базовою логікою.

Q # 46) Що таке тестування статуту?

Відповідь: Сесійне тестування, проведене на основі цілей та порядку денного, перелічених у статуті до початку тестування, називається тестуванням Хартії.

Тестування тут проводиться у фіксованому часовому інтервалі з меншим акцентом на документацію та більшим фокусом на просто тестуванні. Це інший варіант дослідницьких випробувань, коли інженери-випробувачі перевіряють програмне забезпечення в часові рамки ( Наприклад, всього 2 години) на основі певної евристики, розробленої.

Q # 47) Який ваш підхід, коли у вас є пріоритетний випуск, який буде доставлений за дуже короткий час?

Відповідь: У таких випадках продуманий план може бути корисним.

Для сприяння тестуванню за сценарієм дефіциту часу можна зробити наступне: -

• Використання існуючих оновлених сценаріїв автоматизації для виконання регресійного тестування.
• Тестування сценаріїв, що базуються на потоці, наскрізні.
• Виконання тестів з високим пріоритетом, і якщо це дозволяє час, перейдіть на випадки з нижчим пріоритетом.
• Повторне тестування високопріоритетних помилок, поданих у попередніх версіях.
• Швидке тестування програмного забезпечення
• Розробників можна попросити запустити модульні тести, щоб отримати більше охоплення тестуванням.

Q # 48) Написати тестові кейси на будь-який пристрій / предмет, що знаходиться навколо (Приклад: стілець)?

Відповідь: Порада тут буде такою: Завжди починайте зі збору вимог. Це показує вашу зрілість до життєвого циклу розробки програмного забезпечення. Не соромтеся задавати питання після вибору об’єкта.

В цьому випадку:-

• Що це за стілець? Офісне крісло, робочий стіл, диванний стілець, обідній стіл, зручне крісло?
• З якого матеріалу виготовляється стілець - дерево, сталь, пластик, оббивка?
• Запитайте про розміри (зріст, вага залежно від типу стільця).
• Запитайте про наявність. І на основі цього починайте складати свої справи.

Тестові кейси можуть відрізнятися для кожного типу стільця, що краще залишити для вашого мислення ( Наприклад, призначення стільця, розміри відповідно до типу стільця, переносний-непридатний для пиття, легкий, варіанти придбання).

Для кожного стільця, a Тестом на продуктивність може бути: щоб отримати міцність на розрив або максимальну несучу здатність.

Q # 49) Чи можна все автоматизувати?

Відповідь: - Певною мірою так. Але засоби автоматизації, як і інше програмне забезпечення, мають свої обмеження. Крім того, тестоване програмне забезпечення або тестоване програмне забезпечення буде постійно оновлюватися.

Тому немає гарантії, що тестування програмного забезпечення може виконуватися без втручання вручну. Зрештою, інструмент такий же розумний, як і тестер. Це просто тестування програмного забезпечення ще одне програмне забезпечення. Це код / ​​скрипти / бібліотеки, які повинні бути достатньо розумними для тестування та пошуку дефектів.

Висновок

Сподіваємось, ця вправа допоможе вам розігрітися з кількома запитаннями та дасть вам чудовий початок для співбесід та покращить вашу впевненість, відповідаючи на запитання. Крім того, можуть бути й інші запитання на основі сценарію, які можуть з’явитися у вашому резюме / профілі.

Отже, завжди доцільно практикувати фіктивне співбесіду самостійно, щоб співбесіда виявилася безпрограшною і для інтерв’юера, і для кандидата. Пам’ятайте, що аналітик якості - це більше, ніж інженер-випробувач, відгуки якого важливі не тільки для якості продукту, але й для процесу тестування програмного забезпечення.

Дякуємо та бажаємо успіхів в інтерв’ю!

Рекомендована література

• Запитання та відповіді на інтерв’ю
• 25+ Найпопулярніші запитання та відповіді на інтерв’ю ADO.NET
• 25 найкращих запитань та відповідей на інтерв’ю для спритного тестування
• Запитання для інтерв’ю з Spock (найпопулярніші)
• Запитання та відповіді на інтерв’ю для тестування ETL
• 20 найпопулярніших запитань та відповідей на інтерв’ю TestNG
• 30 найкращих запитань та відповідей на інтерв’ю з огірками
• 50 найпопулярніших запитань та відповідей на інтерв’ю CCNA