Процессы и методологии: вопросы для собеседования QA

Кроме самих проверок, QA участвует в уточнении требований, оценке рисков и формировании критериев готовности.

Ещё важная часть — улучшение процесса: качество баг-репортов, тестовые данные, отчётность и обратная связь команде.

Из практики: когда QA подключается раньше разработки, количество поздних дефектов заметно падает.

Из артефактов для QA особенно важны backlog, sprint backlog и инкремент с понятными критериями приёмки.

Из церемоний ключевые — планирование, daily, review и ретроспектива: на них QA синхронизирует риски и качество.

Из практики: если QA активно участвует в review и ретро, команда быстрее исправляет системные проблемы качества.

В Agile тестировщик не «финальный фильтр», а участник команды с первого дня задачи.

Он помогает уточнить критерии приёмки, покрытие рисков и план проверок до выкладки.

Из практики: активная роль QA на планировании убирает много переделок в конце спринта.

Критерии входа определяют, когда тестировать уже имеет смысл: есть сборка, окружение и понятные требования.

Критерии выхода и Definition of Done фиксируют, что работа действительно завершена: проверки пройдены, критичные дефекты закрыты, артефакты обновлены.

Из практики: прозрачный DoD снижает число спорных задач «почти готово» перед релизом.

Shift-left означает перенос активности QA на ранние стадии: требования, дизайн и декомпозицию задач.

Так дефекты обнаруживаются раньше и обходятся дешевле для команды и бизнеса.

Из практики: участие QA в уточнении требований заметно сокращает количество критичных исправлений в конце.

Сдвиг тестирования влево означает, что проверки и анализ рисков начинаются раньше, ещё до готового функционала.

Я подключаю QA на этапе требований и проектирования, чтобы ловить проблемы до реализации.

Из практики: раннее участие QA заметно снижает стоимость исправлений.

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

Отдельно оцениваю остаточные риски и влияние известных ограничений на пользователя и бизнес.

Из практики: лучше честно зафиксировать риски перед релизом, чем делать вид, что их нет.

Построение QA с нуля начинаю с оценки рисков продукта, целей качества и текущих узких мест в процессе.

Дальше выстраиваю приоритеты: критичные сценарии, окружения, метрики, роли и правила релизной готовности.

Из практики: устойчивый процесс рождается из простых и понятных правил, которые команда реально соблюдает каждый день.

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

В приоритет ставлю критичные потоки и высокорисковые изменения, а остальное фиксирую как следующий этап.

Из практики: прозрачная договорённость о приоритетах с командой снимает конфликты и помогает уложиться в сроки.

Ретроспектива — это встреча команды в конце итерации: что прошло хорошо, что плохо, что улучшить. Помогает накапливать практику и расти.

Форматы: Start/Stop/Continue, Mad/Sad/Glad, 4L (Liked/Learned/Lacked/Longed for). Главное — психологическая безопасность и фиксация конкретных action items.

Из практики: ретроспектива без action items — пустая трата времени. Должен быть владелец каждого пункта и срок проверки на следующей встрече.

Не «контролёр на выходе», а полноценный участник команды: уточняет требования, помогает в дизайне, пишет автотесты, участвует в код-ревью (с точки зрения тестируемости), консультирует команду.

Также QA отвечает за стратегию тестирования, ведёт качество как метрику, прокачивает практики автоматизации.

Из практики: в зрелых командах QA не «принимают» работу разработчиков, а вместе строят процесс, при котором баги ловятся как можно раньше — на ревью, в pre-commit hooks, на CI.

Hotfix — это срочное исправление критичного бага на проде. Обычно делают коротким циклом: отдельная ветка от main/release, минимальный фикс, ускоренное тестирование, релиз.

QA фокусируется на retest конкретного бага и таргетированной регрессии вокруг. Полную регрессию не делают — нет времени, и это излишний риск.

Из практики: после hotfix обязательно пишут post-mortem — что произошло, почему пропустили, что улучшить (тест-кейс, мониторинг, процесс).

Feature flag — переключатель в коде, позволяющий включать/выключать фичу без деплоя. Используется для постепенного раскатывания, A/B-тестов, аварийного отключения.

QA тестирует и со включённым флагом, и с выключенным — обе ветки кода. Также проверяет, что флаг переключается корректно (без перезагрузки или с понятным предупреждением).

