QA інтерв'ю: відповіді на 14 найцікавіших питань

Успішна співбесіда є однією з запорук кар’єрного росту. Портал Software Testing Help часто публікує статті на тему проходження співбесід у сфері айті та в одній з них підсумував цікаві запитання, які може почути претендент на посаду QA-інженера.

Зразки відповідей на запитання подані читачами:

1) Яким є процес тестування на вашому проєкті?

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

Щоб краще зрозуміти процеси тестування, можете прочитати:

Процес тестування

Наскрізне тестування програмного забезпечення

2) Якими будуть ваші дії, коли немає часу на повне тестування?

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

Що робити, коли для тестування недостатньо часу?

3) Розкажіть про найкращий момент у вашій роботі?

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

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

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

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

4) Як ви вважаєте, ваш керівник чи менеджер цінує вашу роботу?

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

Натомість спробуйте згадати будь-які позитивні зауваження, які ви отримали від свого керівника, навіть якщо це просто «Хороша робота» чи «Дякую».

5)Чи шукали ви джерело проблеми для виправлення неполадок у продукті на попередній роботі?

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

6) Який найкращий модуль/найкращий продукт ви коли-небудь тестували і чому він найкращий?

Запитання, засноване на особистому досвіді, адже «найкраще» має різне значення для кожного.

Приклад відповіді: ми працювали над продуктом, випуск якого постійно відкладали (додаток до Microsoft PowerPoint, який генерував власні звіти для клієнта) і клієнт, нарешті, вирішив випустити його на ринок, тож потрібно було провести фінальне тестування. У нас не було документації, ми працювали з обмеженим бюджетом та часом, а за домовленістю з клієнтом було прийнято що кінцевий продукт не може мати більше 3-х серйозних помилок. Ми протестували цей продукт і успішно доставили його менш ніж за 30 днів.

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

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

7)Чи допомагали ви команді у напрямку ризик-менеджменту? Як, будь-який приклад?

Знову питання яке залежить від особистого досвіду. Скажіть так, якщо маєте його, чи ні, якщо ніколи не працювали з таким. Однак, коли ви говорите «Ні», обов’язково уточніть, що у вас немає практичного досвіду, але ви знайомі з теорією і розкажіть що саме ви знаєте про управління ризиками.

Більше інформації про Ризик-Менеджмент та оцінку ризиків у відео.

8) Який найбільш критичний баг ви знайшли? Якою була його критичність? Як це вплинуло на процес тестування?

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

Пріоритет — це атрибут, який вказує на черговість виконання завдання або усунення дефекту.

9) Який найкращий альтернативний шлях ви запропонували, щоб вирішити певну проблему і виконати завдання швидше, ніж заплановано та отримати більше вільного часу?

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

10) Як працювати з багами які рідко відтворюються?

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

11) Як менторити нового працівника?

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

Покращити лідерські навички та здібності ти можеш на курсі: Лідерство для Team Lead'а

12) Як покращити навички розробки тестових кейсів та забезпечити високий рівень охоплення?

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

13) Для будь-якого поля на сторінці створення облікового запису немає обмежень кількості символів. Що це означає?

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

14) Під час дослідницького тестування, ви побачили що немає опції «Забули пароль?» на логін сторінці. Як саме ви запишете цей баг?

Відповідь: Неважливо як саме ви знайшли баг, принцип створення баг-репорту залишається незмінним. Більше про Bug reports. Практичне заняття в JIRA.

Також варто переглянути 101 питання які може почути QA на співбесіді + зразки відповідей

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


Оригінал статті

Переклад Лілії Вариводи

Тестувати може кожен. Навчаємо. Розповідаємо про складне, місцями заплутане — по-простому. Надихаємо!

Практичний курс Тестування з Працевлаштуванням

Курси та події

Публікації

Відео