Блог

Пользовательские истории: качественое тестирование в Agile

2025-01-27 14:25
Пользовательские истории — не документы, а инструмент диалога с пользователем. В чем разница между приложением, которое раздражает с первого клика, и продуктом, который решает проблемы ещё до того, как вы их осознаете? Первое формально создано для галочки, второе — через понимание потребностей реальных людей. Именно здесь на сцену выходят пользовательские истории.

Как связаны QA-процессы и пользовательские истории

QA (англ. Quality Assurance) = процесс обеспечения качества ПО через проверку функциональности, производительности и безопасности.
Направление QA и понятие юзер стори тесно связаны, т.к. ориентированы на создание качественного ПО. Пользовательские истории описывают цели пользователя, а QA трансформирует их в тестовые сценарии. Это гарантирует, что разработанные функции решают реальные задачи.

Почему важно писать качественные истории?

  • Плохо сформулированные истории приводят к путанице, задержкам и нерелевантному функционалу.
  • Чёткие критерии и шаблоны (например, INVEST) упрощают процесс разработки эффективных историй.
Поэтому для нас важно соблюдать специальные критерии и делать историю полезной и эффективной. Особенно хорошо это получается, когда можно не ломать голову над текстом, а идти по специально разработанному шаблону.

Пользовательские истории и подход Agile: как построить гибкое тестирование

Для комфортного погружения, давайте ещё немного разберёмся в терминологии.
Agile = подход, ориентированный на быструю адаптацию к изменениям с фокусом на потребности пользователей. В Agile пользовательские истории базируют работу, помогая команде определить, что нужно успеть сделать во время спринта и почему это важно.
Бэклог = список задач, включающий пользовательские истории и технические требования. В TMS ТестОпс пользовательские истории связаны с задачами из бэклога, статус их выполнения отслеживается в реальном времени.
Спринт = короткий период (обычно 1–2 недели), в течение которого команда выполняет определённое количество задач из бэклога. Каждый спринт начинается с планирования и заканчивается демонстрацией выполненной работы.
Дашборд = визуализация ключевых метрик проекта. Благодаря удобынм дашбордам в ТестОпс специалисты могут быстро оценить общий прогресс проекта или статус выполнения тестов.
Метрики = числовые показатели для оценки эффективности работы команды или качества продукта. В QA-тестировании метрики могут включать процент успешных тестов, время выполнения тестов и количество найденных багов.
Фреймворк (англ. Framework) = методика или шаблон для организации процесса работы. Например, INVEST — это популярный шаблон для упрощенного создания пользовательских историй, с которыми комфортно работать в команде. Как раз такой подход прекрасно реализуется в рамках Agile, включая подход Scrum, где требования формулируются в удобном формате.

Как Agile применяет пользовательские истории в тестировании

В работе с юзер стори тестировщики применяют фреймворк Agile следующим образом:

Приоритизация

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

Гибкость

Agile позволяет корректировать пользовательские истории по ходу работы. Например, если нужно добавить возможность группировать тесты по дате запуска, эта задача может быть внесена в текущий спринт и сразу протестирована.
💡 Пример: Добавление группировки тестов по дате запуска может быть внесено в текущий спринт и сразу протестировано.

Коллаборация

Пользовательские истории обсуждаются всем составом команды. На платформе ТестОпс такие обсуждения можно дополнить визуализацией, например, используя встроенные дашборды, где легко увидеть, какие задачи выполняются и какие тесты уже пройдены.
💡 Пример: если пользовательская история звучит так: «Как тестировщик, я хочу, чтобы результаты тестов показывали процент успешного выполнения для каждого модуля, чтобы понимать, где возникли проблемы», то в тестировании следует сосредоточиться на проверке правильности отображения статистики в интерфейсе программы.

Пользовательские истории в Scrum: от идеи до тестирования

Scrum = фреймворк Agile, где работа разбивается на спринты. Пользовательские истории работают одинаково хорошо в обеих методологиях и становятся основой для работы всей команды, включая менеджеров, разработчиков и тестировщиков.

Роль пользовательских историй в Scrum

I. Формирование бэклога

Пользовательские истории формируют список задач — бэклог. В ТестОпс истории привязываются к тестам для отслеживания выполнения.

Пример списка задач в ТестОпс

II. Декомпозиция задач

Cложные пользовательские истории делятся на небольшие задачи.

Пример разбивки заданий

История «Автоматическая проверка новых функций» делится на: добавление тестов для кнопки, проверку API, тестирование интерфейса на разных устройствах.

III. Критерии приёмки

Истории всегда содержат чёткие критерии. В ТестОпс это может быть успешное выполнение всех автоматических тестов для заданной сборки без ошибок в отчётах.

Пример условий принятия ПИ

В Scrum пользовательская история может звучать так: «Как пользователь, я хочу видеть сортировку тестов по их статусу (успешные, с ошибками, пропущенные), чтобы быстрее находить проблемные тесты», реализуется за 2 спринта.
  1. Сначала команда разрабатывает и добавляет функцию сортировки тестов;
  2. Затем тестирует её корректность её работы и отображению правильных статусов.
  3. Такие метрики как время на поиск тестов (сокращено на 30%) и доля актуализированных тестов (увеличена до 90%), демонстрируют улучшение процесса тестирования.

Шаблон INVEST в тестировании: основа пользовательских историй

Вне зависимости от выбранного фреймворка, качественная пользовательская история соответствует принципам INVEST. Мы его так и перевели: «ИНВЕСТ», а далее разбираем по буквам:

Independent (Индивидуальная):

ПИ существует самостоятельно и не зависит от других задач. Другими словами, задача или история является независимой и автономной.