Из практики: фича-флаги — мощный инструмент, но создают комбинаторное пространство для тестирования. Лучше иметь правила управления (как долго, кто владелец, когда удалить).

Постмортем — это разбор инцидента после его устранения: что произошло, как обнаружили, что сделали, root cause, какие уроки.

Принцип blameless — не ищут виноватых, ищут процесс/систему, который допустил ошибку. Это создаёт безопасность для честных отчётов.

Из практики: вывод обычно — action items: улучшить мониторинг, добавить тест, изменить процесс, написать runbook. Их обязательно отслеживают до закрытия.

Kanban — непрерывный поток задач без чётких итераций. Доска с колонками (TODO, IN PROGRESS, DONE), WIP limits, метрики flow time.

Scrum — итеративный с фиксированной длиной (sprint), commitment-ом на спринт, церемониями (planning, daily, review, retro).

Из практики: Kanban подходит для поддержки/инцидентов (нет смысла планировать спринт). Scrum — для продуктовой разработки с возможностью планирования.

Story points — относительная оценка сложности задачи (1, 2, 3, 5, 8, 13...). Не в часах, а в «сложности по сравнению с другими задачами».

Используют для прогнозирования velocity (сколько story points команда делает за спринт) и планирования.

Из практики: точки — не для измерения индивидуальной производительности. Это инструмент команды. Сравнивать velocity между командами бессмысленно.

Sprint planning — встреча в начале спринта: что взять в работу, какие задачи декомпозировать, оценка.

QA участвует: уточняет требования, обращает внимание на тестируемость, оценивает усилия по тестированию, поднимает риски.

Из практики: без QA на планировании рискуете взять задачу, которая в конце спринта окажется неотестируемой за оставшееся время.

Грумминг — регулярная встреча для подготовки задач к будущим спринтам: уточнение требований, разделение крупных, добавление acceptance criteria, оценка.

Участвуют PM, разработчики, QA, дизайнер. Цель — чтобы к sprint planning задачи уже были «готовы».

Из практики: качественный грумминг сокращает время на planning и устраняет задачи-сюрпризы в работе. Часто 1-2 часа в неделю.

PR review — обсуждение изменений перед merge. QA может: проверить acceptance criteria, посмотреть, что тесты добавлены, проверить, что новые UI-элементы тестируемы (data-testid).

Также: запустить новую сборку, протестировать руками сложные сценарии, дать feedback по edge-cases.

Из практики: QA на ревью PR — отличный shift-left. Баги ловятся до merge, и часто разработчик правит сразу.

Quality gate — критерии, при которых билд/изменение можно продвинуть дальше: code coverage, проход тестов, отсутствие critical багов, performance не регрессировал.

Определяет команда совместно: dev, QA, ops, product. Закрепляют в CI/CD pipeline.

Из практики: правильные quality gates — баланс между качеством и скоростью. Слишком строгие — задачи не идут в продакшен. Слишком мягкие — баги.

Incident management — процесс обработки инцидентов в проде: обнаружение, реакция, mitigation, recovery, post-mortem.

QA: помогает с диагностикой (воспроизвести в стенде), пишет тест-кейс на регрессию, участвует в post-mortem и предлагает улучшения процесса.

Из практики: ваша задача — чтобы один и тот же инцидент не повторился. Каждый post-mortem должен дать action item для testing/processes.

Jira — система управления задачами от Atlassian. Сущности: Issue (задача — Story, Bug, Task, Epic), Project, Sprint, Board, Workflow (статусы и переходы).

Кастомизируется глубоко: свои типы issue, поля, экраны, workflows.

Из практики: стандарт для большинства больших команд. Минусы — медленный UI, сложность администрирования. Альтернативы — Linear, YouTrack.

Часы/человекодни — абсолютная оценка. Story points — относительная (Фибоначчи 1/2/3/5/8/13). T-shirt size (S/M/L/XL) — для крупных эпиков. Planning poker — групповая оценка карточками. PERT — по трём оценкам (опт/реал/песс).

Я лично — story points в спринте, t-shirt size для роадмапа. Часы — только когда заказчик настаивает (фикс-цена контракт).

