Ситуаційні питання — Manual QA

Вимог немає або вони неповні. Що робиш?

Зібрати, що є: тікет, макети, переписка, схожі фічі, поведінка конкурентів, Swagger.
Скласти список питань і закритих припущень і пройти їх з PM чи аналітиком.
Записати домовленості в тікет — це і є вимоги.
Тестувати на основі ризиків і досвіду, позначаючи, які очікування — мої припущення.

На співбесіді: Я збираю все, що є: тікет, макети, переписку, Swagger, схожі фічі. Складаю список питань і своїх припущень і проходжу його з PM, а домовленості фіксую в тікеті. Паралельно тестую на основі ризиків, позначаючи, де очікуваний результат — моє припущення.

Реліз завтра, а часу на повне тестування немає. Що робиш?

Пріоритизувати за ризиком: що змінилося, що найкритичніше для бізнесу, де найчастіше ламалося.
Тестувати в такому порядку: зміни релізу → критичні сценарії (гроші, логін) → решта регресії.
Прозоро повідомити, що протестовано, а що ні, і які ризики.
Рішення про реліз приймає команда й бізнес, а QA дає інформацію для цього рішення.

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

Користувачі знайшли критичний баг на проді. Твої дії?

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

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

Як протестуєш форму логіну?

Позитивні: валідні дані, «запам'ятати мене», вхід після logout.

Негативні: невірний пароль, неіснуючий email, порожні поля, пробіли, неправильний формат, регістр email.

Безпека: блокування після N невдалих спроб, однакове повідомлення для невірного логіну і пароля (щоб не розкривати, які email існують), пароль замаскований і не в URL, HTTPS, SQL-ін'єкції й XSS у полях, сесія закінчується після бездіяльності.

Інше: Enter замість кліку, автозаповнення браузера, кілька вкладок, «Назад» після logout, локалізація помилок, мобільна версія.

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

Як протестуєш переказ коштів між картками?

