Тестовые стенды и баг репорты

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

Зачем нужны тестовые стенды?

Представьте Яндекс.Карты:

• Продакшен (production) — версия, которую используют миллионы людей.
• Разработка — новая функция (например, маршруты по тоннелям) создаётся отдельно, чтобы не сломать текущую работу сервиса.

Проблема без тестовых стендов:
❌ Если разработчик сразу зальёт непроверенный код в продакшен, пользователи могут столкнуться с багами.

Решение:
✅ Тестирование проходит на изолированных стендах, где можно безопасно проверять изменения.

Какие бывают тестовые стенды?

1. Локальный стенд (Localhost)

• Запускается на компьютере разработчика.
• Используется для первичной проверки кода.
• Пример: http://localhost:3000.

2. Dev-стенд (Development)

• Внутренний сервер для команды.
• Сюда заливают незавершённые функции для тестирования внутри команды.

3. QA/Stage-стенд

• Максимально приближен к продакшену.
• Здесь тестировщики проверяют готовые фичи перед выпуском.

4. Продакшен (Production)

• Финальная, рабочая версия для пользователей.

Как попадает код на тестовый стенд?

1. Разработчик создаёт новую функцию локально.
2. Код заливается в Dev-стенд → проверяется командой.
3. После исправлений попадает на QA-стенд → тестирование.
4. Если всё ок — выпускается в продакшен.

Пример для веб-приложения:

• Продакшен: https://yandex.ru/maps
• Dev-стенд: https://dev.maps.yandex-team.ru
• QA-стенд: https://qa.maps.yandex-team.ru

Как тестировщик работает со стендами?

1. Получает ссылку на тестовую версию (например, от разработчика).
2. Проверяет новую функциональность согласно чек-листу.
3. Фиксирует баги в трекере (Jira, YouTrack).
4. Подтверждает исправления перед выпуском.

Важно:

• На Dev-стенде могут быть «сырые» функции.
• На QA-стенде всё должно быть как в продакшене (те же данные, API, настройки).

Чек-лист для тестирования на стендах

1. Соответствие ТЗ
   Фича работает как задумано.
2. Интеграция с системой
   Нет конфликтов с другими функциями.
3. Безопасность
   Нет утечек данных или уязвимостей.
4. Производительность
   Нет лагов или зависаний.

✅ Тестовые стенды — обязательный этап перед выпуском обновлений.
✅ Dev → QA → Prod — стандартный путь кода.
✅ Все баги должны быть исправлены до выхода в продакшен.

Баг-репорты. Что такое баг и как его выявить?

Баг — это несоответствие между ожидаемым (ОР) и фактическим (ФР) результатом работы приложения. Например:

• ОР: В Яндекс.Маршрутах можно ввести начальную и конечную точки маршрута
• ФР: Поле ввода начальной точки неактивно, пользователь не может построить маршрут

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

Структура идеального баг-репорта

1. Заголовок (Title)

Должен быть конкретным и информативным. Примеры:
✅ "Профиль: поле 'Имя' не принимает значения короче 3 символов"
❌ "Проблема с формой"

2. Шаги воспроизведения (Steps to Reproduce)

Чёткая последовательность действий:

1. Открыть приложение Яндекс.Маршруты
2. Нажать на поле "Откуда"
3. Попытаться ввести адрес

3. Ожидаемый и фактический результат

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

4. Критичность (Severity)

УровеньПримерКритическийПриложение полностью не запускаетсяВысокийНе работает основная функцияСреднийЧастичная неработоспособностьНизкийОпечатка в тексте

5. Приоритет (Priority)

• Высокий: Блокирует работу других команд
• Средний: Важно, но может подождать
• Низкий: Косметические проблемы

Жизненный цикл бага

Ключевые статусы:

1. Open — ошибка зарегистрирована
2. In Progress — разработчик исправляет
3. Fixed — исправление готово
4. Testing — ретест
5. Re-opened — баг не устранён
6. Closed — успешно исправлено

Где оформлять баг-репорты?

Популярные системы:

• Jira (наиболее распространённая)
• Bugzilla
• Redmine
• YouTrack
• Внутренние системы компаний

Совет: Всегда уточняйте в команде:

1. Какую систему используют
2. Есть ли шаблоны баг-репортов
3. Кому назначать задачи

Пример заполненного баг-репорта

Заголовок:
"Яндекс.Маршруты: поле 'Откуда' неактивно на iOS 16.2"

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

1. Открыть приложение на iPhone 13 (iOS 16.2)
2. Нажать на поле "Откуда"
3. Попытаться ввести текст

ОР: Поле активируется, появляется клавиатура
ФР: Поле остаётся неактивным
Критичность: Высокая
Приоритет: Высокий
Версия: 3.14.2
Скриншот: [ссылка]

Практические советы

1. Один баг — один отчёт (не объединяйте несколько проблем)
2. Всегда прикладывайте доказательства (скриншоты, логи, видео)
3. Проверяйте воспроизводимость (минимум на 2 разных устройствах)
4. Следите за статусами — вовремя делайте ретесты
5. Будьте вежливы — "Найден баг", а не "Вы сломали"

Запомните: Хороший баг-репорт экономит время всей команды и ускоряет процесс исправления ошибок!