Git для тестировщика: минимум, который нужен на работе

Тестировщику не нужно уметь всё, что умеет Git. Нужен понятный минимум: понимать, что за версия на стенде, читать историю изменений и хранить свою документацию.

Зачем это тестировщику

Три реальные ситуации, в которых без Git вы беспомощны.

• «У меня воспроизводится, у тебя нет». Часто причина в том, что на стендах разные версии. Понимание веток и коммитов позволяет это проверить, а не гадать.
• «Что вошло в эту сборку». История изменений отвечает на вопрос, что вообще менялось, — а это отправная точка для регресса.
• Своя документация и автотесты. Чек-листы и коллекции хранят там же, где код, — чтобы они версионировались вместе с продуктом.

Три понятия, которых достаточно для старта

Понятие	Что это простыми словами
Коммит	Сохранённое состояние проекта с описанием, что изменили
Ветка	Отдельная линия работы: делают фичу, не трогая основную версию
Слияние (merge)	Перенос изменений из ветки в основную линию

Типичный процесс: разработчик создаёт ветку под задачу, делает коммиты, открывает пул-реквест, коллеги смотрят код, ветку вливают в основную. Ваша сборка на стенде — это состояние какой-то из веток на какой-то момент.

Команды, которые понадобятся

Полноценно писать в репозиторий вам, скорее всего, не придётся. А вот читать — да.

• git clone <адрес> — скачать репозиторий к себе.
• git pull — забрать свежие изменения.
• git log --oneline -20 — двадцать последних коммитов кратко.
• git branch -a — какие есть ветки.
• git checkout <ветка> — переключиться на ветку.
• git status — что изменено у вас локально.
• git diff — что именно изменено.

Для своей документации добавятся три: git add ., git commit -m "текст", git push. Этого хватает, чтобы вести чек-листы в репозитории.

Как понять, что за версия на стенде

Самый частый практический вопрос. Способы, по убыванию удобства:

1. Посмотреть в интерфейсе. Во многих продуктах номер сборки виден в подвале или в «О программе».
2. Спросить сервер. Часто есть служебный адрес вроде /version или /health, отдающий версию и хеш коммита.
3. Посмотреть в системе сборки. В CI видно, какой коммит выкатывали на какой стенд и когда.
4. Спросить команду. Нормальный способ, но первые три быстрее.

Что читать в истории изменений

Перед регрессом полезно посмотреть, что вошло в сборку. Не чтобы читать код, а чтобы понять зону влияния.

Смотрите на две вещи: какие файлы менялись (по названиям обычно понятно, какая часть продукта затронута) и сколько изменений (правка в три строки и переработка модуля требуют разного внимания).

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

Пул-реквест и ревью

Пул-реквест — предложение влить ветку в основную линию. Там видно: что изменено, кто смотрел, прошли ли автотесты, есть ли замечания.

Тестировщика часто добавляют в ревью. Читать код не обязательно — полезно другое: посмотреть описание задачи и задать вопросы. «А что будет, если поле придёт пустым?» на этом этапе стоит минуту, а после релиза — дефект.

В зрелых командах в пул-реквесте видно и результат прогона автотестов. Красный статус до слияния — сигнал, что сборку тестировать рано.

Что такое CI и почему это касается вас

Как только код попадает в репозиторий, за дело берётся система непрерывной интеграции: она собирает проект, гоняет тесты и выкладывает сборку на стенд. Тестировщику она интересна двумя вещами.

Логи сборки отвечают на вопрос «почему на стенде старая версия»: часто выясняется, что сборка упала и выката просто не было. Это экономит час поисков несуществующего дефекта.

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

Где хранить свою документацию

Аргумент за хранение чек-листов и коллекций в репозитории продукта: они меняются вместе с ним. Переделали функцию — правка кода и правка чек-листа едут одним изменением, и документация не отстаёт.

Аргумент против: не всем в команде удобно читать разметку в репозитории вместо вики. Компромисс, который работает: автотесты и коллекции — в репозитории, обзорная документация и требования — в вики со ссылками.