QA на практике

Открыто

PAY

PAY-001 КРИТИЧЕСКИЙ

Таймаут платёжного шлюза

Оплата не проходит, когда ответ провайдера занимает более 15 секунд. Пользователи теряют заказы и деньги.

Платежи Таймаут Продакшн

Окружение: Продакшн, Chrome 120, сеть 3G

Шаги воспроизведения:

1. Добавить товар в корзину
2. Перейти к оформлению
3. Ввести данные карты
4. Нажать "Оплатить" на медленном соединении

Фактический результат: Ошибка таймаута "Сессия завершилась" спустя 15 с

Ожидаемый результат: Платёж обрабатывается или показывается кнопка повтора

Рекомендации:

• Увеличить таймаут до 30 секунд
• Добавить механизм повторов (3 попытки)
• Показывать индикатор прогресса

Показать детали

Открыто

PAY

RULE-001 КРИТИЧЕСКИЙ

Processing продолжает поиск транзакций после отклонения Travel Rule

Сервис processing-service продолжает поиск и обработку транзакций даже после того, как сервис Travel Rule возвращает статус отклонения (DECLINED).

Платежи Travel Rule Транзакции

Окружение: Продакшн, Процессинг, Travel Rule

Шаги воспроизведения:

1. Создать инвойс или транзакцию
2. Дождаться запуска проверки Travel Rule
3. Вернуть ответ DECLINED от сервиса Travel Rule
4. Проверить логи processing-service и активность очередей
5. Убедиться, что поиск транзакции продолжается после отклонения

Фактический результат: Processing-service продолжает поиск и обработку транзакций после отклонения проверки Travel Rule.

Ожидаемый результат: Processing-service должен немедленно прекращать поиск и дальнейшую обработку транзакций после получения статуса отклонения от Travel Rule.

Рекомендации:

• Немедленно завершать transaction-search после статуса DECLINED
• Добавить early-stop механизм для processing pipeline
• Блокировать создание новых processing jobs после отказа Travel Rule
• Добавить guard-check перед каждым этапом обработки транзакции
• Логировать причину остановки processing flow
• Покрыть сценарий integration и e2e тестами

Показать детали

Открыто

RPC

RPC-018 КРИТИЧЕСКИЙ

Polygon RPC provider возвращает некорректные block data

Polygon RPC провайдеры (Infura, Alchemy, GetBlock) периодически возвращают некорректные block payloads, которые не проходят десериализацию из-за DeserError: BlockTransactions во время обработки блоков.

Polygon RPC EIP-4844

Окружение: Продакшн, Polygon RPC, Infura / GetBlock

Шаги воспроизведения:

1. Подключиться к Polygon RPC через Infura или Alchemy
2. Запросить block data через eth_getBlockByNumber
3. Попытаться десериализовать BlockTransactions
4. Проверить появление периодических DeserError

Фактический результат: Десериализация блоков периодически завершается ошибкой DeserError, из-за чего RPC backend пропускает затронутые блоки.

Ожидаемый результат: Block data должны корректно десериализоваться, включая поддержку EIP-4844 blob transactions.

Рекомендации:

• Обновить логику десериализации транзакций для поддержки EIP-4844
• Добавить fallback parsing для неизвестных transaction variants
• Реализовать retry и provider failover для некорректных RPC-ответов
• Логировать номера проблемных блоков и ответы провайдеров
• Валидировать RPC payload schema перед обработкой транзакций
• Покрыть blob transaction сценарии regression и integration тестами

Показать детали

Открыто

INV

INV-024 КРИТИЧЕСКИЙ

Crypto invoice ожидает полный timeout без обнаруженного депозита

Crypto invoices остаются в состоянии AwaitingCryptoDeposit до полного expires_at timeout (5-10+ часов), даже если blockchain transaction так и не была обнаружена, что создает плохой UX в payment widget.

Payments Crypto Invoices

Окружение: Продакшн, payment-invoices, crypto payment widget

Шаги воспроизведения:

1. Создать crypto invoice и открыть payment widget
2. Проверить состояние AwaitingCryptoDeposit
3. Не отправлять crypto transaction
4. Дождаться окончания deposit detection window
5. Убедиться, что invoice продолжает ожидание до expires_at

Фактический результат: Invoice остается активным в течение полного timeout периода (5-10+ часов). Step_02 продолжает polling oracle-pool примерно каждые 2 минуты и получает ответы "Transaction still not found", в то время как widget продолжает показывать "awaiting payment".

Ожидаемый результат: Invoices без обнаруженных blockchain transactions должны завершаться раньше после окончания deposit detection window, тогда как полный expires_at timeout должен применяться только после обнаружения транзакции.

