Вы уже знаете, как эффективно общаться в IT-команде: как вежливо указывать на ошибку, как задавать уточняющие вопросы и как строить продуктивный диалог с разработчиками и аналитиками. Теперь пришло время поговорить о том, о чём именно вы будете общаться.
Представим ситуацию: вам приходит задача — «Проверьте форму сброса пароля». Что делать? Куда смотреть? Что считать ошибкой?
Ответ — в требованиях. Именно они определяют, как должна работать функция, а значит, что и как вы будете тестировать.
Сегодня мы разберём, как тестировщик работает с требованиями пользователя, и познакомимся с одним из самых популярных способов их оформления — User Story.
Что такое User Story?
User Story (пользовательская история) — это краткое описание функции с точки зрения пользователя.
Она не техническая, не формальная, а человеческая. Её цель — объяснить, кто хочет сделать что и зачем.
Структура User Story стандартна:
Как [роль], я хочу [действие], чтобы [цель]
Пример:
Как пользователь, я хочу сбросить пароль, чтобы восстановить доступ к аккаунту
Как администратор, я хочу видеть список последних входов, чтобы отслеживать безопасность
Такая форма помогает всей команде — и разработчику, и тестировщику — думать о пользователе, а не только о коде.
💡 Важно: User Story — это не задача разработчика и не баг-репорт. Это описание потребности. Она становится задачей только после уточнений.
Критерии принятия: что значит «готово»?
User Story сама по себе — это скорее идея. Но чтобы её можно было реализовать и проверить, нужны критерии принятия.
Критерии принятия — это конкретные условия, при выполнении которых задачу можно считать завершённой.
Они отвечают на вопрос:
✅ Что должно произойти, чтобы мы сказали: «Функция работает правильно»?
Вернёмся к примеру с сбросом пароля:
User Story:
Как пользователь, я хочу сбросить пароль, чтобы восстановить доступ к аккаунту
Критерии принятия:
- Когда пользователь нажимает «Забыли пароль?», открывается форма ввода email
- После ввода зарегистрированного email и нажатия «Отправить» приходит письмо со ссылкой
- Ссылка действует 1 час
- По переходу по ссылке пользователь может ввести новый пароль
- Новый пароль должен соответствовать требованиям безопасности (не менее 8 символов, одна цифра)
Без таких критериев тестировщик может проверить «всё подряд» или, наоборот, пропустить важное.
🔄 Напомним: вы уже учили, как писать тест-кейсы и чек-листы. Теперь вы понимаете — критерии принятия — это основа для ваших тестов.
Как тестировщик использует User Story?
User Story — это отправная точка для тестирования.
Вот как мы с вами можем превратить её в инструмент проверки:
- Читаем User Story — понимаем, кто пользователь и зачем ему функция
- Изучаем критерии принятия — выделяем, что именно нужно проверить
- Создаём чек-лист или тест-кейсы — превращаем требования в шаги тестирования
Возьмём ту же User Story и создадим чек-лист:
Чек-лист: Сброс пароля
- Проверить наличие кнопки «Забыли пароль?» на экране входа
- Проверить, что после ввода email и нажатия «Отправить» появляется сообщение «Письмо отправлено»
- Проверить, что на указанный email приходит письмо со ссылкой
- Проверить, что ссылка в письме действует в течение 1 часа
- Проверить, что после перехода по ссылке открывается форма ввода нового пароля
- Проверить, что система не принимает пароль короче 8 символов
- Проверить, что после успешного сброса можно войти с новым паролем
Вы видите? Каждый пункт — это перевод критерия принятия в действие.
💬 Это прямая связь с темой Эффективная коммуникация в IT-команде. Если критерии непонятны — вы уже знаете, как вежливо задать вопрос аналитику.
Хорошая vs. плохая User Story
Чтобы лучше понять разницу, сравним два примера.
| Плохо | Хорошо |
|---|---|
| «Сделать сброс пароля» | «Как пользователь, я хочу сбросить пароль, чтобы восстановить доступ к аккаунту» |
| Нет критериев | Есть 5 чётких критериев принятия |
| Что проверять? Непонятно | Чёткий план для тестирования |
В первом случае тестировщик может уйти в догадки. Во втором — сразу понимает, что и как проверять.
🔍 Практический совет: Если вы видите User Story без критериев — это повод задать вопрос. Не начинайте тестирование вслепую.
Как избежать типичных ошибок?
Даже с хорошей User Story можно ошибиться. Вот частые ловушки:
-
Тестирование «всего подряд»
→ Фокусируйтесь только на том, что описано в критериях.
→ Остальное — это уже отдельные задачи. -
Игнорирование контекста
→ Спрашивайте: кто пользователь? Что он хочет?
→ Например, «администратор» и «обычный пользователь» — разные роли, разные ожидания. -
Неспособность перевести текст в шаги
→ Разбивайте каждый критерий на конкретные действия.
→ Используйте шаблон: «Проверить, что при [условии] происходит [результат]».
💡 Если User Story кажется расплывчатой — вспомните, чему вы учили в Эффективной коммуникации: задавайте уточняющие вопросы. Это не ошибка — это часть вашей роли.
Почему это важно для карьеры?
User Story — это язык Agile-команд.
На большинстве проектов в России в 2025 году требования оформляются именно в таком формате — особенно в Jira, YouTrack и других системах управления задачами.
Когда вы умеете работать с User Story:
- Вы понимаете, что именно тестировать
- Вы можете сразу создавать полезные тест-кейсы
- Вы говорите на одном языке с аналитиками и разработчиками
- Вы показываете, что готовы к реальной работе, а не только к теории
🚀 Это то, на что смотрят на собеседованиях. Умение работать с требованиями — один из ключевых навыков Junior QA.
Что дальше?
То, что вы только что создали — чек-лист по User Story — это отличный пример практической работы.
И знаете что?
В следующей теме — Что включить в портфолио — мы расскажем, как именно такие материалы помогут вам показать свои навыки будущему работодателю.
Сохраните этот чек-лист. Он пригодится.
А пока — поздравляем.
Теперь вы не просто ищете баги.
Вы понимаете, откуда берётся правильный тест.
И это восхитительно.