Опишите процессы разработки и тестирования на вашем предыдущем проекте.

Ответ

На последнем проекте мы использовали адаптированную гибридную модель Scrum/Kanban в рамках двухнедельных спринтов.

Организация работы:

  • Планирование спринта: В начале спринта проводилась встреча, на которой команда (разработчики, тестировщики, аналитик) оценивала задачи из бэклога продукта и формировала спринт-бэклог.
  • Ежедневные стендапы: Короткие 15-минутные встречи для синхронизации: что сделал, что планирую, есть ли блокеры.
  • Ретроспектива: В конце спринта — анализ того, что прошло хорошо, что можно улучшить, с фиксацией action items.
  • Канбан-доска: В Jira использовалась доска с колонками: Backlog, Ready for Dev, In Progress, Code Review, QA, Done. WIP-лимиты помогали избегать перегрузки.

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

  1. Ветвление кода: GitFlow-like модель. Для каждой задачи создавалась feature-ветка от develop.
  2. Ревью кода: Обязательный этап. Перед мержем в develop как минимум один коллега должен был одобрить Pull Request (GitLab). Акцент делался на читаемость, соответствие стандартам и отсутствие "запахов" кода.
  3. Непрерывная интеграция (CI): При пуше в ветку и создании PR автоматически запускался пайплайн в GitLab CI/CD:
    • Сборка проекта.
    • Запуск модульных (JUnit) и интеграционных тестов.
    • Статический анализ кода (SonarQube).
    • Сборка Docker-образа для тестового окружения.
    • Мерж в develop был возможен только при "зелёном" пайплайне.
  4. Тестирование:
    • Разработчики: Писали модульные и интеграционные тесты для своего кода (покрытие >80%).
    • QA-инженеры:
      • Автоматизация: Писали и поддерживали E2E-тесты на Playwright (UI) и API-тесты на REST Assured. Они запускались в nightly-билде и на staging перед релизом.
      • Ручное тестирование: Проводилось по чек-листам для новых фич и критичных пользовательских сценариев. Регрессионное тестирование в основном было автоматизировано.
      • Баги фиксировались в Jira, привязывались к задаче.
  5. Непрерывное развертывание (CD): Успешные сборки из develop автоматически деплоились на staging-окружение. Раз в спринт стабильная версия из main ветки деплоилась на production (с предварительным согласованием и откат-планом).

Инструменты: Jira/Confluence, GitLab (CI/CD, репозиторий), Docker/Kubernetes, Playwright, JUnit, SonarQube, TestRail для управления тест-кейсами.

Пример задачи в пайплайне:

# Упрощённый .gitlab-ci.yml
stages:
  - build
  - test
  - deploy-staging

