Что такое Acceptance Criteria и как их правильно формулировать?

Acceptance Criteria: Определение и Формулировка

Acceptance Criteria — это четкий набор условий, которые должны быть выполнены для того, чтобы task/user story считался готовым. Это контракт между product manager и разработчиком.

Почему Acceptance Criteria критичны

Без AC:

• Разработчик гадает, что нужно сделать
• Тестер не понимает, как проверять
• Вопросы во время разработки требуют clarifications
• Код перепишется 3 раза
• Задача считается то сделанной, то нет

С хорошими AC:

• Разработчик знает точно, что делать
• Тестер знает, как проверять
• Минимум вопросов
• Код пишется один раз
• Все согласны, когда задача done

Формат: Given-When-Then (сценарный подход)

Это наиболее мощный и понятный формат:

Given [начальное состояние]
When [пользователь делает это]
Then [ожидаемый результат]

Реальный пример 1: Функция "Добавить в избранное"

Хорошо сформулированные AC:

Feature: Add to Favorites

Scenario 1: User adds product to favorites
  Given user is logged in
  When user clicks heart icon on product card
  Then product is added to favorites
  And heart icon becomes filled (red)
  And "Added to favorites" toast appears for 3 seconds
  And product appears in /favorites section

Scenario 2: User removes from favorites
  Given product is in user's favorites
  When user clicks filled heart icon
  Then product is removed from favorites
  And heart icon becomes outline (gray)
  And product disappears from /favorites section

Scenario 3: Anonymous user tries to add to favorites
  Given user is not logged in
  When user clicks heart icon
  Then redirect to /login page
  And previous page URL is saved in redirect_to parameter
  And heart icon does NOT change

Scenario 4: Network error
  Given user clicks heart icon
  When network error occurs (500, timeout, no connection)
  Then heart icon state reverts to previous
  And error toast appears: "Failed to save. Please try again"
  And retry button is shown

Реальный пример 2: Импорт контактов

Задача: User story: "Как пользователь, я хочу импортировать контакты из CSV"

Acceptance Criteria:

## Functional Requirements

1. File Upload
   Given user is on /contacts/import page
   When user clicks "Choose file" button
   Then file picker opens
   And accepted formats: CSV only
   And max file size: 5MB
   And error shown if file > 5MB: "File too large. Max 5MB"

2. File Parsing
   Given user selects valid CSV file
   When user clicks "Upload"
   Then file is parsed
   And progress bar shows upload progress (0-100%)
   And expected columns: first_name, last_name, email, phone (optional)
   And error shown if required columns missing

3. Validation
   Given CSV is parsed
   When validation runs
   Then duplicate emails (already in system) are marked
   And invalid emails are marked with red flag
   And summary shown: "100 valid, 5 duplicates, 2 invalid"

4. Preview & Confirmation
   Given validation complete
   When user sees preview
   Then table shows first 10 rows
   And pagination shows "Showing 1-10 of 100"
   And user can mark duplicates for skip
   And checkbox to select all/none

5. Import
   Given user clicks "Import"
   When import starts
   Then progress bar shows percent
   And estimated time remaining shown
   And user CAN close dialog (import continues in background)
   And notification when complete: "Imported 98 contacts"

## Non-Functional Requirements

- Performance: Import < 30 seconds for 1000 contacts
- Security: File uploaded to secure temp storage, deleted after import
- Error Handling: No partial imports (all or nothing transaction)
- Browser: Works in Chrome 90+, Firefox 88+, Safari 14+
- Mobile: Works on iOS/Android with file upload

Структурированный шаблон AC

## Acceptance Criteria

ACTOR: [кто] (user, admin, system)

PREREQUISITES:
- User is logged in
- Product exists in database
- User has permission to edit

SCENARIOS:

### Scenario 1: Happy Path
Given [initial state]
When [user action]
Then [expected result]
And [additional validation]

### Scenario 2: Alternative Flow
Given [initial state]
When [different action]
Then [different result]

### Scenario 3: Error Case
Given [error condition]
When [user action]
Then [error handling]
And [error message shown]

