20 selective qa interview questions clear interview 2021
Запитання та відповіді на питання QA щодо забезпечення якості, які найчастіше задають, щоб допомогти вам підготуватися до співбесіди:
Ось деякі запитання, які я б поставив, коли брав інтерв’ю у інженера із забезпечення якості.
У запитаннях більше буде наголошено на процесах якості та стратегії, і вони не будуть задаватися для тестування.
Інженери QA - це, в основному, люди, які провели певний час у тестовій галузі, тому що коли ви створюєте дорожні карти та стратегію, завжди вигідно мати певний вплив на галузь.
Давайте розпочнемо!!
Найчастіші запитання щодо інтерв’ю з якості
Давайте розпочнемо!!
Q # 1) Яка різниця між забезпеченням якості, контролем якості та тестуванням?
Відповідь: Забезпечення якості - це процес планування та визначення способу моніторингу та впровадження процесів якості (тестування) в команді та організації. Цей метод визначає та встановлює стандарти якості проектів.
Контроль якості - це процес виявлення дефектів та надання пропозицій щодо покращення якості програмного забезпечення. Методи, які використовує Контроль якості, зазвичай встановлюються системою забезпечення якості. Запровадження контролю якості - це головний обов’язок групи тестування.
Тестування - це процес пошуку дефектів / помилок. Він перевіряє, чи відповідає програмне забезпечення, розроблене командою розробників, вимогам, встановленим користувачем, та стандартам, встановленим організацією.
Тут основна увага приділяється пошуку помилок, а групи тестування працюють якісним воротарем.
Q # 2) Коли, на вашу думку, слід розпочати діяльність з контролю якості?
Відповідь: Діяльність із забезпечення якості повинна розпочатися на початку проекту. Чим раніше починається, тим вигідніше встановлювати стандарти для досягнення якості.
Вартість, час та зусилля є дуже складними у випадку, якщо діяльність із забезпечення якості затримується.
Q # 3) Що таке різниця між планом випробувань та стратегією випробувань ?
Відповідь: Стратегія тестування знаходиться на вищому рівні, в основному створена менеджером проекту, який демонструє загальний підхід тестування для всього проекту, тоді як план тестування показує, як тестування повинно проводитись для певної програми, яка підпадає під проект.
Q # 4) Чи можете ви пояснити життєвий цикл тестування програмного забезпечення?
Відповідь: Життєвий цикл тестування програмного забезпечення відноситься до процесу тестування, який має конкретні кроки, які слід виконати у визначеній послідовності, щоб забезпечити досягнення цілей щодо якості.
Q # 5) Як ви визначаєте a формат написання хорошого тесту ?
Відповідь: Формат тестового кейсу включає:
- Ідентифікатор тестового кейсу
- Опис тестового кейсу
- Серйозність
- Пріоритет
- Навколишнє середовище
- Версія збірки
- Кроки для виконання
- Очікувані результати
- Фактичні результати
Q # 6) Що таке хороший тест?
Відповідь: Простими словами, хорошим тестом є той, який виявляє дефект. Але всі тести не виявлять дефектів, тому хорошим тестом може бути також той, який має всі встановлені деталі та охоплення.
Q # 7) Що б ви зробили, якщо у вас є великий набір для виконання за дуже короткий час?
Відповідь: Якщо у нас менше часу, і нам доводиться виконувати більший обсяг тестових кейсів, нам слід сформулювати пріоритет тесту та виконати спочатку тести з високим пріоритетом, а потім перейти до нижчих пріоритетів.
Таким чином ми можемо забезпечити тестування важливих аспектів програмного забезпечення.
Крім того, ми можемо також шукати переваги споживача щодо того, що є найважливішою функцією програмного забезпечення на їх думку, і нам слід розпочати тестування з тих областей, а потім поступово переходити до тих областей, які мають меншу важливість.
Q # 8) Чи вважаєте ви, що QA також може брати участь у вирішенні виробничих проблем?
Відповідь: Безумовно!! Для QA було б гарною кривою навчання брати участь у вирішенні виробничих питань. Багато проблем із виробництвом часу можна вирішити, очистивши журнали, ввівши деякі налаштування реєстру або перезапустивши служби.
Команда контролю якості може дуже добре вирішити подібні екологічні проблеми.
Крім того, якщо QA має розуміння вирішення виробничих проблем, вони можуть включити їх під час написання тестових кейсів, і таким чином вони можуть сприяти підвищенню якості та намагатися мінімізувати виробничі дефекти.
Q # 9) Припустимо, ви знайдете помилку у виробництві, як би ви переконались, що та сама помилка не буде повторно представлена?
Відповідь: Найкращий спосіб - негайно написати тест на виробничий дефект і включити його до набору регресій. Таким чином ми гарантуємо, що помилка не з’являється знову.
Крім того, ми можемо придумати альтернативні тестові кейси або подібні види тестових кейсів і включити їх до нашого запланованого виконання.
Q # 10) Яка різниця між функціональним та нефункціональним тестуванням?
Відповідь:
Функціональне тестування має справу з функціональним аспектом програми. Ця методика перевіряє поведінку системи відповідно до вимог та специфікацій. Вони безпосередньо пов’язані з вимогами замовника. Ми перевіряємо тестові випадки на відповідність зазначеним вимогам і робимо результати тесту відповідними або успішними.
Приклади включають регресію, інтеграцію, систему, дим тощо
Нефункціональне тестування , з іншого боку, перевіряє нефункціональний аспект програми. Він зосереджується не на потребі, а на факторах навколишнього середовища, таких як продуктивність, навантаження та стрес. Вони прямо не зазначені у вимозі, але прописані у стандартах якості. Отже, як QA ми повинні переконатися, що цим тестуванням також надається достатньо часу та пріоритету.
Q # 11) Що таке негативне тестування? Чим воно відрізняється від позитивного тестування?
Відповідь: Негативне тестування - це техніка, яка підтверджує, що система поводиться витончено у випадку будь-яких недійсних входів. Наприклад, у випадку, якщо користувач вводить якісь недійсні дані у текстове поле, система повинна відображати належне повідомлення замість технічного повідомлення, яке користувач не розуміє.
Негативне тестування відрізняється від позитивного тестування таким чином, що позитивне тестування підтверджує, що наша система працює належним чином, і порівнює результати тестування з очікуваними результатами.
Більшість часових сценаріїв негативного тестування не згадуються в документах щодо функціональних вимог. Як контроль якості ми маємо виявити негативні сценарії і повинні мати положення для їх перевірки.
Q # 12) Як би ви переконались, що ваше тестування завершено та має гарне охоплення?
Відповідь: Матриця простежуваності вимог та матриці охоплення тестів допоможуть нам визначити, що наші тестові випадки мають гарне покриття.
Матриця простежуваності вимог допоможе нам визначити, що умов тестування достатньо, щоб охопити всі вимоги. Матриці покриття допоможуть нам визначити, що тестових випадків достатньо, щоб задовольнити всі визначені умови тестування в RTM.
Ан RTM буде виглядати приблизно так:
Так само, Тестові матриці покриття виглядатимуть так:
Q # 13) На які різні артефакти ви посилаєтесь, коли пишете тестові кейси?
Відповідь: Основні використані артефакти:
- Специфікація функціональних вимог
- Документ про розуміння вимог
- Використовуйте кейси
- Каркасні дроти
- Історії користувачів
- Критерії приймання
- Багато разів тести UAT
Q # 14) Чи вдалося вам коли-небудь писати тестові кейси, не маючи жодних документів?
Відповідь: Так, бувають випадки, коли ми маємо ситуацію, коли нам доводиться писати тестові кейси, не маючи жодних конкретних документів.
В такому разі, найкращий спосіб:
- Співпрацюйте з BA та командою розробників.
- Копайте в листах, де є якась інформація.
- Копайте у старих тестових випадках / наборі регресії
- Якщо функція нова, спробуйте прочитати вікі-сторінки або довідку програми, щоб отримати ідею
- Посидьте з розробником і спробуйте зрозуміти внесені зміни.
- Виходячи з вашого розуміння, визначте стан тестування та надішліть його BA або зацікавленим сторонам для перегляду.
Q # 15) Що мається на увазі під Перевірка та перевірка ?
Відповідь:
Перевірка - це процес оцінки кінцевого продукту, щоб перевірити, чи відповідає програмне забезпечення комерційним потребам. Виконання тесту, яке ми виконуємо у своєму повсякденному житті, - це перевірка діяльності, яка включає тестування диму, функціональне тестування, регресійне тестування, тестування систем тощо.
Перевірка - це процес оцінки посередницьких робочих продуктів життєвого циклу розробки програмного забезпечення, щоб перевірити, чи правильно ми рухаємося до створення кінцевого продукту.
Q # 16) Які різні методи перевірки ви знаєте?
Відповідь: Методи перевірки є статичними. Існує 3 методи перевірки.
Це пояснюється наступним чином:
(i) Огляд - Це метод, за допомогою якого код / тестові кейси розглядає особа, крім автора, який його створив. Це один із найпростіших та найкращих способів забезпечити покриття та якість.
як використовувати .jar файли -
(ii) Інспекція - Це технічний та дисциплінований спосіб вивчити та виправити дефекти тестового артефакту чи коду. Оскільки він дисциплінований, він має різні ролі:
- Модератор - Сприяє проведенню всієї інспекційної наради.
- Рекордер - Записує протокол засідання, дефекти та інші обговорені моменти.
- Читач - Прочитайте документ / код. Керівник також веде на всю інспекційну нараду.
- Виробник - Автор. Вони несуть відповідальність за оновлення свого документа / коду відповідно до коментарів.
- Рецензент - Усі члени команди можуть вважатися рецензентами. Цю роль також може зіграти якась група експертів, що вимагає проекту.
(iii) Покрокове керівництво - Це процес, коли автор документа / коду читає зміст і отримує відгук. Це здебільшого своєрідна сесія FYI (для вашої інформації), а не пошук виправлень.
Q # 17) Яка різниця між Випробування на навантаження та стрес ?
Відповідь:
Стрес-тестування це техніка, яка перевіряє поведінку системи, коли вона працює під напругою. Для пояснення ми зменшуємо ресурси та перевіряємо поведінку системи. Спочатку ми розуміємо верхню межу системи і поступово зменшуємо ресурси та перевіряємо поведінку системи.
В Тестування навантаження, ми перевіряємо поведінку системи за очікуваного навантаження. Навантаженням може бути одночасний доступ користувачів або ресурсів до системи одночасно.
Q # 18) Якщо у вас є якісь сумніви щодо вашого проекту, як ви підходите?
Відповідь: У разі будь-яких сумнівів спершу спробуйте його очистити, прочитавши доступні артефакти / довідку щодо програми. У разі сумнівів, які зберігаються, попросіть безпосереднього керівника або старшого члена вашої команди.
Бізнес-аналітики також можуть бути хорошим вибором, щоб задати сумніви. Ми також можемо передати наші запити команді розробників у разі будь-яких інших сумнівів. Останнім варіантом буде зв’язок з менеджером і, нарешті, з зацікавленими сторонами.
Q # 19) Чи використовували ви якісь засоби автоматизації?
Відповідь: Відповідь на це питання є дуже винятковою для особистості. Дайте відповідь на всі інструменти та стратегії автоматизації, які ви використовували у своєму проекті.
Q # 20) Як ви визначаєте, яка частина програмного забезпечення вимагає скільки тестування?
Відповідь: Ми можемо дізнатися цей фактор, з’ясувавши Цикломатична складність .
Т Ця техніка допомагає визначити нижче 3 запитання щодо програм / функцій
- Чи перевіряється функція / програма?
- Чи зрозуміла функція / програма всім?
- Чи є функція / програма достатньо надійною?
Як QA, ми можемо використовувати цю техніку, щоб визначити “рівень” нашого тестування.
Практично, якщо результат цикломатичної складності більший чи більший, ми вважаємо цю частину функцій складною, і тому робимо висновок як тестувальника; що шматок коду / функціональності вимагає поглибленого тестування.
З іншого боку, якщо результатом Цикломатичної Складності є менша кількість, ми робимо висновок як QA, що функціональність менш складна, і відповідно визначаємо сферу застосування.
Дуже важливо зрозуміти весь життєвий цикл тестування та, за необхідності, запропонувати зміни в нашому процесі. Мета - поставити високоякісне програмне забезпечення, і таким чином перевірка якості повинна вжити всіх необхідних заходів для вдосконалення процесу та способу виконання тестуванням команди тестування.
Сподіваюся, ці запитання та відповіді на співбесіду допоможуть підготувати інтерв’ю із забезпечення якості.
Рекомендована література
- Запитання та відповіді на інтерв’ю
- Деякі цікаві запитання щодо тестування програмного забезпечення
- Запитання та відповіді на інтерв’ю для тестування ETL
- 20 найважливіших запитань та відповідей на тестування API
- Як підготуватися до співбесіди з тестування програмного забезпечення
- Тестування запитів на інтерв’ю для досвідчених професіоналів
- 25 найкращих запитань та відповідей на інтерв’ю для спритного тестування
- Найпопулярніші 200 запитань щодо тестування програмного забезпечення (Обов’язково прочитайте, щоб очистити БУДЬ-ЯКЕ тестове інтерв’ю)