unit-test:
  stage: test
  script:
    - mvn clean test
  artifacts:
    reports:
      junit: target/surefire-reports/*.xml

e2e-test:
  stage: test
  script:
    - npm ci
    - npx playwright install
    - npx playwright test --reporter=html
  artifacts:
    paths:
      - playwright-report/

Ответ 18+ 🔞

А, ну ты про эту вашу «гибридную модель»? Блядь, это ж когда взяли всё самое ебанутое из двух методологий и скрестили, как мартышку с удавом, чтобы получить неведомую хуйню, которая, по идее, должна работать. Ну, в принципе, работало, пиздец.

Смотри, как мы извращались. Двухнедельные спринты, да. В начале — планирование. Собирается вся кодла: разработчики, тестировщики, этот, аналитик. Сидим, смотрим на бэклог, который накопился, как говна за баней. Оцениваем, пиздимся, пытаемся запихнуть в спринт столько, чтобы не сдохнуть, но и менеджеру угодить. Формируем спринт-бэклог — список задач, на которые мы, блядь, подписались, как дураки.

Каждый день — стендап. Пятнадцать минут, не больше. «Что сделал, что буду делать, что мешает». Главное — не начать рассказывать про свою личную жизнь или архитектурные изыски, а то сразу «Чувак, бля, это не формат, иди нахуй». Блокеры выявляли быстро: «Сервер сдох», «АПИшка от соседей не работает», «Документация — пиздец, а не документы».

В конце спринта — ретроспектива. Это святое, блядь. Разбирали, что было хорошо (обычно нихуя), что было плохо (всё), и что будем делать, чтобы не повторять одни и те же грабли. Action items записывали, а потом благополучно про них забывали до следующей ретро, ёпта.

Доска у нас в Jira была, но с кайфом. Гибрид же, сука. Колонки: Backlog, Ready for Dev, In Progress, Code Review, QA, Done. И WIP-лимиты, блядь! Это чтобы какой-нибудь охуевший не взял в работу десять задач одновременно и всех не затормозил. Лимит в колонке In Progress — два. Больше нельзя, иди похуй, жди своей очереди. Дисциплинировало, пиздец.

А теперь, сука, самое интересное — процесс. Чтоб ты понимал, насколько мы там всё зарегламентировали.

  1. Ветвление. GitFlow, но не совсем, своя поеботина. Для каждой задачи — отдельная ветка от develop. Название ветки — feature/JIRA-123-ochen-vazhnaya-ficha.
  2. Ревью кода. Обязательное, блядь. Без одобрения хотя бы одного коллеги — нихуя не смержишь. Сидишь, создаёшь Pull Request в GitLab, а там тебе начинают тыкать: «А чё тут за магическое число?», «Название переменной — пизда, а не название», «А где тесты, сука?». Иногда доходило до матов, но в итоге код становился чище, это да.
  3. CI/CD, мать его. Вот где начиналась магия, а иногда и пиздец. Настроили пайплайн в GitLab CI. Ты только пушнул в ветку — он уже бежит, как угорелый:
    • Собирает проект.
    • Гоняет модульные (JUnit) и интеграционные тесты.
    • Лезут статики-аналитики (SonarQube) — ищут говнокод.
    • Собирает Docker-образ.
    • И самое главное: если пайплайн красный — нихуя не смержишь в develop. Никаких «ой, я потом пофикшу». Всё, приехали, иди чини.
  4. Тестирование. Тут два фронта.
    • Разработчики: Должны были покрыть свой код тестами. Цель — больше 80%. Кто не покрыл — тому на ревью сразу «Гони тесты, пидорас шерстяной».
    • QA-инженеры: Ну, это отдельная каста, блядь. Они писали автотесты на Playwright (чтобы браузером тыкать) и на REST Assured (для API). Эти тесты гонялись каждую ночь и на staging-е перед релизом. Ручное тестирование — только для новых фич и самых критичных штук. Регресс в основном автоматом. Найдут баг — создадут задачу в Jira и привяжут к твоей фиче. Позор на всю деревню.
  5. Деплой. Успешная сборка из develop сама летела на staging. А раз в спринт, когда в main всё стабильно, — релиз в прод. Но перед этим — собрание, согласование, откат-план на случай, если всё пойдёт по пизде.

Инструменты? Да стандартный набор: Jira/Confluence для планирования и документов, GitLab (тут и репа, и CI/CD), Docker с Kubernetes, Playwright, JUnit, SonarQube, TestRail для тест-кейсов.

Вот, смотри, как примерно выглядел наш пайплайн, чтоб ты проникся:

# Упрощённый .gitlab-ci.yml
stages:
  - build
  - test
  - deploy-staging

unit-test:
  stage: test
  script:
    - mvn clean test
  artifacts:
    reports:
      junit: target/surefire-reports/*.xml

e2e-test:
  stage: test
  script:
    - npm ci
    - npx playwright install
    - npx playwright test --reporter=html
  artifacts:
    paths:
      - playwright-report/

Выглядит безобидно, да? А теперь представь, что этот e2e-test падает в три часа ночи из-за какой-нибудь ерунды, и тебе приходит уведомление. Волнение ебать. Но зато утром уже знаешь, что ломать начало. В общем, система, блядь, была жёсткая, но работала. Как танк, ебать. Иногда глохла, но в целом — ехала.