Валідація: номер картки (формат, контрольна сума Луна), сума (межі, дробові частини, нуль, від'ємна), власна картка як отримувач.
Бізнес-правила: достатньо коштів, ліміти, комісія за тарифом, валюта отримувача.
Результат: баланс відправника і отримувача, історія операцій, сповіщення, квитанція.
Стани й збої: відхилення банком, 3-D Secure, тайм-аут, обрив мережі.
Дублікати й гонки: подвійний клік, «Назад» і повторна відправка, дві вкладки.
Безпека: маскування номера, доступ до чужих переказів, логи без даних карток.
Дані: записи в БД і в журналі аудиту, звірка.

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

Ти єдиний QA на новому проєкті. Що робиш у перші 30 днів?

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

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

Тиждень 3 — швидкі перемоги: smoke-чекліст критичних сценаріїв, шаблон баг-репорту, участь у грумінгу з критеріями приймання.

Тиждень 4 — план: тест-стратегія на основі ризиків, пріоритети для регресії й автоматизації, 2–3 метрики стану. Погодити з командою.

Головне — не ламати процес у перший тиждень, а спершу зрозуміти, чому він такий.

На співбесіді: Перший тиждень я вивчаю продукт і говорю з PM та розробниками, щоб зрозуміти, де найбільше болить. Другий — оцінюю, що вже є: тести, документація, процес релізу. Третій — даю швидкі результати: smoke-чекліст критичних сценаріїв і участь у грумінгу. А на четвертий пропоную тест-стратегію на основі ризиків і погоджую її з командою. Головне — спершу зрозуміти процес, а потім його змінювати.

Розробник каже «у мене працює», а в тебе баг відтворюється. Що робиш?

Порівняти умови: середовище (local vs staging), версія білда, конфіги й фіча-флаги, дані користувача, браузер.
Показати, а не доводити: відео, HAR-файл, точний час для пошуку в серверних логах, ID запиту.
Відтворити разом — 5 хвилин на спільному дзвінку часто економлять день переписки.
Якщо різниця в середовищі — це теж знахідка: розбіжність конфігів між середовищами може повторитися на проді.

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

PM хоче релізити з відомим критичним багом. Твоя позиція?

Рішення про реліз — за бізнесом, а завдання QA — щоб воно було свідомим.

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

Якщо баг порушує закон чи безпеку даних — ескалювати вище, а не просто погодитися.

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

Задачі приходять на тестування в останній день спринту. Як це виправити?

Це проблема процесу, а не швидкості QA. Рішення:

Ділити сторі на менші, щоб вони доходили до тестування протягом спринту.
Обмежити кількість задач у роботі (WIP), щоб команда доводила задачі до кінця, а не починала нові.
Тестувати раніше: тест-кейси до розробки, API до UI, тестування на гілці фічі.
Розробники роблять базову перевірку за чеклістом перед передачею.
Показати проблему даними: час у статусі «Ready for QA», скільки задач приходить в останні два дні — і винести на ретро.

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

Вимоги змінились після того, як ти вже протестував фічу. Що робиш?

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

Якщо таке повторюється — тема для ретро: вимоги мають бути стабільними на момент взяття задачі в спринт (Definition of Ready).

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

Регресія триває три дні, а релізи щотижня. Що робиш?

Пріоритизувати: розділити регресію на рівні — критичний smoke (години), основна регресія, повна (рідко).
Ризик-орієнтований вибір: на кожен реліз — критичні сценарії плюс зони, які зачепили зміни.
Почистити набір: видалити дублі й застарілі кейси, об'єднати дрібні.
Автоматизувати: перш за все стабільні, повторювані, критичні сценарії і API-перевірки.
Паралелити: розподілити ручну регресію між людьми, автотести — між воркерами.

Мета — щоб найважливіша частина регресії займала години, а не дні.

На співбесіді: Я ділю регресію на рівні: швидкий критичний smoke на кожен реліз, основна регресія за зонами змін і повна — рідко. Чищу набір від дублів і застарілих кейсів, а стабільні критичні сценарії й API автоматизую. Мета — щоб найважливіша частина перевірки займала години, а не дні.

Флакі-автотест блокує мердж, команда хоче його просто вимкнути. Твої дії?

Вимкнути — можна, але як тимчасовий крок з відповідальністю:

Помітити тест як quarantine або skip з тікетом, власником і терміном.
Перевірити, що сценарій не лишився зовсім без покриття — тимчасово перевіряти вручну.
Розібрати причину: тест, тестові дані, середовище чи справжня гонка в продукті. Іноді флакі — це реальний баг.
Відстежувати кількість тестів у карантині: якщо вона росте, набір втрачає цінність.

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

Тестове середовище постійно падає, а дедлайн близько. Що робиш?

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

На співбесіді: Я одразу повідомляю команду і фіксую час простою, бо це блокер для всіх. Поки середовище лежить, тестую те, що можу — API, локальне підняття в Docker — і готую кейси й дані. Перепріоритизую на критичні сценарії і чесно оновлюю ризики релізу. А після дедлайну приношу дані про простої, щоб стабільність середовища стала окремою задачею.

Клієнт просить пропустити тестування, щоб встигнути з релізом. Що робиш?

В аутсорсі рішення за клієнтом, але він має приймати його з розумінням наслідків.

Не сперечатися «так не можна», а запропонувати мінімальну перевірку: smoke критичних сценаріїв за кілька годин.
Назвати конкретні ризики: що саме не перевірено і що може статися.
Зафіксувати рішення письмово в листі чи тікеті.
Запропонувати перевірку одразу після релізу і готовий план відкату.
Повідомити свого менеджера чи лідa з боку компанії.

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

Під час тестування знайшов баг, який не стосується твоєї задачі. Що робиш?

Завести його окремим тікетом, а не мовчати і не дописувати в поточну задачу.

Перевірити, чи немає вже такого бага.
Оформити повноцінний репорт з severity.
Якщо баг критичний — одразу сказати команді, а не лише створити тікет.
Зазначити, чи він блокує поточну задачу, і пов'язати тікети.

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

Як ти оцінюєш час на тестування задачі?

Розкладаю на складові і враховую ризики:

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

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

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

Як протестуєш експорт виписки в PDF або CSV?

Дані: операції за період збігаються з історією і базою; суми, валюти, дати; підсумки сходяться.
Фільтри: межі періоду (включно чи ні), порожній період, дуже великий період, часовий пояс.
Формат: CSV відкривається в Excel без зламаних символів (кодування UTF-8, кирилиця), роздільники, десятковий знак; PDF — верстка, розриви сторінок, реквізити.
Обсяг: тисячі операцій — час генерації, розмір файлу, асинхронна генерація з повідомленням.
Безпека: лише власні рахунки, маскування номерів карток, доступ до файлу за посиланням.
CSV-ін'єкція: значення, що починаються з =, +, -, @, не виконуються як формули в Excel.

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

Неповні або суперечливі вимоги

Спершу аналізую вимоги й фіксую конкретні питання, а не загальне «незрозуміло». Уточнюю в PO, бізнес-аналітика або розробника — бажано письмово, у тікеті чи Confluence, щоб рішення лишилось задокументованим. Суперечності показую на прикладі конкретного сценарію.

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

Найкраще ставити такі питання ще на етапі грумінгу або рефайнменту, до початку розробки. Це частина shift-left підходу: дефект у вимогах найдешевше виправити до написання коду.

Тестування форми логіну

Позитивні перевірки: вхід з валідними даними, збереження сесії, опція «Запам'ятати мене», редірект на потрібну сторінку, логаут. Також перевіряю вхід через Enter, автозаповнення браузера й роботу на різних пристроях.

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

Security: пароль приховано й він не потрапляє в URL чи логи, передача лише через HTTPS, блокування або CAPTCHA після кількох невдалих спроб. Також SQL-ін'єкції та XSS у полях, прапорці HttpOnly та Secure для cookie, інвалідація сесії після логауту. Окремо — UI, доступність з клавіатури і відновлення пароля.