Из практики: оценка нужна не для отчёта, а для понимания нагрузки. Поэтому метод выбираю под цель, а не «как у всех».

Часы — абсолютная единица: «эта задача займёт 8 часов». Привязана к конкретному человеку, плохо переносится, ломается при отвлечениях и неожиданностях.

Story points — относительная оценка сложности и неопределённости задачи относительно эталона. Не часы и не дни. Они стабильны от человека к человеку, потому что измеряют задачу, а не исполнителя.

Из практики: главная ценность SP — команда учится калибровать оценки за 3–5 спринтов и предсказывать velocity. С часами этого не происходит.

Waterfall — последовательные этапы, каждый завершён до следующего. V-model — Waterfall с явной привязкой тестирования к этапам анализа/дизайна. RUP — итеративная с фазами Inception/Elaboration/Construction/Transition. Agile — итерации, эмпиризм, ценность; внутри — Scrum (фиксированные спринты), Kanban (поток без спринтов), XP (инженерные практики). SAFe/LeSS — масштабирование Agile на много команд.

Выбор зависит от: стабильности требований, размера, регулирования, культуры. Жёсткий фикс-скоуп с регулятором — Waterfall/V-model. Гибкость, обучение, продукт — Agile.

Из практики: «чистых» методологий мало. Большинство команд — гибрид: Scrum-ish с Kanban-элементами и собственными ритуалами.

Текущий проект — Scrum-подобный процесс с двухнедельными спринтами, daily standup, ревью и ретро. Backlog в Jira, документация в Confluence, общение в Slack.

Лично мне ближе Scrum с элементами Kanban: спринты дают предсказуемость, Kanban-доска внутри спринта помогает видеть поток и узкие места.

Из практики: важно не «какая методология», а как она реализована. Хорошо настроенный Kanban лучше формального Scrum, и наоборот.

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

Не применим (или плохо работает): жёсткий фикс-скоуп с регулятором, узко-специализированные одиночки, поддержка/incident management (тут лучше Kanban), исследовательские проекты с непонятной целью.

Из практики: «Scrum для всего» — миф. Saas-продукт — да. Команда поддержки с приоритетами «прилетает с горизонта» — лучше Kanban с SLA.

Sprint Planning — планирование спринта. Daily Scrum — ежедневный 15-минутный синк. Sprint Review — демо результатов стейкхолдерам в конце спринта. Sprint Retrospective — ретро команды для улучшения процесса. Backlog Refinement — регулярное уточнение и оценка задач (не обязательная по гайду, но почти всегда есть).

Сам спринт — тоже событие (контейнер для остальных). Длина обычно 1–4 недели, фиксированная.

Из практики: ретро — самое ценное событие. Команды, которые ретро отменяют, перестают улучшаться.

Product Owner — отвечает за максимизацию ценности продукта, владеет backlog, расставляет приоритеты. Scrum Master — отвечает за процесс и устранение препятствий, не менеджер команды. Developers (команда разработки) — кросс-функциональная команда, делает инкремент. По гайду — это всё.

Аналитик и BA в Scrum формально — часть Developers (или работают «рядом», помогая PO). В Scrum нет роли «аналитик» — это часть командной экспертизы.

Из практики: часто PO перегружен и берёт BA как «делегата по требованиям». Это работает, если границы ответственности понятны.

Kanban — метод управления потоком задач без фиксированных итераций. Принципы: визуализация (доска с колонками), WIP-лимиты (макс. задач в одной колонке), управление потоком (минимизация ожидания), явные правила, регулярная улучшающая обратная связь.

Работает «pull» — следующая задача берётся, когда есть ёмкость, а не «push» (всё на исполнителей).

Из практики: Kanban отлично подходит для поддержки, инфраструктурных команд, и продуктовых, где приоритеты часто меняются. WIP-лимиты — ключевая практика.

Scrum — итерации (спринты), фиксированный scope спринта, события (planning, retro), роли (PO, SM, Devs), velocity. Kanban — непрерывный поток без спринтов, WIP-лимиты, метрики потока (lead/cycle time), без жёстких ролей.

Scrum хорош для продуктовых задач с возможностью планирования. Kanban — для непрерывного потока (поддержка, операции, инфраструктура).

Из практики: гибрид «Scrumban» популярен — спринты + WIP-лимиты + lead-time-метрики.