План, що описує заходи для зниження ймовірності виникнення або впливу ризиків.

План, що приймає на себе всі ризики без жодних дій.

Додатковий тестовий сценарій для перевірки нової функції.

Документ, який фіксує усі виявлені дефекти.

Що таке mitigation plan у контексті управління ризиками?

Тест перевіряє знання ключових концепцій та практик тестування програмного забезпечення на рівні Senior QA.

Набір критеріїв, які визначають, що робота над інкрементом або завданням завершена і готова до релізу.

Список тестів, які треба автоматизувати для релізу.

Документ, що описує лише функціональні вимоги продукту.

Графік робіт і термінів для команди розробки.

Коли виявлено нуль дефектів під час тестування.

Коли досягнуто погоджених критеріїв виходу (exit criteria), ризики прийнятні, і досягнутий рівень покриття відповідає вимогам.

Коли команда тестувальників вичерпала весь перелік можливих сценаріїв вручну.

Коли минув запланований час тестування незалежно від результатів.

Коли можна вважати, що тестування завершене?

Інструмент для автоматичного створення тестів.

Спосіб класифікації дефектів за пріоритетністю.

Процес виявлення корінної причини дефекту з метою запобігання повторенню помилки.

Метод оцінки продуктивності тестової команди.

Що таке RCA (Root Cause Analysis) у тестуванні і яка її основна мета?

Перенесення тестування на етап після релізу для швидшої ідентифікації дефектів.

Тестування, яке виконується лише командою розробників.

Зменшення обсягу тестів, щоб скоротити час релізу.

Зсув тестування на ранні стадії життєвого циклу розробки з метою виявити дефекти раніше.

Що означає поняття "shift-left testing"?

Провести аналіз вимог і ризиків, визначити критичні бізнес-функції та скласти тест-стратегію і план.

Негайно почати автоматизувати всі існуючі тести.

Почекати, поки розробники завершать увесь функціонал, і лише потім почати тестування.

Зосередитись тільки на UI-тестуванні, оскільки UX найважливіший.

Який найкращий початковий підхід для старту QA в новому проєкті?

Лише один раз на початку проєкту.

Регулярно: після значних змін у вимогах або перед кожним релізом.

Тільки коли виявляють багато дефектів під час тестування.

Ніколи — документація має бути стабільною.

Як часто варто виконувати рев’ю тестової документації?

Включити всі відомі регресійні тести.

Випадково обрати кілька тестів для швидкої перевірки.

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

Запустити лише автоматичні тести UI без врахування бекенду.

Як швидко сформувати вибірку перевірок для smоke-тестування?

Орієнтуватися лише на максимальні можливі значення навантаження без урахування реальних сценаріїв.

Брати за основу історичні дані трафіку, SLA, очікувані користувацькі сценарії та метрики продуктивності.

Тестувати тільки пік навантаження раз на рік.

Робити навантаження лише на UI, ігноруючи API та інфраструктуру.

На яких засадах слід будувати стратегію навантажувального тестування?

Показник рентабельності інвестицій, що обчислюється як (вигоди від заходу − витрати) / витрати.

Кількість знайдених дефектів за одиницю часу тестування.

Час, що витрачається на автоматизацію одного тесту.

Відношення кількості тестів до кількості вимог.

Що таке ROI і як його зазвичай розраховують у контексті тестування?

Інструмент для створення тестових даних вручну.

Практики безперервної інтеграції та безперервної доставки/розгортання, що автоматизують збірку, тестування і доставку коду.

Методологія управління вимогами.

Спосіб ручного тестування релізів тільки вночі.

Що таке CI/CD у розробці ПЗ і яка його ключова перевага?

1–3 кроки, щоб тест був максимально простим.

Більше 20 кроків, щоб охопити всі деталі в одному сценарії.

Будь-яка довжина, головне — покрити усі випадки.

Приблизно 5–10 кроків — достатньо для чіткого опису дій і простоти супроводу.

Яка оптимальна кількість кроків у тестовому сценарії для зручності виконання та діагностики?

Питання 5 з 12