Как понять ветку и тестировать задачу бэка в статусе готового к тестированию
Что проверяют
Понимаете ли вы путь задачи от ветки до стенда и умеете ли убедиться, что тестируете именно нужную сборку. Следом обычно спрашивают, что делать, если после слияния в основную ветку что-то сломалось.
Как отвечать
Сначала найдите ветку и изменения:
- связь с задачей: в карточке Jira есть панель разработки со ссылками на ветку и merge request, либо ветку ищут по соглашению об именах, например
feature/PAY-123-refund-limit; - описание и дифф: в GitLab или GitHub прочитайте описание MR и список изменённых файлов. Миграции, новые эндпоинты, правки конфигов и общих модулей сразу показывают, что проверять и где ждать регрессии;
- актуальность: ветка должна быть свежей относительно
developилиmain, иначе после слияния поведение может измениться.
Затем убедитесь, что стенд тот:
- где собрано: ветку либо разворачивают на отдельном динамическом стенде из CI, либо сначала вливают в
developи выкатывают на тестовый; - что собрано: сверьте хэш коммита на стенде с последним в ветке. У многих сервисов есть эндпоинт версии, в Spring Boot это
/actuator/info, ещё можно посмотреть тег образа в пайплайне.
Сама проверка бэкенд-задачи:
- API: Postman или Swagger, позитивные и негативные сценарии по критериям приёмки;
- данные: SQL-запросами проверить, что записалось в базу и применилась миграция;
- логи и очереди: Kibana или Grafana, сообщения в Kafka или RabbitMQ, если задача их касается;
- регрессия: соседний функционал, который задевают изменённые модули.
Результат фиксируется в задаче: что проверено, на какой сборке, какие баги заведены и связаны с ней.
Где спотыкаются
Тестируют на стенде со старой сборкой, потому что пайплайн упал или ещё не доехал. Сверка хэша коммита занимает минуту и снимает вопрос.
Не смотрят дифф и проверяют только сценарий из описания. Правка общего модуля ломает то, о чём в задаче не сказано ни слова.
Закрывают задачу после проверки в ветке и не смотрят её после слияния. Конфликт при мерже или чужие изменения в develop могут вернуть баг, поэтому нужен короткий смоук на общем стенде.