QAForge
Посмотрите, как требования превращаются в тест-кейсы, чек-листы и другие QA-артефакты.
QAForge не заменяет QA-инженеров. Он помогает уменьшить рутинное форматирование и ускоряет подготовку тестовых артефактов, а смысл, полнота и риски остаются на ручной проверке специалиста.
Техника: Equivalence Partitioning + Boundary Value Analysis
Вместо пары проверок valid/invalid пример показывает классы эквивалентности, границы и точные ожидаемые результаты.
Техника: Decision Table Testing
Таблица решений убирает хаотичные проверки и показывает, какие комбинации условий дают разные действия.
Техника: State Transition Testing
Проверки строятся вокруг состояний кода и разрешённых переходов, а не вокруг одной успешной авторизации.
Техника: Checklist-Based Testing
Чек-лист показывает широкое покрытие области без длинного сценария на десятки шагов.
Техника: API validation + boundary checks
API-пример фиксирует контракт: поля, типы, границы, авторизацию, статусы и тело ошибки.
Техника: Risk-oriented lifecycle testing
Платёжный пример показывает lifecycle, idempotency и согласованность бизнес-состояний.
Границы
Границы · Web / Финансы
Форма перевода принимает целую сумму в RUB от 100 до 500000 включительно. Перевод создаётся только для допустимого целого значения.
1. Сумма 99 RUB отклоняется как значение ниже минимума
Ожидаемый результат: Система отклоняет значение 99, показывает сообщение о минимальной сумме 100 ₽, перевод не создаётся.
2. Сумма 100 RUB принимается как нижняя граница
Ожидаемый результат: Кнопка отправки активна, перевод создаётся на 100 ₽, в подтверждении указана ровно эта сумма.
3. Сумма 500000 RUB принимается как верхняя граница
Ожидаемый результат: Перевод создаётся на 500000 ₽, предупреждение о превышении лимита не отображается.
4. Сумма 500001 RUB отклоняется как превышение лимита
Ожидаемый результат: Система показывает сообщение о максимальной сумме 500000 ₽, перевод не создаётся и баланс не меняется.
5. Дробное значение 100.50 RUB отклоняется
Ожидаемый результат: Поле сообщает, что сумма должна быть целым числом в RUB, запрос на перевод не отправляется.
Такой набор показывает риск на соседних значениях 99/100/101 и 499999/500000/500001. Это лучше, чем просто написать “проверить валидную и невалидную сумму”, потому что дефекты часто возникают именно на границах.
Таблицы решений
Таблицы решений · Web / Checkout
Промокод применяется только если он существует, активен, не истёк, сумма корзины не меньше 3000 ₽ и пользователь не использовал его раньше.
1. R1: все условия выполнены
Ожидаемый результат: Скидка появляется в блоке итогов, итоговая сумма пересчитана, повторное применение того же кода не добавляет вторую скидку.
2. R4: промокод истёк при остальных выполненных условиях
Ожидаемый результат: Система показывает сообщение об истечении срока, скидка не применяется, корзина остаётся без изменений.
3. R5: сумма корзины 2999 ₽
Ожидаемый результат: Промокод отклоняется с сообщением о минимальной сумме 3000 ₽, скидка не появляется в итогах.
4. R6: пользователь уже использовал промокод
Ожидаемый результат: Промокод отклоняется для текущего пользователя, но сам код остаётся активным для других пользователей.
Репрезентативные правила уменьшают дубли и бессмысленные кейсы. QA видит, какое условие меняет действие системы, а не получает десять похожих проверок без логики покрытия.
Состояния
Состояния · Web / Auth
Пользователь входит по одноразовому OTP-коду. Код истекает через 5 минут. После 3 неверных попыток код блокируется. Новый код сбрасывает счётчик попыток.
1. Переход no_code -> code_sent при запросе OTP
Ожидаемый результат: Создаётся новый OTP, состояние становится code_sent, счётчик неверных попыток равен 0, старый код недоступен.
2. Третья неверная попытка переводит код в code_blocked
Ожидаемый результат: После третьей неверной попытки код переходит в состояние blocked, дальнейшая проверка этого кода невозможна.
3. Истёкший код не может перейти в code_verified
Ожидаемый результат: Через 5 минут система отклоняет даже правильный код, показывает сообщение об истечении и предлагает запросить новый.
4. Новый код после блокировки сбрасывает попытки
Ожидаемый результат: Новый OTP получает состояние code_sent, счётчик попыток равен 0, заблокированный код остаётся недействительным.
Lifecycle-подход помогает не пропустить ошибки с истечением, блокировкой, повторным запросом и использованием старых кодов.
Чек-листы
Чек-листы · Web / Mobile
Пользователь может редактировать имя, аватар, телефон и настройки уведомлений в профиле.
1. Изменение имени сохраняется во всех местах отображения
Ожидаемый результат: Новое имя видно в профиле, меню аккаунта и карточке автора без ручной очистки кеша.
2. Ошибка загрузки аватара не удаляет текущий аватар
Ожидаемый результат: При неподдерживаемом формате файла отображается понятная ошибка, прежний аватар остаётся активным.
3. Редактирование чужого профиля запрещено
Ожидаемый результат: Запрос завершается 403 или безопасным отказом, данные другого пользователя не меняются.
Чек-лист полезен, когда нужно быстро пройти много независимых аспектов: функциональность, валидацию, права, сохранение и синхронизацию между сессиями.
API
API · REST API
POST /orders создаёт заказ. Поля: product_id обязательная строка, quantity целое число 1..99, delivery_date опциональная ISO-дата не в прошлом, auth token обязателен.
1. Валидный запрос с quantity=1
Ожидаемый результат: API возвращает 201, тело содержит order_id и status=created, заказ связан с авторизованным пользователем.
2. quantity=0 отклоняется по нижней границе
Ожидаемый результат: API возвращает 422 с кодом ошибки quantity_out_of_range, заказ не создаётся.
3. product_id отсутствует
Ожидаемый результат: API возвращает 400 с ошибкой required_field: product_id, побочных эффектов нет.
4. Отсутствует auth token
Ожидаемый результат: API возвращает 401, тело ошибки не раскрывает внутренние детали авторизации, заказ не создаётся.
5. delivery_date в прошлом
Ожидаемый результат: API возвращает 422 с кодом delivery_date_in_past, остальные валидные поля не сохраняются как черновик заказа.
API-тесты должны проверять не только “ошибка отображается”, а точный HTTP-статус, код ошибки, отсутствие side effects и границы допустимых значений.
Платежи
Платежи · Web / SaaS billing
SaaS-подписка оплачивается через внешнего платёжного провайдера. Доступ активируется только после подтверждения платежа, а после успешного возврата платный доступ завершается.
1. checkout_created не активирует тариф
Ожидаемый результат: В БД создан payment intent со status=pending, текущий тариф пользователя не меняется, лимиты не увеличиваются.
2. payment_succeeded активирует подписку один раз
Ожидаемый результат: Подписка получает status=active и выбранный plan, usage counters соответствуют новому тарифу, повторная обработка того же события не меняет период повторно.
3. payment_canceled не меняет текущий доступ
Ожидаемый результат: Payment intent получает status=canceled, subscription остаётся прежней, платные лимиты не выдаются.
4. refund_succeeded завершает платный доступ
Ожидаемый результат: Подписка переводится на Free-поведение, current_period_end становится текущим временем, история платежа и возврата сохраняется.
5. Повторный webhook с тем же provider_event_id безопасен
Ожидаемый результат: Событие распознаётся как уже обработанное, вторая подписка не создаётся и лимиты не увеличиваются повторно.
В платёжных сценариях важно проверять не только экран оплаты, но и состояние подписки, usage-лимиты, повторные события и поведение после refund.
Одна AI-генерация доступна без регистрации. Войдите, чтобы сохранять историю и продолжить работу.