Співбесіда на Manual QA перевіряє знання теорії тестування, технік тест-дизайну та вміння писати баг-репорти, з якими розробник справді може працювати. Нижче — питання, які ставлять найчастіше на рівні Junior і Middle, кожне з еталонною відповіддю. Senior: архітектуру, трейд-офи, менторство та прийняття рішень.
Спершу зʼясовуєте, де якість реально болить: говорите з підтримкою, читаєте інциденти за три місяці, питаєте розробників, що їм страшно чіпати. Потім лагодите найдешевше з найбільшим ефектом — зазвичай це смоук на критичному шляху плюс зрозумілий процес роботи з багами. Написати стратегію тестування першого тижня — класична помилка: її ніхто не прочитає, і авторитету під неї ви ще не заробили.
Перестати сперечатися про покриття і почати показувати, що прорвалося. Рахуйте дефекти, знайдені після релізу, у що вони обійшлися в часі підтримки, хотфіксах і клієнтах, що пішли, і порівнюйте з вартістю зловити їх раніше. Виграє не аргумент «нам потрібно більше тестувальників», а «ось у що нам обійшовся минулий квартал і ось скільки коштує це запобігти».
Коли фіча ще змінюється — ви лагодитимете тест частіше, ніж він вас захистить. Коли перевірка дешева для людини і дорога для машини: візуальні оцінки, юзабіліті. Коли тест нестабільний за своєю природою — тайминги, зовнішні сервіси, справжні платежі, — бо червона збірка, якій не вірять, гірша за її відсутність. Автоматизація окупається на стабільних, повторюваних і цінних шляхах, а не на всьому підряд.
Безобвинувально і про механізм, а не про людину. Відновити таймлайн, відділити тригер від причини, з якої він пройшов, і спитати, чому його пропустив кожен шар — вимоги, рев'ю, тести, оточення. На виході невелика кількість змін із власниками, а не рішення «бути уважнішими». Якщо баг того самого класу прорвався двічі, дефект у процесі, а не в тестувальнику.
Корисна метрика відповідає на питання, за яким хтось ухвалить рішення: дефекти, що втекли, час до виявлення, частка флакі, покриття критичних сценаріїв. Кількість тест-кейсів і кількість знайдених багів — класичні брехливі, бо обидві заохочують робити більше чогось замість пошуку важливого, і обидві зростають, коли якість падає. Будь-яку метрику, яку ви показуєте, почнуть оптимізувати, тому показуйте лише ті, накрутку яких ви переживете.
Не відмовою, а розміном. Назвіть конкретно, що не буде перевірено і що з цього може дійти до користувачів, їхньою мовою — виторг, навантаження на підтримку, репутація. Запропонуйте менший обсяг, який реально покриваєте, замість вдавати, що встигаєте повний. Мета в тому, щоб рішення ухвалювалося з видимим ризиком; якщо після цього випускають — це законне бізнес-рішення, і воно зафіксоване.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Senior QA Manual →