В условиях быстрого темпа разработки программного обеспечения разрыв между тем, что представляет себе заинтересованная сторона, и тем, что создает разработчик, может быть огромным. Этот разрыв часто устраняется с помощьюКритериев приемки пользовательской истории. Для команд обеспечения качества эти критерии — это не просто список проверок; это контракт по качеству. Когда они сформулированы четко, они превращают неопределенность в конкретные сценарии тестирования.
Многие команды сталкиваются со слабо сформулированными требованиями. Фразы, такие как «удобный для пользователя» или «быстрая загрузка», часто появляются в первых черновиках, но не выдерживают строгой проверки. Этот гид предлагает структурированный подход к созданиюпроверяемых критериев приемки которые повышают эффективность инженеров по качеству, снижают количество утечек дефектов и обеспечивают согласованность между функциями продукта, разработки и тестирования.
🎯 Почему проверяемые критерии приемки важны
Критерии приемки (КП) определяют границы пользовательской истории. Они указывают условия, которые должны быть выполнены, чтобы считать историю завершенной. Для специалистов по качеству эти утверждения служат основой для создания тестовых случаев. Без них тестирование превращается в угадывание.
- Четкость ожиданий: Четкие критерии устраняют ошибки толкования между ролями.
- Эффективное тестирование: Конкретные условия позволяют тестировщикам сразу же создавать точные тестовые случаи.
- Снижение повторной работы: Неопределенность часто приводит к созданию неправильной функции. Хорошие КП предотвращают эту потерю.
- Поддержка автоматизированного тестирования: Проверяемые утверждения являются обязательным условием для скриптов автоматизации.
Когда КП неясны, команда тестирования тратит время на уточнение требований в течение спринта, что замедляет доставку. Когда КП точны, фокус полностью смещается на проверку и обеспечение качества.
🔍 Характеристики проверяемого утверждения
Не каждое требование проверяемо. Утверждение является действительным только в том случае, если его можно объективно проверить. Чтобы обеспечить проверяемость, критерии должны соответствовать следующим принципам:
- Однозначность: Утверждение имеет только одно толкование.
- Проверяемость: Возможна проверка прохождения или неудачи посредством наблюдения или данных.
- Атомарность: Каждый критерий касается одного условия, а не сложного требования.
- Актуальность: Он напрямую связан с целью пользовательской истории.
- Согласованность: Он не противоречит другим критериям или ограничениям системы.
Обратите внимание на различие между субъективным и объективным языком. Субъективные термины основаны на мнении, тогда как объективные термины основаны на данных.
📉 Примеры субъективного и объективного языка
| Субъективный (избегать) | Объективный (цель) |
|---|---|
| Страница должна загружаться быстро. | Страница должна загружаться за 2 секунды при подключении 3G. |
| Система должна быть защищенной. | Пароли должны быть зашифрованы с использованием хеширования SHA-256. |
| Пользователи должны легко ориентироваться в системе. | Пользователи могут добраться до страницы оформления заказа за 3 клика с главной страницы. |
| Отчет должен выглядеть хорошо. | Отчет должен отображать всего 5 столбцов с выровненными заголовками. |
Обратите внимание, как объективные формулировки содержат конкретные метрики, методы или количественные показатели. Это позволяет тестировщику принять решение «прошел/не прошел» без консультации с владельцем продукта.
🛠 Техники написания критериев приемки
Существует несколько форматов документирования критериев приемки. Выбор зависит от зрелости команды и сложности функции. Ниже приведены наиболее эффективные методы.
1. Простые формулировки на естественном языке
Простые повествовательные предложения хорошо подходят для простых функций. Такой подход доступен для заинтересованных сторон без технической подготовки.
- Когда пользователь нажимает кнопку отправки, появляется сообщение об успешном выполнении.
- Когда пользователь вводит недействительный адрес электронной почты, сообщение об ошибке отображается под полем.
- Система не должна разрешать создание дублирующихся учетных записей с одинаковым адресом электронной почты.
2. Синтаксис Gherkin (Дано/Когда/То)
Этот формат тесно связан с разработкой, ориентированной на поведение (BDD). Он структурирует критерии по контексту, действию и результату. Он особенно предпочтителен для сложных рабочих процессов.
- Дано: Пользователь находится на странице входа.
- Когда: Пользователь вводит действительное имя пользователя и пароль.
- То: Система перенаправляет пользователя на панель управления.
Эта структура заставляет автора явно учитывать предварительные условия и ожидаемые результаты.
3. Формат списка контроля
Иногда список условий достаточен, особенно для обновлений пользовательского интерфейса или изменений конфигурации. Каждый элемент представляет собой проверяемое условие.
- Верхнее меню отображает логотип компании.
- Навигационная панель остается неподвижной в верхней части при прокрутке.
- Нижний колонтитул содержит год авторского права и юридические ссылки.
- Форма контакта требует ввода имени и фамилии.
🤝 Стратегии сотрудничества
Написание критериев приемки редко является одиночной задачей. Для этого требуется участие владельца продукта, разработчиков и инженеров по тестированию. Практика «Трех друзей» предполагает совместную встречу этих трех ролей для совместного определения критериев.
Ключевые цели сотрудничества
- Общее понимание:Убедитесь, что все понимают требования одинаково.
- Проверка осуществимости:Разработчики подтверждают, что критерии технически выполнимы.
- Обзор проверяемости:QA обеспечивает, чтобы критерии можно было проверить без неоднозначности.
- Выявление крайних случаев:Группа обсуждает, что происходит, когда возникают неполадки.
Вовлечение QA на раннем этапе написания позволяет выявить потенциальные препятствия до начала кодирования. Это снижает риск обнаружения критических дефектов на поздних этапах цикла.
⚠️ Распространенные ошибки и антипаттерны
Даже опытные команды попадают в ловушки при написании критериев. Признание этих паттернов помогает поддерживать высокое качество.
1. Включение деталей технической реализации
Критерии приемки должны описыватьчто делает система, а некак это делает. Детали реализации должны находиться в технических документах проектирования.
- Плохо: База данных должна использовать таблицу MySQL с именем users.
- Хорошо: Система должна безопасно хранить учетные данные пользователей и извлекать их для аутентификации.
2. Перегрузка нескольких функций
Каждый критерий должен касаться одного конкретного поведения. Сочетание нескольких поведений создает сложное условие, которое трудно протестировать.
- Плохо: Пользователь может войти в систему и увидеть свою фотографию профиля.
- Хорошо: Пользователь может войти в систему. Профиль пользователя отображает загруженное изображение.
3. Избыточное использование отрицательной формулировки
Хотя отрицательное тестирование важно, слишком много утверждений «не должен» может затуманить основной поток.
- Плохо: Система не должна допускать null-значения. Система не должна допускать пустые строки. Система не должна допускать специальные символы.
- Хорошо: Система проверяет поля ввода, чтобы убедиться, что они содержат только буквенно-цифровые символы и не пусты.
4. Пренебрежение нефункциональными требованиями
Функциональные критерии имеют важное значение, но также важны производительность, безопасность и доступность. Их следует включать, если они влияют на пользовательский опыт.
- Время отклика не должно превышать 200 мс для поисковых запросов.
- Интерфейс должен поддерживать навигацию с помощью клавиатуры для всех интерактивных элементов.
- Передача данных должна быть зашифрована с использованием HTTPS.
🧩 Границы и граничные условия
Стандартные сценарии работы легко описываются. Подлинная ценность тестирования заключается в исследовании границ. Критерии приемки должны явно указывать, как система обрабатывает экстремальные или необычные входные данные.
Категории граничных условий
- Нулевые значения: Что происходит, если количество равно 0?
- Максимальные ограничения: Каково максимальное количество символов для текстового поля?
- Состояния null: Как отображается интерфейс, когда данные отсутствуют?
- Параллельные действия: Что происходит, если два пользователя одновременно редактируют одну и ту же запись?
- Сбои в сети: Как система ведет себя при отключении интернета?
Пример критерия граничного условия:
- Если пользователь пытается загрузить файл размером более 50 МБ, система отображает сообщение об ошибке и отклоняет файл.
🔄 Обслуживание и эволюция
Критерии приемки не являются статическими документами. По мере развития продукта критерии также должны изменяться. Рефакторинг кода часто требует обновления критериев, чтобы они соответствовали новому поведению.
Лучшие практики обслуживания
- Проверка во время планирования спринта:Повторно рассмотрите старые истории, чтобы убедиться, что критерии по-прежнему соответствуют текущему поведению.
- Обновление после исправления ошибки: Если ошибка выявляет отсутствующее условие, немедленно добавьте его в критерии приемки.
- Архивирование устаревших критериев: Удалите критерии, которые больше не применимы, чтобы избежать путаницы.
- Контроль версий: Храните историю изменений критериев для целей аудита.
Своевременное обновление критериев гарантирует, что регрессионное тестирование остается эффективным. Устаревшие критерии приводят к ложноположительным результатам, когда тесты проходят, хотя функциональность изменилась.
📊 Оценка качества критериев приемки
Как вы узнаете, работают ли ваши критерии приемки? Используйте метрики для оценки их эффективности с течением времени.
- Покрытие тест-кейсов: Высокое покрытие указывает на четкие критерии. Низкое покрытие свидетельствует о неоднозначности.
- Утечка дефектов: Если ошибки попадают в продакшн, противоречащие критериям приемки, критерии, вероятно, были недостаточными.
- Время уточнения: Отслеживайте, сколько времени QA тратит на задавание вопросов по требованиям. Большое время указывает на плохие критерии приемки.
- Уровень автоматизации: Высокий уровень автоматизации коррелирует с проверяемыми, однозначными критериями.
Регулярные ретроспективы помогут командам обсудить эти метрики и соответствующим образом скорректировать процесс написания.
🔗 Интеграция с определением готовности
Критерии приемки специфичны для пользовательской истории. Определение готовности (DoD) применяется ко всему релизу или спринту. Они работают вместе, но выполняют разные функции.
- DoD: «Весь код проверен», «Все юнит-тесты пройдены», «Документация обновлена». (Глобальные стандарты)
- AC: «Пользователь может сбросить пароль по электронной почте». (Специфичный для функции)
История считается завершённой только тогда, когда выполнены оба критерия приемки и удовлетворены условия завершения. Команды QA должны проверить оба уровня, чтобы подтвердить готовность функции.
💡 Практические примеры
Чтобы закрепить понимание, давайте рассмотрим полный пример пользовательской истории с плохими и улучшенными критериями.
История: функция сброса пароля
❌ Плохие критерии приемки
- Пользователь может сбросить пароль.
- Система отправляет электронное письмо.
- Ссылка устаревает через некоторое время.
- Безопасность имеет важное значение.
✅ Улучшенные критерии приемки
- Предположим, пользователь находится на странице входа, когда он нажимает «Забыли пароль», он перенаправляется на форму сброса.
- Когда пользователь вводит зарегистрированный адрес электронной почты и отправляет форму, на экране появляется сообщение подтверждения.
- Электронное письмо, содержащее уникальную ссылку для сброса, отправляется в течение 5 минут.
- Ссылка для сброса устаревает через 24 часа после генерации.
- Если пользователь вводит неверный код, система отображает ошибку и разрешает повторную попытку.
- Новые пароли должны соответствовать требованиям сложности (8 символов, 1 цифра, 1 символ).
Улучшенная версия позволяет команде QA создавать конкретные тестовые случаи для проверки времени отправки писем, срока действия ссылки и правил сложности пароля.
🚀 Вперед
Написание проверяемых критериев приемки — это навык, который улучшается с практикой. Требуется дисциплина, чтобы избегать неоднозначной лексики, и обязательство к ясности. Сосредоточившись на объективных, проверяемых утверждениях, команды QA могут снизить неоднозначность и обеспечить более высокое качество программного обеспечения.
Начните с аудита текущих историй. Выявите критерии, основанные на мнении или неопределенных метриках. Перепишите их с включением конкретных условий. Поощряйте взаимодействие между ролями для обеспечения общего понимания. Со временем сокращение количества ошибок и повторной работы подтвердит вашу работу.
Помните, цель — не просто написать текст. Цель — определить качество. Когда критерии чёткие, тестирование эффективно, а продукт надёжен.