Рекомендации:

• Реализовать two-tier timeout логику для crypto invoices
• Добавить early expiry для invoices без обнаруженных транзакций
• Сохранять возможность cancel во время deposit detection window
• Не завершать invoice, если oracle-pool уже обнаружил in-flight transaction
• Отписывать oracle-pool listeners при любом expiry state
• Вынести invoice timeout values в configurable environment variables

Показать детали

Открыто

C2F

C2F-011 КРИТИЧЕСКИЙ

GetInvoice возвращает 500 после oracle-pool callback

После получения oracle-pool callback endpoint GetInvoice возвращает 500 Internal Server Error вместо корректного invoice object.

Payments Oracle Pool Invoices

Окружение: Development, payment-invoices, oracle-pool callback flow

Шаги воспроизведения:

1. Создать invoice через PaymentInvoicesService.CreateInvoice
2. Убедиться, что invoice имеет статус pending.awaiting_crypto_deposit
3. Вызвать GetInvoice и проверить, что endpoint работает до callback
4. Отправить POST /v1/callbacks/oracle-pool со status=1 и confirmations=1
5. Повторно вызвать GetInvoice для того же invoice_id

Фактический результат: GetInvoice возвращает 500 Internal Server Error после обработки oracle-pool callback.

Ожидаемый результат: GetInvoice должен возвращать корректный invoice object с обновленным статусом: pending.awaiting_checks, pending.awaiting_exchange или expired.

Рекомендации:

• Проверить invoice state transitions после oracle-pool callback
• Добавить null и schema validation перед invoice serialization
• Логировать callback payloads и invoice state mutations для debugging
• Не допускать некорректные invoice states в GetInvoice response mapping
• Добавить fallback error handling для malformed callback data
• Покрыть callback-to-GetInvoice flow integration и regression тестами

Показать детали

Подтверждено

AUTH

AUTH-042 ВЫСОКИЙ

Токен сессии в URL

Токен аутентификации виден в адресной строке браузера, что позволяет перехват через историю браузера или логи прокси.

Безпека OAuth Токен

Окружение: Все браузеры, после OAuth-входа

Шаги воспроизведения:

1. Нажать "Войти через Google"
2. Завершить OAuth-авторизацию
3. Проверить URL после редиректа

Фактический результат: Токен виден: site.com/home?token=abc123

Ожидаемый результат: Токен хранится только в httpOnly cookie

Рекомендации:

• Убрать токен из URL-параметров
• Використовувати secure cookie з SameSite=Strict
• Проверить логи доступа на наличие токенов

Показать детали

Подтверждено

UI

UI-089 СРЕДНИЙ

Накладання меню на iPhone SE

Пункты меню навигации накладываются друг на друга на экранах меньше 375px.

Интерфейс Адаптивность Мобильная версия

Окружение: iOS Safari, iPhone SE (375×667)

Шаги воспроизведения:

1. Открыть сайт на iPhone SE
2. Натиснути на меню-бургер
3. Посмотреть расположение пунктов меню

Фактический результат: Пункты меню накладываются, часть из них недоступна

Ожидаемый результат: Все пункты меню видны и кликабельны

Рекомендации:

• Добавить media query для экранов <375px
• Уменьшить размер шрифта или отступы
• Тестувати на реальному iPhone SE

Показать детали

Подтверждено

SYNC

SYNC-014 ВЫСОКИЙ

Потеря черновика после обновления страницы

Последние изменения в длинной форме исчезают, если пользователь обновляет страницу во время задержки автосохранения.

Втрата даних Автозбереження Safari

Окружение: Стейджинг, Safari 17, нестабильный Wi-Fi

Шаги воспроизведения:

1. Открыть длинную форму с автосохранением
2. Вводить данные 20-30 секунд
3. Обновить страницу во время синхронизации

Фактический результат: Последние изменения исчезают без предупреждения

Ожидаемый результат: Черновик восстанавливается или показывается предупреждение о несохранённых изменениях

Рекомендации:

• Хранить несинхронизированное состояние локально
• Добавить индикатор состояния синхронизации
• Предупреждать перед перезагрузкой при наличии несохранённых изменений

Показать детали

Открыто

ROLE

ROLE-031 КРИТИЧЕСКИЙ

Эскалация прав через кеш ролей

После отзыва админ-прав пользователь ещё некоторое время может выполнять защищённые действия.

Окружение: Продакшн, SaaS админ-панель

Шаги воспроизведения:

1. Снять роль администратора с существующего пользователя
2. Не завершать текущую сессию
3. Попробовать выполнить админ-действия

Фактический результат: Часть админ-эндпоинтов остаётся доступной до протухания кеша

