Как получал сборки

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

Получение сборок — фундаментальный процесс в работе QA Engineer. Я строил этот процесс, исходя из типа проекта (веб, мобильное приложение, десктоп, backend), методологии разработки (Waterfall, Agile, CI/CD) и инструментария команды. Основные методы и источники можно разделить на несколько категорий.

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

• CI/CD pipelines (Jenkins, GitLab CI, TeamCity, GitHub Actions). Это самый частый и автоматизированный способ. После мержа кода в определенную ветку (например, develop или main) pipeline автоматически запускает сборку, выполняет unit-тесты и публикует артефакт.

    *   В Jenkins, например, сборка могла быть доступна как прямые `.apk`/`.ipa` файлы или ссылки на скачивание из последнего успешного билда.

```bash
# Пример: часто использовался простой HTTP-доступ к артефактам Jenkins
# Ссылка вида: http://jenkins-server/job/project-name/lastSuccessfulBuild/artifact/build/outputs/apk/app-debug.apk
```

• Системы управления артефактами (Artifactory, Nexus). В mature-проектах сборки не просто "выкладывались" на CI сервер, а публиковались в центральный репозиторий с версионированием. Это позволяло точно идентифицировать сборку, управлять зависимостями и получать билды по четкой версии (например, app-1.2.3-beta.apk).
• Прямая сборка от разработчиков. В начале проекта или для горячих фиксов разработчики могли предоставить сборку напрямую:

    *   **adb для Android**: Разработчик собирает APK и передает его, или мы сами устанавливали через `adb install`.

```bash
adb install -r path/to/app-debug.apk  # -r для переустановки
```

    *   **Xcode для iOS**: Получение `.ipa` файла или доступ к проекту через **TestFlight** или **Apple Developer Portal** для внутреннего тестирования.
    *   **Веб-проекты**: Часто разработчики просто сообщали, что на определенном **стэнд-сервере** (stand) или в конкретной **ветке Git** выложена новая версия фронтенда. Мы тестировали прямо на этом сервере или собирали фронтенд локально.

• Системы управления тестированием (TestFlight, Google Play Internal Testing, Firebase App Distribution). Для мобильных приложений это специализированные и удобные каналы. Разработчик загружает сборку в систему, и тестировщики получают доступ через приложение-клиент (TestFlight) или ссылку (Firebase). Это также дает удобную централизованную обратную связь.
• Локальная сборка из исходного кода. Как QA, я часто самостоятельно собирал проект из нужной ветки Git для:

    *   Проверки конкретного коммита или ветки.
    *   Исследования проблемы, когда нужно было добавить логи или провести глубокую диагностику.
    *   Для веб-проектов: `npm run build` или `yarn build`.
    *   Для мобильных: открытие проекта в Android Studio/Xcode и запуск билда.

Ключевые принципы и практики в процессе

• Четкая идентификация сборки. Каждая полученная сборка должна иметь уникальный идентификатор: версия (semver), номер билда (build number), хеш коммита (commit hash), дата сборки. Это критично для отчетности и воспроизведения проблем.
• Автоматизация получения. В идеальном процессе после успешного билда в CI/CD система автоматически:

    1.  Публикует сборку в артефакт-репозиторий.
    2.  Размещает ее на тестовый сервер (для веб).
    3.  Загружает в средство дистрибуции (например, Firebase).
    4.  **Отправляет notification** в чат команды (Slack, Telegram) или создает запись в **Test Management Tool** (TestRail, Zephyr) о наличии новой версии для тестирования.

• Контроль качества сборки (Smoke Test на этапе сборки). Часто в pipeline добавлялся этап автоматического smoke-теста (например, запуск одного ключевого UI-теста или проверка доступности API). Только после его успеха сборка считалась готовой для передачи QA. Это экономило время на тестирование очевидно сломанных билдов.
• Согласованность среды. Полученная сборка должна соответствовать тестовой среде (test environment): правильные конфигурации, подключение к тестовым базам данных и API. Иногда приходилось получать отдельные сборки для разных сред (stage, prod-like).

Пример workflow для мобильного проекта в Agile

1. Разработчик завершает задачу и мержит код в develop.
2. Jenkins запускает pipeline для ветки develop: собирает проект, запускает unit-тесты, создает .apk.
3. Pipeline загружает .apk в Firebase App Distribution, добавляя заметку с номером задачи из Jira.
4. Firebase отправляет email-приглашение тестировщикам.
5. QA Engineer получает email, скачивает приложение через ссылку Firebase на тестовое устройство.
6. В чат команды приходит авто-сообщение от Jenkins: "Сборка v1.2.3-build456 для задачи PROJ-789 доступна для тестирования".
7. QA начинает тестирование, четко указывая в отчете о дефекте: "Сборка: v1.2.3-build456 (коммит abc123)".

Таким образом, получение сборок — это не просто "скачать файл", а часть хорошо организованного процесса непрерывной интеграции и поставки, требующая четкой коммуникации, автоматизации и внимания к деталям для обеспечения эффективного тестирования.