Пример индивидуального задания в пользовательской истории

Если для завершения задачи «поиск пользователя по ID» требуется сначала реализовать сортировку по имени, это снижает гибкость планирования. Таким образом, задача «Добавить поиск по ID» должна быть независимой от задачи «Добавить фильтрацию по имени», чтобы они могли выполняться параллельно.

Negotiable (Надёжная)

Пользовательская история = точка начала диалога, а не ультимативное требование. Смысл в том, что история чётко сформулирована и выполнима, чтобы обеспечить надёжность реализации.

Пример обеспечения надёжности ПИ

Всегда есть смысл позабоиться о надёжности задачи, поэтому вместо «Как пользователь, я хочу фильтр с ползунком, чтобы задавать диапазон цен с шагом 1 рубль» лучше указать «Как пользователь, я хочу, чтобы на сайте была возможность фильтровать товары по цене, чтобы находить товары в рамках моего бюджета» — такая формулировка оставляет место для обсуждения деталей реализации.

Valuable (Выгодная)

Нормальная пользовательская история приносит ощутимую пользу пользователю и проекту.

Пример обеспечения выгодности задачи

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

Estimable (Единичная)

Для адекватной оценки трудозатрат в хорошей пользовательской истории всё понятно изложено в рамках одного предложения.

Пример единичности в пользовательской истории

Форма постановки задчи «Добавить кнопку экспорта данных» более конкретна, чем абстрактное «Наладить работу с данными» — чёткая постановка вопроса упрощает оценку по времени и ресурсам.

Small (Сокращенная)

История подаётся достаточно компактно, чтобы выполняться за один спринт.

Пример лаконичности в задаче

Так, вместо длинной истории «Создать личный кабинет пользователя с включением следующих разделов...», лучше разбить её на подзадачи, такие как «Добавить форму регистрации и определить поля для заполнения», «Создать интуитивно-понятный интерфейс авторизации» и т.д.

Testable (Тестируемая)

Чётко определенные критерии приёмки, чтобы мы могли проверить, что задача выполнена верно.

Пример соблюдения критерия тестируемости ПИ

Если придерживаться строгих условий приёмки, историю «Кнопка экспорта должна работать корректно, загружая файл в формате электронной таблицы» — такое действительно можно проверить в ходе тестирования.

Практический кейс создания пользовательской истории: хорошая VS 'не очень'

Теперь, когда мы ознакомились с фреймворками и моделями для составления пользовательской истории, мы можем определить, как стоит делать, а как — нет.

Как выглядит хорошая и плохая юзер стори

Хорошая история

Как тестировщик, я хочу видеть историю тестов для каждого запуска, чтобы анализировать результаты работы системы.
  • Независима: не требует реализации дополнительных модулей;
  • Ценна: помогает тестировщику анализировать систему;
  • Тестируема: можно проверить, что история тестов видна и корректна.

Непонятная история

Как пользователь, я хочу, чтобы всё работало быстро и красиво!
  • Неконкретна: неясно, что именно и каким образом нужно улучшать;
  • Неоцениваема: невозможно оценить трудозатраты;
  • Неполезна: не указывает на конкретную проблему.

Как составить корректную пользвательскую историю в Agile

Вот как мы В ТестОпс подходим к созданию пригодных и качественных пользовательских историй:

I. Определяем роль пользователя и его цель

Думаем, что именно хочет получить пользователь. Это помогает не терять фокус на ценности.

II. Используем простой язык

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

III. Регулярно обсуждаем истории и штурмим с командой

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

IV. Проверяем на соответствие INVEST или иным подходящим шаблонам

Перед добавлением истории в бэклог смотрим, отвечает ли она этим критериям.

Интеграция с TMS ТестОпс

В нашей практике мы полагаемся не только на модель INVEST и фреймворки Agile/Scrum, но также и на прозрачность и актуальность документации. Когда мы работаем над пользовательскими историями в тестировании, важно, чтобы они были понятны не только команде разработки, но и всем, кто участвует в проекте. Чтобы не терять детали и видеть, как каждая история помогает создать полезный продукт, мы используем собственные инструменты.
ТестОпс помогает обеспечивать качественное тестирование, поскольку автоматически поддерживает документацию в актуальном состоянии и позволяет соотнести пользовательские истории с тестами и результатами. Таким образом, у нас:
  1. Упрощается коммуникация;
  2. Сокращается время на рутинные задачи;
  3. Повышается прозрачность процессов.

Коротко о главном

Почему качественные пользовательские истории — наш выбор?
  • Мы считаем ПИ средством для бесшовного обмена информацией. Когда команда вкладывается в проработку историй, мы имеем не только комфортную постановку задач, но и лучшее представление конечного результата.
  • В TMS ТестОпс истории позволяют систематизировать тесты, и специалистам становится легче коммуницировать. Объединение ПИ с инструментами тестирования делает QA прозрачнее, а продукт — качественнее. Гибкие фреймворки Agile и Scrum снижают риски конфликтов в уточнении требований и упрощают распределение сроков, приоритетов и ресурсов.
Продуманные истории легче согласовать с бизнес-стратегией: любое изменение соотносится с измеримой пользой, и мы получаем чёткий образ развития продукта.
Мы в команде ТестОпс практикуем полноценную работу с пользовательскими историями — от первых идей до приёмочных тестов. Оптимизация формата ПИ, обсуждение и привязка к реальным метрикам ведут к верному росту качества продукта. Мы уверены, что этот подход реально даёт выхлоп в виде конкурентного преимущества и мотивирует всю команду идти к ощутимым результатам, а не впустую гнать задачи «по списку».