Ожидаемый результат: Изменения ролей применяются сразу после обновления прав

Рекомендации:

• Инвалидировать кеш ролей после обновления прав
• Проверять роли на сервере для чувствительных действий
• Логировать попытки доступа после отзыва прав

Показать детали

Подтверждено

AN

AN-022 СРЕДНИЙ

Событие покупки не попадает в аналитику

Успешный заказ создаётся, но событие покупки не отправляется после оформления в один клик.

Аналитика GA4 Оформлення

Окружение: Продакшн, GA4 + внутренний BI-конвейер

Шаги воспроизведения:

1. Запустить оформление в один клик с сохранённой картой
2. Успешно завершить оплату
3. Проверить сетевые запросы и дашборд аналитики

Фактический результат: Заказ создан, но событие выручки отсутствует

Ожидаемый результат: Событие покупки отправляется один раз с корректной суммой и ID заказа

Рекомендации:

• Запускать аналитику только после подтверждённого backend-успеха
• Добавить оповещения о просадке событий покупки
• Покрыть checkout-сценарии отдельным regression-набором

Показать детали

Подтверждено

CHK

PERF-017 СРЕДНИЙ

Сброс фильтров после пагинации каталога

После перехода на вторую страницу каталога активные фильтры исчезают, а список товаров меняется без предупреждения.

Каталог Фильтры Пользовательский опыт

Окружение: Продакшн, Chrome 123, десктопный каталог

Шаги воспроизведения:

1. Открыть каталог товаров
2. Применить 2-3 фильтра и сортировку
3. Перейти на вторую страницу результатов

Фактический результат: Фильтры сбрасываются, показываются нефильтрованные товары

Ожидаемый результат: Фильтры сохраняются при пагинации

Рекомендации:

• Добавить фильтры в URL-параметры
• Использовать History API для навигации
• Хранить состояние фильтров в sessionStorage

Показать детали

Открыто

PDF

FILE-055 ВЫСОКИЙ

PDF-счёт доступен после выхода из аккаунта

Ссылка на инвойс продолжает открывать документ даже после завершения пользовательской сессии.

Безпека PDF Доступ

Окружение: Продакшн, клиентский портал, история инвойсов

Шаги воспроизведения:

1. Войти в аккаунт и открыть историю счетов
2. Скопировать прямую ссылку на PDF
3. Выйти из аккаунта и открыть ссылку в новой вкладке

Фактический результат: Документ скачивается без повторной проверки доступа

Ожидаемый результат: Доступ к файлу блокируется или требует новой авторизации

Рекомендации:

• Проверять авторизацию на уровне файлового эндпоинта
• Использовать короткоживущие подписанные URL
• Добавить аудит доступа к чувствительным документам

Показать детали

Открыто

SQL

SQL-008 КРИТИЧЕСКИЙ

SQL-инъекция в поисковом поле

Поле поиска не экранирует спецсимволы, позволяя выполнять произвольные SQL-запросы.

Безпека SQL-инъекция Пошук

Окружение: Продакшн, поиск товаров, PostgreSQL 14

Шаги воспроизведения:

1. Открыть каталог товаров
2. Ввести в пошук: '; DROP TABLE orders; --
3. Натиснути Enter

Фактический результат: Запрос выполняется без санитизации, возможна потеря данных

Ожидаемый результат: Спецсимволы экранируются, поиск безопасен

Рекомендации:

• Использовать параметризованные запросы (prepared statements)
• Добавить валидацию ввода на уровне API
• Включить WAF-правила для SQL-инъекций

Показать детали

Подтверждено

WARN

XSS-003 ВЫСОКИЙ

XSS через поле отзыва

Отзывы пользователей отображаются без экранирования HTML, позволяя выполнять скрипты.

Безпека XSS Отзывы

Окружение: Продакшн, страница товара, раздел отзывов

Шаги воспроизведения:

1. Открыть любой товар
2. Добавить отзыв с текстом: <script>alert('XSS')</script>
3. Сохранить отзыв

Фактический результат: Скрипт выполняется при просмотре отзыва другими пользователями

Ожидаемый результат: HTML-теги экранируются, текст отображается как текст

Рекомендации:

• Использовать textContent вместо innerHTML
• Добавить CSP-заголовки
• Провести аудит всех мест вывода пользовательских данных

Показать детали

Подтверждено

TMO

RATE-007 СРЕДНИЙ

Отсутствие ограничения частоты запросов на API

API-эндпоинт для смены пароля не имеет ограничений на количество запросов.

API Ограничение запросов Перебор

Окружение: Продакшн, API-эндпоинт /api/v1/password-reset

