Система відділу забезпечення якості (QA)

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

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

QA-менеджер пише «План», розподіляє виконання та володіє рішенням про рекомендацію запуску — саме він зупиняє реліз, якщо лишаються критичні репорти. Тестувальники виконують і пишуть репорти за єдиним стандартом; розробники приймають репорти, виправляють і повертають до «Верифікації». Принцип системи: тестувальник не верифікує виправлення репорту, який написав сам, і запуск — рішення, задокументоване цифрами, а не загальне відчуття, що все виглядає добре.