Приведи пример критерия требования

Пример критерия требования: Проверка функциональности формы авторизации

Давайте рассмотрим конкретный пример критерия требования для функции "Форма входа пользователя" в веб-приложении. Этот критерий переводит общее требование "Пользователь должен иметь возможность войти в систему" в набор проверяемых условий и сценариев.

Исходное требование (User Story)

Как зарегистрированный пользователь, Я хочу вводить свои учетные данные на странице входа, Чтобы получить доступ к своей персональной учетной записи.

Пример критериев приемки (Acceptance Criteria)

Критерии формализуют это требование, делая его однозначным и тестируемым.

AC-1: Успешная аутентификация с валидными данными

• Дано: Пользователь находится на странице входа.
• Когда: Пользователь вводит зарегистрированный email и корректный пароль в соответствующие поля и нажимает кнопку "Войти".
• Тогда: Система аутентифицирует пользователя и выполняет перенаправление на главную страницу его личного кабинета.
• И: В заголовке страницы отображается приветствие: "Добро пожаловать, [Имя_Пользователя]".
• И: Сессия пользователя становится активной.

AC-2: Обработка неверных учетных данных

• Дано: Пользователь находится на странице входа.
• Когда: Пользователь вводит валидный email, но неверный пароль (или email не существует в системе) и нажимает "Войти".
• Тогда: Система НЕ предоставляет доступ.
• И: Над формой входа отображается общее сообщение об ошибке: "Неверный email или пароль".
• И: Поля "Email" и "Пароль" очищаются (или остается только введенный email, в зависимости от политики безопасности).
• И: Сессия пользователя НЕ создается.

AC-3: Валидация обязательных полей на стороне клиента

• Дано: Пользователь находится на странице входа.
• Когда: Пользователь оставляет поле "Email" или "Пароль" пустым.
• И: Пользователь нажимает на кнопку "Войти" или переводит фокус с пустого поля.
• Тогда: Под соответствующим пустым полем немедленно появляется сообщение: "Поле обязательно для заполнения".
• И: Кнопка "Войти" может быть неактивна (опциональный, но хороший критерий UX).

AC-4: Формат поля "Email"

• Дано: Пользователь находится на странице входа.
• Когда: Пользователь вводит в поле "Email" строку в невалидном формате (например, user@ или userexample.com).
• И: Пользователь переводит фокус с поля.
• Тогда: Под полем "Email" появляется сообщение: "Введите корректный адрес электронной почты".

Почему это хорошие критерии?

Эти примеры соответствуют ключевым принципам SMART и качества требований:

• Конкретные (Specific): Четко описаны условия, действия и результаты (например, "перенаправление на главную страницу личного кабинета").
• Измеримые (Measurable): Результат бинарный — либо произошло, либо нет (редирект, сообщение появилось).
• Достижимые (Achievable): Технически реализуемы и соответствуют рамкам задачи.
• Релевантные (Relevant): Прямо вытекают из пользовательской истории.
• Ограниченные по времени (Time-bound): Подразумевается, что отклик системы должен быть мгновенным.

Практическое применение в тестировании

На основе этих критериев QA-инженер строит тест-кейсы. Например, для AC-1 тест может выглядеть так:

Feature: Авторизация пользователя
  Scenario: Успешный вход с валидными данными
    Given Я открыл страницу входа "/login"
    When Я ввожу "testuser@example.com" в поле "Email"
    And Я ввожу "SecurePass123" в поле "Пароль"
    And Я нажимаю кнопку "Войти"
    Then Я должен быть перенаправлен на страницу "/dashboard"
    And На странице должен отображаться текст "Добро пожаловать, TestUser"

Для тестирования этих сценариев инженеру потребуются как предварительные данные (зарегистрированный пользователь testuser@example.com с паролем SecurePass123), так и тестовые сценарии негативной проверки (использование несуществующего email, SQL-инъекции в поле пароля, проверка на чувствительность к регистру).

Таким образом, критерии приемки служат мостом между бизнес-требованием и конкретными, автоматизируемыми проверками, обеспечивая полное и однозначное понимание "готовности" функциональности всеми участниками команды (Product Owner, разработчиками, тестировщиками).