### Scenario 4: Edge Case
Given [boundary condition]
When [user action]
Then [handled correctly]

## Non-Functional Requirements

- Performance: <200ms response time
- Accessibility: WCAG 2.1 AA compliant
- Browser Support: Chrome, Firefox, Safari, Edge (latest 2 versions)
- Mobile: Responsive on 320px+ width
- Security: All inputs validated and sanitized
- Localization: Support for en, ru, de

## Out of Scope
- [что мы НЕ делаем в этом task]
- [чтобы избежать scope creep]

Типичные ошибки при формулировке AC

❌ Плохо: Слишком расплывчато

AC: User can add items to cart
AC: System should handle errors
AC: Performance is acceptable

✅ Хорошо: Конкретно и проверяемо

AC: When user clicks "Add to Cart" with valid quantity,
    item is added to cart within 200ms
AC: If quantity > available stock,
    error message shows "Only X items available"
AC: Page load time < 2s on 4G connection

❌ Плохо: Содержит реализацию

AC: Frontend sends POST request to /api/cart/add
AC: Backend validates using Pydantic

✅ Хорошо: Фокус на поведении, не реализации

AC: User receives confirmation when item is added
AC: Invalid quantities are rejected with clear error

❌ Плохо: Двусмысленно

AC: Price should be calculated correctly

✅ Хорошо: Точный расчет

AC: Total price = (item_price * quantity) + tax + shipping
AC: Tax calculated based on user's location (state/country)
AC: Discount codes reduce total BEFORE tax

Мой процесс создания хороших AC

Шаг 1: Понять user story

Как [actor], я хочу [action], 
чтобы [benefit]

Шаг 2: Определить happy path

Какой самый частый сценарий использования?

Шаг 3: Добавить alternative flows

Что если user делает что-то другое?

Шаг 4: Добавить error cases

Что если что-то сломается?

Шаг 5: Добавить NFR (non-functional)

Производительность? Безопасность? Доступность?

Шаг 6: Review с разработчиком

Можно ли это реализовать в sprint?
Что-то неясно?

Реальный пример из проекта

Задача: Payment processing

User Story:
Как покупатель, я хочу оплатить заказ,
чтобы завершить покупку

AC:

1. Payment Method Selection
   Given user is on checkout page
   When user selects payment method (card, PayPal, Apple Pay)
   Then selected method is highlighted
   And form changes to method-specific fields

2. Card Payment - Happy Path
   Given user selects "Card" payment
   When user enters valid card number, expiry, CVC
   And clicks "Pay"
   Then:
     - Loading spinner shows for 2-5 seconds
     - Success page shown
     - Order confirmation email sent
     - User redirected to /orders/{order_id}

3. Card Payment - Invalid Card
   Given user enters invalid card number
   When user clicks "Pay"
   Then:
     - Error message: "Invalid card number"
     - Card field highlighted in red
     - Payment not processed
     - User can retry

4. Network Error
   Given payment is being processed
   When network error occurs
   Then:
     - Loading stops
     - Error message: "Connection lost. Please try again"
     - "Retry" button shown
     - Order status: pending (not completed, not failed)
     - User can retry without double-charging

5. Timeout
   Given user clicks "Pay"
   When request takes > 30 seconds
   Then:
     - Loading spinner stops
     - Error message: "Payment timeout. Try again?"
     - Status checked via /orders/{order_id}/status endpoint

NFR:
- PCI DSS compliant (no card data stored)
- Payment processing < 5 seconds
- 99.9% uptime
- Supports currencies: USD, EUR, GBP

Tools для AC

• Jira / Linear — прямо в task description
• Confluence — для более сложных requirements
• Cucumber/BDD — для автоматизированного тестирования
• Figma — для визуальных AC (screenshot с аннотациями)

Когда AC готовы

• ✅ Каждое условие проверяемо (не"good" а"< 200ms")
• ✅ Нет двусмысленности (все согласны на определение)
• ✅ Разработчик может начать кодить
• ✅ Тестер может написать test cases
• ✅ Возможные ошибки и edge cases учтены

Хорошие AC — это инвестиция в качество, скорость разработки и минимизацию рисков.