DoD (Definition of Done) Формальный чек-лист, без которого инкремент не считается готовым. Если в DoD нет пункта про автотесты, исследовательское тестирование или проверку на продуктовом окружении — задача не готова.

Acceptance Criteria Контракт между Product Owner и командой. QA превращает критерии в тест-кейсы. Нет критериев — нет опоры для тестирования, одни догадки.

Definition of Ready (DoR) Входной фильтр задачи в спринт: понятна ценность, прописаны Acceptance Criteria, даны оценки, убраны внешние зависимости. Без DoR QA получает сырую историю и заведомо плывёт по срокам.

Shift-Left Тестирование начинается не после разработки, а в момент refinement и планирования. QA — инженер качества, а не приёмщик брака в конце конвейера.

Three Amigos Встреча Business Analyst, разработчика и QA до написания кода. Цель — снять разночтения по истории. Главный источник багов — недосказанность, «Амигос» глушат её на старте.

Example Mapping Техника разбора User Story: правила, конкретные примеры, открытые вопросы. QA вылавливает неоднозначности и превращает их в ясные сценарии.

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

Test Pyramid Распределение тестов по уровням: много модульных (юнит), меньше интеграционных, ещё меньше сквозных e2e. Если пирамида перевёрнута — имеем хрупкие, медленные прогоны, которые врут о качестве.

TDD (Test-Driven Development) Разработчик пишет падающий тест, потом код, потом рефакторит. Для QA это значит, что модульные проверки живут с первого дня, а силы тестировщика смещаются на интеграцию, сценарии поведения и исследование.

BDD (Behavior-Driven Development) Сценарии на языке Given-When-Then, понятном и бизнесу, и разработке. QA участвует в написании исполняемых спецификаций — они же становятся автотестами.

ATDD (Acceptance Test-Driven Development) Приёмочные тесты создаются до разработки, совместно PO, разработчиками и QA. Это Acceptance Criteria в форме автоматизированной проверки, а не просто текста в тикете.

Exploratory Testing Одновременное изучение, проектирование и выполнение тестов по хартии (сессии). Не хаотичный «тык», а дисциплина с временными рамками и отчётом о найденных рисках.

Pair Testing / Mob Testing Совместная сессия двух или всей команды за одной клавиатурой. Вскрывает слепые зоны быстрее, чем одиночная проверка, и моментально распространяет знание продукта.

Regression Testing Проверка, что новый код не разрушил существующее поведение. В Agile это непрерывная активность, а не фаза; если оставлять её только на конец спринта — техдолг сожрёт скорость.

Smoke Testing Минимальный «дымовой» прогон критического пути после сборки. Цель — понять, можно ли отдавать билд дальше, или он упадёт на первых шагах.

Sanity Testing Узконаправленная проверка исправления: баг точно закрыт, и очевидные соседние функции не пострадали. Не путайте с регрессом — здесь глубина минимальная.

Continuous Integration (CI) Автоматическая сборка и прогон тестов при каждом коммите. QA следит, чтобы пайплайн не «зеленил» ложноположительными прогонами, а набор тестов давал быструю обратную связь.

Continuous Delivery (CD) Способность выпускать релиз в любой момент. Для QA означает, что ручное регрессионное тестирование на релизных ветках — динозавр; упор на автоматизированные проверки и безопасные механизмы выкатки.

Feature Toggle Выключатель функциональности в коде. Позволяет тестировать фичу изолированно, комбинировать состояния тогглов и прятать неготовый функционал от пользователей.

Canary Release / Blue-Green Deployment Выпуск новой версии на небольшую группу пользователей (канареечный) либо на параллельное окружение с мгновенным переключением. QA анализирует метрики, логи, ошибки, чтобы принять решение «катить дальше или откатить».

Technical Debt Осознанные компромиссы в коде ради скорости. Для QA это инкубатор регрессионных багов и замедления тестов. Важно визуализировать техдолг и биться за время на его выплату.