PrepBro
← Назад к вопросам

Какие знаешь виды требований?

1.2 Junior🔥 191 комментариев
#Процессы и методологии разработки#Тестовая документация

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI23 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Какие знаешь виды требований?

Требования — это описание того, что должно делать приложение. В тестировании нужно знать все виды, чтобы правильно создавать тест-кейсы.

1. Функциональные требования (Functional Requirements)

Описание: что именно должна делать система.

Примеры:

  • Пользователь должен иметь возможность залогиниться
  • При создании заказа должна отправиться квитанция на email
  • Фильтр по цене должен работать от 0 до 100000 рублей

Для QA: пишу тесты, проверяющие, что функция работает как описано.

2. Нефункциональные требования (Non-Functional Requirements)

Описание: как система должна работать (качество, производительность).

Подтипы:

Производительность (Performance)

  • Страница должна грузиться за < 2 секунды
  • API должен обслуживать 1000 запросов в секунду
  • Приложение должно работать с 10000 одновременных пользователей

Надёжность (Reliability)

  • Uptime >= 99.9%
  • MTBF (Mean Time Between Failures) > 100 часов
  • Система не должна потерять данные при сбое

Безопасность (Security)

  • Пароли должны быть зашифрованы
  • Данные передаются по HTTPS
  • Должна быть двухфакторная аутентификация

Масштабируемость (Scalability)

  • При увеличении нагрузки в 10 раз производительность падает не более чем на 20%
  • Система должна масштабироваться горизонтально

Совместимость (Compatibility)

  • Работает в Chrome, Firefox, Safari, Edge
  • Совместимо с iOS 12+ и Android 8+
  • Работает на Windows, macOS, Linux

Юзабилити (Usability)

  • Интерфейс интуитивен для пользователя
  • Time To Task < 3 минут для основного сценария
  • Доступность для людей с ограничениями (WCAG 2.1 AA)

Поддерживаемость (Maintainability)

  • Код должен быть задокументирован
  • 80%+ code coverage тестами
  • Архитектура должна позволять быстро добавлять новые фичи

Для QA: пишу тесты на производительность, нагрузку, безопасность, совместимость.

3. Явные требования (Explicit Requirements)

Описание: требования, явно написанные в спецификации.

Пример: "Кнопка Submit должна быть зелёного цвета (#00AA00) и расположена в нижней части формы."

Для QA: просто проверяю, что соответствует спецификации.

4. Неявные требования (Implicit Requirements)

Описание: требования, которые подразумеваются, но не написаны явно.

Примеры:

  • Форма должна работать при отключённом JavaScript (graceful degradation)
  • Приложение должно показывать понятные error messages
  • При потере интернета должен быть retry или offline mode

Для QA: нужно интуитивно понимать, как должна работать система, и тестировать edge cases.

5. Функциональные требования по областям

Требования к данным (Data Requirements)

  • Какие данные вводит пользователь
  • Какие данные хранит система
  • Какой формат данных (int, string, date)
  • Какие ограничения (минимум, максимум, валидация)

Пример: Email должен соответствовать формату xxx@yyy.zzz и не длиннее 255 символов.

Требования к пользовательским действиям (User Story)

Обычно в формате:

Как [тип пользователя]
Я хочу [действие]
Чтобы [причина]

Пример:
Как неавторизованный пользователь
Я хочу создать аккаунт
Чтобы начать использовать приложение

Для QA: из User Story делаю acceptance criteria (критерии приёмки) и пишу тесты.

6. Требования к интерфейсу (UI/UX Requirements)

  • Кнопки должны быть кликабельны
  • Текст должен быть читаемым (контраст, размер шрифта)
  • Формы должны работать на мобильных
  • Navigation должна быть интуитивной

Для QA: проверяю адаптивность, usability, accessibility.

7. Требования к API (API Requirements)

  • Какие endpoints доступны
  • Какие параметры принимает
  • Какой формат ответа (JSON, XML)
  • Какие HTTP коды возвращает (200, 400, 500)

Пример:

GET /api/users/{id}
Params: none
Response: {
  "id": 123,
  "name": "John",
  "email": "john@example.com"
}
Status codes: 200 OK, 404 Not Found

8. Требования к бизнес-процессам (Business Process Requirements)

  • В каком порядке должны выполняться операции
  • Какие условия для перехода в другое состояние
  • Какие роли и permission нужны

Пример: Заказ может быть создан только авторизованным пользователем. После создания статус = Pending. После оплаты статус = Paid. После отправки статус = Shipped.

Уровни требований

High Level Requirements: общее описание системы "Приложение должно быть платёжной системой"

Detailed Requirements: конкретные требования "При нажатии на кнопку Pay должен открыться модал ввода карты"

Test Cases: конкретные тесты на основе требований "Тест: вводим валидные данные карты → должен быть успешный платёж"

Как QA работает с требованиями

  1. Читаю требования — понимаю, что должна делать система
  2. Выявляю неясности — спрашиваю, если что-то непонятно
  3. Выделяю критерии приёмки — какие условия означают, что требование выполнено
  4. Пишу тест-кейсы — для каждого требования хотя бы один тест
  5. Проверяю реализацию — запускаю тесты против кода

Красные флаги в требованиях

  • Требование слишком расплывчато ("система должна быть быстрой")
  • Требования противоречат друг другу
  • Требования не измеримы (нет метрик)
  • Отсутствуют acceptance criteria
  • Требования меняются каждый день

Мой совет: хорошие требования — основа хорошего тестирования. Если требование неясно, тебе точно не удастся его полностью протестировать.

Какие знаешь виды требований? | PrepBro