Шаги воспроизведения:

1. Отправить запрос на смену пароля
2. Повторить запрос 100+ раз за минуту
3. Проверить ответы сервера

Фактический результат: Все запросы обрабатываются, возможен перебор токенов

Ожидаемый результат: После 5 неудачных попыток — временная блокировка

Рекомендации:

• Добавить rate limiting (5 запросов в минуту)
• Внедрить exponential backoff
• Логировать подозрительную активность

Показать детали

Открыто

EXP

UPLOAD-012 ВЫСОКИЙ

Загрузка исполняемых файлов

Форма загрузки аватара принимает любые типы файлов, включая .exe и .php.

Безпека Загрузка файлов Валидация

Окружение: Продакшн, профиль пользователя, загрузка аватара

Шаги воспроизведения:

1. Открыть настройки профиля
2. Выбрать файл shell.php вместо изображения
3. Загрузить файл

Фактический результат: Файл загружается и доступен по прямой ссылке

Ожидаемый результат: Ошибка валидации — разрешены только изображения

Рекомендации:

• Валидировать MIME-тип и расширение файла
• Проверять magic bytes файла
• Хранить файлы вне web-root с переименованием

Показать детали

Открыто

PAY

PAY-014 КРИТИЧЕСКИЙ

Повторное списание после повторной оплаты

Если пользователь повторно нажимает оплату после долгого ответа провайдера, создаются два успешных списания для одного заказа.

Платежи Двойное списание Checkout

Окружение: Продакшн, checkout, Stripe fallback flow

Шаги воспроизведения:

1. Оформить заказ с банковской картой
2. Дождаться задержки ответа платёжного провайдера
3. Повторно нажать кнопку "Оплатить"

Фактический результат: Создаются два успешных платежа и дублирующий webhook

Ожидаемый результат: Повторное нажатие блокируется, платёж обрабатывается один раз

Рекомендации:

• Добавить idempotency key для каждого платёжного запроса
• Блокировать кнопку после первого клика до ответа провайдера
• Отдельно логировать дублирующиеся webhooks и reconciliation case

Показать детали

Подтверждено

BIL

PAY-029 СРЕДНИЙ

Некорректное округление суммы при частичной оплате

При частичной оплате бонусами итоговая сумма в checkout отличается от суммы, которая передаётся в платёжный провайдер.

Платежи Округление Бонусы

Окружение: Продакшн, бонусный баланс, частичная оплата картой

Шаги воспроизведения:

1. Добавить товар с копейками в корзину
2. Применить бонусный баланс на часть суммы
3. Перейти к подтверждению оплаты картой

Фактический результат: На странице показана одна сумма, а у провайдера формируется другая

Ожидаемый результат: Сумма в UI, backend и у провайдера полностью совпадает

Рекомендации:

• Унифицировать правила округления между клиентской и серверной частями
• Работать с минимальными денежными единицами вместо чисел с плавающей точкой
• Добавить автотесты для бонусных и смешанных оплат

Показать детали

Подтверждено

AN

AN-031 ВЫСОКИЙ

Событие возврата не попадает в аналитику

После успешного refund в админ-панели событие возврата не попадает ни в GA4, ни во внутренний финансовый дашборд.

Аналитика Refund Финансы

Окружение: Продакшн, админ-панель, refund workflow

Шаги воспроизведения:

1. Открыть оплаченный заказ в админ-панели
2. Выполнить частичный или полный возврат
3. Проверить аналитические события и BI-дашборд

Фактический результат: Refund завершён, но событие о возврате не отправляется

Ожидаемый результат: Аналитика обновляется сразу после успешного refund

Рекомендации:

• Отправлять отдельную refund event после подтверждения backend-статуса
• Добавить мониторинг разрыва между orders и refunds в аналитике
• Покрыть refund flow отдельным regression-сценарием

Показать детали

Открыто

UTM

AN-044 СРЕДНИЙ

Потеря UTM-меток после входа в аккаунт

После логина пользователя атрибуция кампании сбрасывается, и заказы попадают в отчётность как direct / none.

Аналитика UTM Атрибуция

Окружение: Продакшн, multi-step login перед checkout

Шаги воспроизведения:

1. Открыть лендинг с UTM-метками
2. Перейти к товару и войти в аккаунт
3. Завершить checkout и проверить source / medium

Фактический результат: Заказ регистрируется как direct / none без кампании

Ожидаемый результат: Исходные UTM-метки сохраняются до завершения покупки

Рекомендации:

• Сохранять attribution state в sessionStorage или server session
• Не перезаписывать source после auth redirect
• Добавить проверки для login-to-checkout funnel

Показать детали