СтП: Практика 8

Практика 8

Открыто: Thursday, 16 December 2021, 14:56

Срок сдачи: Tuesday, 28 December 2021, 14:56

Кейс 1. Побудуйте технічне інтерв’ю з кандидатом на відповідну посаду, користуючись наступним:

Познайомитися з кандидатом особисто, з’ясувати ступінь зацікавленості в роботі. Оцінити готовність у зміні місця праці. Дізнатися, чи підходить він компанії, чи зуміє виконувати посадові обов’язки. Реально порівняти претендентів між собою.
Уточнити деталі, які залишилися нез’ясованими після прочитання резюме або анкети. Зіставити отриману різними шляхами інформацію.
З’ясувати ступінь відповідності майбутнього співробітника займаній посаді, співставити, оцінити минулі успіхи і досягнення.
Оцінити особистісні якості людини: харизму, характер, здібності, чесність, дізнатися цінності, бачення й ідеали,
Презентувати свою ІТ компанію з усіма плюсами роботи в ній (за мінуси звісно Вам будуть мовчати). Повідомити про обов’язки, описати особливості адаптації та її терміни.
З’ясувати, наскільки збігаються очікування сторін. А якщо вони відрізняються, то як саме? Досвідчений HR намагатиметься знайти спільний знаменник та дійти до компромісу.
Дати можливість кандидату зрозуміти, чи дійсно йому потрібна ця робота?
Визначити, наскільки комунікабельною є людина, чи зможе вона влитися в колектив.
Дати людям можливість висловити свої побажання і думки з того чи іншого питання.
Поговорити про перспективи кар’єрного зростання.
Виявити які проблеми можуть виникнути в майбутньому. Зрозуміти причини, за якими майбутні співробітники не задоволені попередньою роботою, звільняються і т. п.

Приклад QA інтерв'ю

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стратегія працевлаштування

Практика 8

Top Software Testing Interview Questions