Как проверяешь тесты на предпериоде?

Как проверяешь тесты на предпериоде

Предпериод (pre-production, staging, QA environment) — это критический этап перед запуском на продакшен. BA должен убедиться, что все требования реализованы и протестированы так, как это будет работать в реальной жизни. Вот структурированный подход.

Что такое тестирование на предпериоде

Предпериод — это копия продакшена со своими данными и пользователями. Здесь:

• Разработка уже завершена
• Код залит в ветку staging
• Данные похожи на реальные, но это не реальные данные
• Нет реальных пользователей, только QA и BA

Роль BA в тестировании

BA — это мост между требованиями и тестировщиком. BA отвечает за:

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

Подготовка к тестированию на предпериоде

1. Чек-лист требований Создать таблицу: требование → тест-кейс → статус тестирования

Пример:

2. Тестовые данные

• Какие данные нужны для тестирования? (пользователи, заказы, продукты)
• Кто их подготовит? (обычно QA или разработчик)
• Реалистичны ли они? (например, если в боевой системе 1 млн пользователей, на staging должны быть хотя бы 100k)
• Есть ли критичные данные, которые нельзя использовать из продакшена? (личные данные, финансовая информация)

3. Тестовые аккаунты

• Нужны ли аккаунты с разными ролями? (админ, модератор, обычный пользователь)
• Какие права доступа у каждого?
• Есть ли различие в UI для разных ролей?

Процесс тестирования на предпериоде

1. Smoke-тестирование (дымовое тестирование) Проверить базовую функциональность без использования требований:

• Приложение запускается без ошибок
• Можно залогиниться
• Основные страницы загружаются
• Нет белых экранов ошибок

Если smoke-test падает — дальше не идём, отправляем разработчикам обратно.

2. Функциональное тестирование Тестировщик идёт по каждому требованию и проверяет тест-кейсы.

Пример требования: "Пользователь может отфильтровать товары по цене"

Тест-кейсы:

• TC-101: Открыть страницу товаров → применить фильтр "цена от 100 до 500" → проверить результаты
• TC-102: Фильтр работает при пустом списке товаров
• TC-103: Граничные значения: цена 0 и цена 999999
• TC-104: Отрицательные значения (цена -100) должны быть отклонены

3. Интеграционное тестирование Проверить, как компоненты работают вместе:

• Пользователь создаёт заказ → получает SMS уведомление → может оплатить → видит в личном кабинете
• Админ создаёт скидку → она автоматически применяется → пользователь видит новую цену

4. Регрессионное тестирование Проверить, что старая функциональность не сломалась:

• Если на этой неделе добавили новый способ оплаты, убедиться, что старые способы ещё работают
• Если изменили форму регистрации, проверить, что логин всё ещё работает

Типичные баги, которые ловят на предпериоде

• UI баги: кнопка не видна, текст не переводится, шрифт некрасиво отображается
• Логика: скидка применяется неправильно, расчёт сумм ошибочный
• Интеграции: SMS не отправляется, платёж не прошёл, данные не синхронизировались
• Производительность: страница загружается 30 секунд (вместо обещанных 3)
• Безопасность: пользователь может видеть чужие данные, не авторизованный пользователь может отправить платёж

Работа с обнаруженными ошибками

1. Классификация

• Критичный баг: система не работает, данные теряются, проблема с безопасностью → лучше не выпускать
• Высокий приоритет: функция не работает, но есть workaround → можно выпустить, но нужно срочно исправить
• Средний: UI неудачный, но логика правильная → можно отложить
• Низкий: опечатка в тексте, скошенная иконка → можно исправить позже

2. Создание баг-репорта

Титул: Форма регистрации не отправляет email при введении +7 в телефон
Шаги к воспроизведению:
1. Открыть страницу регистрации
2. Заполнить все поля, в телефоне ввести +79123456789
3. Нажать "Зарегистрироваться"
4. Проверить email

Ожидаемое: письмо с подтверждением приходит
Фактическое: письмо не приходит, ошибка в консоли: "Invalid phone number"

Окружение: Chrome 120, Windows 11
Дата: 25.03.2026, 14:30

3. Согласование с разработчиком

• Критичный баг → разработчик прерывает всё и исправляет
• Менее критичный → планируется на следующий спринт или hotfix

Критерии выхода на продакшен (Definition of Done для предпериода)

✓ Все требования реализованы ✓ Все критичные баги исправлены ✓ Регрессионные тесты пройдены ✓ Производительность в норме (нет timeout, нет утечек памяти) ✓ Данные корректно обрабатываются (нет потерь, дубликатов, ошибок) ✓ Безопасность проверена (нет утечек данных, SQL injection и т.п.) ✓ Локализация (если требуется): все переводы корректные ✓ Мониторинг установлен (алерты настроены, логи пишутся) ✓ Откат плана готов (знаем, как быстро откатиться на старую версию) ✓ Product Owner согласен выпускать

Как BA проверяет качество тестов

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

Если тесты хорошие, то выпуск на продакшен будет спокойным и предсказуемым.