БЛОК 1. Основы тестирования — 4. Где начинается тестирование
🧭 Введение: почему это ключевой сдвиг для junior QA
Многие новички думают, что тестирование начинается в тот момент, когда задача перешла в колонку “Ready for QA”. На практике к этому моменту уже поздно исправлять часть критичных ошибок дёшево и спокойно. Именно поэтому сильный QA начинает тестирование раньше: с требований, критериев и рисков.
Если стартовать рано, команда быстрее замечает дыры в логике, неясные формулировки и конфликтующие ожидания. Это снижает число “срочных” багов перед релизом и делает работу QA заметной для всей команды.
💡 Совет:
Перед любым тестом сначала спросите: “Что именно мы строим и как поймём, что это работает правильно?”
✅ Вывод:
Тестирование начинается не с кликов в интерфейсе, а с проверки требований и ожиданий.
⚠️ Проблема -> решение
Когда QA подключается только после разработки, команда получает типичную боль: неясные критерии, внезапные спорные кейсы, затянутые фиксы и нервный релиз. Формально “тестирование было”, но качество процесса остаётся слабым.
Решение — сдвинуть начало тестирования влево: QA участвует в анализе задачи до кода, задаёт уточняющие вопросы, фиксирует риски и готовит черновой тест-дизайн заранее.
🟢 Если совсем просто:
Чем раньше QA подключился к задаче, тем меньше дорогих сюрпризов в конце.
🎯 Как понять, что этап прошёл успешно:
До начала разработки у команды уже есть понятные критерии приёмки, список рисков и базовый план проверок.
🛠️ Чем помогает и как работает
Ранний старт тестирования помогает команде принимать решения на фактах, а не на догадках. QA не тормозит разработку, а снижает количество переделок и улучшает предсказуемость релиза.
Как это работает:
- Шаг 1: QA читает задачу до разработки и проверяет, есть ли тестопригодные требования.
- Шаг 2: QA уточняет двусмысленные места в user story и acceptance criteria.
- Шаг 3: QA фиксирует риски: где может сломаться логика, валидация, права доступа, интеграции.
- Шаг 4: QA заранее готовит черновой набор проверок (happy path, negative, edge).
- Шаг 5: QA синхронизирует ожидания с Dev/BA/PO до старта реализации.
- Шаг 6: После появления build QA выполняет уже подготовленные проверки быстрее и точнее.
✅ Вывод:
Раннее тестирование уменьшает хаос в execution и повышает качество релизных решений.
📚 Ключевые термины (простыми словами)
- Requirement (требование) — правило или ожидание к функциональности.
- User Story (пользовательская история) — описание ценности фичи для пользователя.
- Acceptance Criteria (критерии приёмки) — условия, при которых задача считается выполненной.
- Testability (тестопригодность) — насколько требование можно проверить объективно.
- Ambiguity (неоднозначность) — формулировка, которую можно понять по-разному.
- Shift-left testing (сдвиг тестирования влево) — раннее подключение QA до этапа execution.
- Risk (риск) — вероятность проблемы и её влияние на пользователя/бизнес.
- Definition of Done (критерий завершения) — единое правило, когда работа действительно готова.
1. Тестирование требований: старт качества до кода
Первый реальный шаг тестирования происходит в момент чтения задачи, а не при запуске тест-кейсов. Если требования расплывчатые, QA не сможет сделать точную проверку даже при идеальном execution.
🟢 Если совсем просто:
Сначала проверяем, что задачу вообще можно проверить, потом пишем тесты.
🎯 Как понять, что этап прошёл успешно:
Требования можно перевести в конкретные проверки “вход -> действие -> ожидаемый результат”.
Назначение:
Поймать логические и формулировочные проблемы до разработки.
Простыми словами:
QA проверяет не только продукт, но и саму постановку задачи на понятность и проверяемость.
Для новичка:
Если после чтения задачи вы не можете сформулировать “что считать правильным результатом”, значит требование ещё сырое.
Аналогия:
Это как проверять чертёж до начала строительства: дешевле исправить бумагу, чем ломать готовую стену.
Пример:
Плохо: "Сделать удобную регистрацию"Хорошо: "Пользователь с валидным email и паролем >= 8 символовможет зарегистрироваться и видит экран успешного входа"🔎 Как это происходит на практике:
- QA получает задачу на refinement.
- QA выделяет неопределённые места: “удобная”, “быстро”, “по возможности”.
- QA задаёт уточняющие вопросы и переводит формулировки в проверяемые критерии.
- Команда фиксирует обновлённые критерии до старта разработки.
Характеристики:
- ✅ Снижает число ложных багов и споров “это баг или фича”.
- ✅ Ускоряет разработку за счёт ясной постановки.
- ✅ Делает тестирование предсказуемым.
Когда использовать:
Всегда, когда задача новая, сложная или влияет на критичный пользовательский поток.
✅ Вывод:
Если требование не тестопригодно, execution будет дорогим и неточным.
2. Acceptance Criteria: что именно считаем “готово”
Даже хорошая user story бесполезна, если команда не договорилась о точных критериях приёмки. AC превращают “общую идею” в конкретные проверяемые условия.
🟢 Если совсем просто:
Acceptance Criteria это чек-лист “готово/не готово”.
🎯 Как понять, что этап прошёл успешно:
Каждый критерий можно проверить объективно и получить однозначный результат.
Назначение:
Зафиксировать единое понимание результата между QA, Dev и PO.
Простыми словами:
AC отвечают на вопрос: “Что обязательно должно работать, чтобы задачу принять?”
Для новичка:
Если критерий нельзя проверить одним конкретным тестом, он слишком абстрактный и требует уточнения.
Аналогия:
Это как список приёмки квартиры: без него вы не докажете, что работа действительно завершена.
Пример:
AC-1: Невалидный email -> ошибка "Введите корректный email"AC-2: Пустой пароль -> кнопка "Зарегистрироваться" неактивнаAC-3: Успешная регистрация -> создаётся user и отправляется welcome email🔎 Как это происходит на практике:
- QA читает AC и проверяет их на измеримость.
- QA добавляет missing cases: пустые поля, дубли, граничные значения.
- PO подтверждает бизнес-ожидания.
- Dev реализует поведение под согласованные AC.
Характеристики:
- ✅ Уменьшают двусмысленность в задаче.
- ✅ Ускоряют triage дефектов.
- ✅ Повышают качество релизной оценки.
Когда использовать:
Для каждой новой фичи, особенно в аутентификации, платежах и других критичных областях.
✅ Вывод:
Сильные acceptance criteria это фундамент и для разработки, и для тестирования.
3. Вопросы QA до разработки: как находить риски заранее
Раннее тестирование невозможно без правильных вопросов. QA должен не ждать проблем, а заранее искать уязвимые места в бизнес-логике и интеграциях.
🟢 Если совсем просто:
Хороший вопрос до кода экономит часы фиксов после кода.
🎯 Как понять, что этап прошёл успешно:
По итогам обсуждения появился список рисков и решений до начала реализации.
Назначение:
Предотвратить дефекты до их появления в коде.
Простыми словами:
QA заранее спрашивает “что если...?”, чтобы команда не ловила это в последний день перед релизом.
Для новичка:
Если вы не задали ни одного вопроса до разработки, вы почти наверняка получите неожиданные баги на execution.
Аналогия:
Это как репетиция перед выступлением: лучше ошибиться на прогоне, чем на сцене.
Пример:
Вопросы QA:1) Что делать при повторной отправке формы?2) Как система ведёт себя при медленном API?3) Что видит заблокированный пользователь?4) Какой текст ошибки показываем при 500?🔎 Как это происходит на практике:
- QA готовит 5-10 уточняющих вопросов перед groom/refinement.
- Команда обсуждает edge/negative сценарии.
- Решения фиксируются в задаче.
- QA обновляет черновой тест-дизайн под договорённости.
Характеристики:
- ✅ Уменьшают количество “сюрпризов” в конце спринта.
- ✅ Повышают зрелость командной коммуникации.
- ✅ Снижают риск релизных блокеров.
Когда использовать:
Перед стартом разработки, а также при изменении требований по ходу задачи.
✅ Вывод:
Ранние вопросы QA это не бюрократия, а инструмент профилактики дефектов.
4. Тест-дизайн до execution: черновик проверок заранее
Junior QA часто откладывает тест-дизайн “на потом”, когда появится build. Это замедляет работу и делает проверку хаотичной. Намного эффективнее подготовить черновой набор сценариев заранее.
🟢 Если совсем просто:
Сначала план проверок, потом запуск проверок.
🎯 Как понять, что этап прошёл успешно:
К моменту получения build у QA уже есть готовый список приоритетных проверок и тестовые данные.
Назначение:
Ускорить execution и повысить полноту покрытия.
Простыми словами:
QA заранее готовит карту маршрута, чтобы не искать путь в последний момент.
Для новичка:
Если build пришёл, а вы только начинаете думать “что проверить”, значит старт тестирования был слишком поздним.
Аналогия:
Это как собрать рюкзак до поездки, а не в такси по дороге в аэропорт.
Пример:
Черновой набор:- Happy path: валидная регистрация- Negative: невалидный email, пустой пароль, дубли email- Edge: длина пароля 7/8/9 символов- Non-functional hint: ответ API < 500 мс (базовый ориентир)🔎 Как это происходит на практике:
- QA строит минимальный список сценариев сразу после согласования AC.
- QA отмечает приоритет: critical/high/medium.
- QA готовит тестовые данные и preconditions.
- После выкладки build QA запускает проверки без потери времени.
Характеристики:
- ✅ Сокращает время между “build готов” и “первые результаты готовы”.
- ✅ Уменьшает риск пропуска критичных сценариев.
- ✅ Делает процесс проверок воспроизводимым.
Когда использовать:
Во всех задачах, где важна скорость обратной связи и предсказуемость релиза.
✅ Вывод:
Ранний тест-дизайн превращает execution в управляемый процесс, а не в импровизацию.
📊 Сравнение: ранний vs поздний старт тестирования
| Критерий | Ранний старт (до разработки) | Поздний старт (после разработки) |
|---|---|---|
| Работа с требованиями | Дыры и неоднозначности ловятся заранее | Проблемы всплывают на execution |
| Стоимость исправлений | Ниже | Выше |
| Скорость QA после build | Быстрая, сценарии уже готовы | Медленная, дизайн делается в последний момент |
| Коммуникация в команде | Прозрачная и спокойная | Споры “кто виноват” |
| Релизное решение | Основано на фактах и рисках | Часто “на ощущениях” |
✅ Must-Know для junior QA
- Тестирование начинается с требований и критериев, а не с кнопки “Run test”.
- Неоднозначное требование нужно уточнять до начала разработки.
- Каждый acceptance criterion должен быть проверяемым и однозначным.
- Риски лучше фиксировать до кода, а не после первых багов.
- Черновой тест-дизайн до execution экономит время всей команды.
- QA отвечает за прозрачность качества, а не за “магическое отсутствие багов”.
- Чем раньше найден дефект, тем дешевле его исправление.
❌ Частые мифы
❌ Миф: QA начинает работать только когда задача в колонке “Testing”.
✅ Как правильно: QA подключается на этапе требований и уточняет критерии до разработки.
📎 Почему это важно: ранний старт снижает стоимость ошибок и ускоряет релиз.
❌ Миф: Если требования написал аналитик, QA не должен их проверять.
✅ Как правильно: QA проверяет требования на тестопригодность и двусмысленность.
📎 Почему это важно: даже хорошее требование может быть непроверяемым в текущем виде.
❌ Миф: Сначала пишем код, потом подумаем про negative и edge cases.
✅ Как правильно: негативные и граничные сценарии обсуждаются до разработки.
📎 Почему это важно: иначе команда получает поздние и дорогие переделки.
❌ Миф: Чем больше найдено багов в конце, тем лучше QA.
✅ Как правильно: сильный QA предотвращает часть багов ещё до написания кода.
📎 Почему это важно: цель QA — не “охота на баги”, а снижение риска для пользователя и бизнеса.
❓ Часто спрашивают на собеседованиях
❓ Вопрос: Где по-настоящему начинается тестирование в Agile-команде?
✅ Ответ: На этапе анализа требований: когда QA проверяет постановку, критерии приёмки и риски до начала разработки.
❓ Вопрос: Почему раннее подключение QA экономит время команде?
✅ Ответ: Потому что дефекты и логические дыры находят до кода, когда исправления дешевле и быстрее.
❓ Вопрос: Как понять, что acceptance criteria хорошие?
✅ Ответ: Каждый критерий однозначный, проверяемый и даёт один понятный ожидаемый результат.
❓ Вопрос: Что должен сделать junior QA до старта execution?
✅ Ответ: Уточнить требования, зафиксировать риски, подготовить черновой набор сценариев и тестовые данные.
❓ Вопрос: Что будет, если пропустить этап анализа требований?
✅ Ответ: Команда получит хаотичный execution, спорные дефекты и высокий риск поздних переделок перед релизом.
🚫 Типичные ошибки
Ошибка 1: “Я начну думать о тестах, когда придёт build”
❌ Неправильно:
Откладывать тест-дизайн и вопросы к требованиям до этапа execution.
✅ Правильно:
Готовить черновой план проверок и уточнять AC до разработки.
Почему:
Так QA даёт быструю и точную обратную связь сразу после появления build.
Ошибка 2: Не задавать вопросы к неоднозначным формулировкам
❌ Неправильно:
Тестировать “как понял” без уточнений.
✅ Правильно:
Фиксировать двусмысленности и согласовывать точные условия с PO/BA.
Почему:
Это уменьшает число конфликтов “это дефект или не дефект”.
Ошибка 3: Проверять только happy path
❌ Неправильно:
Ограничиваться сценариями “всё работает правильно”.
✅ Правильно:
Сразу планировать negative и edge cases.
Почему:
Реальные инциденты чаще всего возникают именно в нестандартных ветках.
Ошибка 4: Не фиксировать риски письменно
❌ Неправильно:
Обсудить риски устно и не сохранить их в задаче.
✅ Правильно:
Вести короткий риск-лог и связывать риски с проверками.
Почему:
Без фиксации команда теряет контекст и повторяет одни и те же ошибки.
🧩 Best Practices
- Подключайтесь к задаче на refinement, а не только на execution.
- Переводите “красивые” формулировки в проверяемые критерии.
- Храните короткий чек-лист вопросов к требованиям для каждого нового тикета.
- Делайте черновой test design до появления build.
- Фиксируйте риски и их статус в одном месте, доступном всей команде.
- На daily коротко обновляйте команду: что уточнено, какие риски закрыты, что блокирует старт.
🏁 Заключение
Тестирование начинается там, где появляется задача и требования к ней. Если QA подключается рано, команда выигрывает дважды: меньше дорогих дефектов и больше предсказуемости релиза.
Сильный junior QA это не человек, который “больше всех кликает”, а специалист, который раньше других видит риск и превращает его в проверяемое действие.