Привет, Хабр! Я – Мария Скрипачева, тестировщик в АйТи-Балансе. Сегодня почти все компании применяют тестирование, и мы не исключение: наши проекты проходят несколько стадий проверок до развёртывания. На нынешнем месте работы я иногда встречаю вопрос, с которым не раз сталкивалась на предыдущих: «а нужен ли GitHub тестировщику?». Эта дискуссия не нова. Я решила внести свою лепту в обсуждение, опираясь на мой опыт и опыт моих коллег, и заодно рассказать о фундаментальных вещах. Поехали?

Что к чему

Коротко о предмете статьи:

• Git – это система контроля версий кода/проекта. Каждый участник команды может редактировать его, просматривать изменения от коллег, а также откатываться к предыдущим версиям – это помогает выяснить, что и когда пошло не так, если возникли проблемы.

• GitHub (или просто GH) – это крупнейший бесплатный веб-сервис для удобной работы с Git. Есть и другие аналоги (например, Bitbucket), но Гитхаб – самое популярное решение.

Нужен ли этот инструментарий тестировщику? Смотря какому. Напоминаю, что есть две специализации:

• Ручной тестировщик (QA Manual или мануальщик) – проверяет качество продукта вручную, без программирования.

• Автоматизатор (QA Automation) – применяет специальные программы для выполнения тестов.

Рассмотрим пользу Гита для обеих категорий.

Git для мануальщиков

Ручные тесты проводят средствами обычного пользователя: мышью, клавиатурой, пальцами по тачскрину. Мануальщики не используют программирование в своей работе, поэтому и изучать Гит им необязательно. Лучше уделить время инструментам, которые точно понадобятся в ручном тестировании. Для конкретики загляните вот в эти репозитории.

«Но знание Гита могут требовать в вакансиях» – возразите вы мне. Так действительно бывает, но реалии на рабочих местах другие. Вакансию могли составить не только для джунов или мануальщиков. Или в ней написали вообще все технологии, которые используются на проекте – даже те, с которыми ручному тестировщику работать не придется (тимлид бегло перечислил эйчару, лишь бы от него побыстрее отстали).

С другой стороны, изучение Гита может быть плюсом для мануальщика. В статье «Зачем Git тестировщику» подробно рассказано, что оно даёт. А вот если тестировщик приступает к автоматизации, то тогда Гит и Гитхаб ему точно пригодятся.

Git для автоматизаторов

Для автоматизации тестов пишут специальные программы. Этот код нужно где-то хранить и обеспечить коллегам доступ к нему. Вот тут-то нам и понадобится GitHub!

Теперь разберёмся с фундаментальными вещами.

Основы Гитхаба для тестировщика

В сухом остатке, вы должны научиться:

1. Работать с Гитом и Гитхабом.

2. Настраивать автозапуск тестов с помощью GitHub Actions.

Для этого нужны Git и GitHub. Все дальнейшие действия я буду показывать в среде Linux. Если хотите работать из-под Windows – рекомендую установить WSL.

Git и GitHub

Первым делом установите Git.  Далее многие бы посоветовали настроить его, но я рекомендую сначала зарегистрироваться на Гитхабе. Создав аккаунт, вы можете скрыть свой реальный почтовый адрес: перейдите в настройки Emails, выставьте галочки на «Keep my email addresses private» и «Block command line pushes that expose my email». Под первым параметром будет написан ваш приватный email, вроде такого: 123456789+yourname@users.noreply.github.com.

Теперь настраиваем Гит. Нам нужно сообщить ему своё имя и почтовый адрес – так коллеги будут знать, кто и какие изменения внёс в проект. Открываем терминал, вводим две команды:

git config --global user.name "ваше_имя"
git config --global user.email "ваш_email"

Если хотите использовать приватный email с Гитхаба, то вторая команда должна выглядеть примерно так:

git config --global user.email "123456789+yourname@users.noreply.github.com"

Выставляем ветку по умолчанию на main (Гитхаб переименовал master на main ещё несколько лет назад):

git config --global init.defaultBranch main

Если хотите цветной вывод на экран, введите:

git config --global color.ui auto

Проверяем, корректно ли мы всё настроили:

git config --list --global

Если что-то не так – введите нужные команды повторно и правильно.

Создание SSH-ключа

SSH-ключ – это длинная комбинация символов для идентификации компьютера. Он нужен, чтобы вы не вводили свой логин и пароль каждый раз, когда пушите изменения на Гитхаб, а также во избежание ошибки “Please use a personal access token”.

Проверьте, не установлен ли этот ключ у вас:

ls ~/.ssh/id_ed25519.pub

Если нет (“No such file or directory”), то:

1. Создайте его, введя эту команду: ssh-keygen -t ed25519

2. Когда система спросит, куда сохранить ключ, просто нажмите Enter.

3. Далее она предложит создать пароль – можете ввести его или пропустить нажатием Enter.

Когда вы создали ключ (или он уже был создан на вашем компьютере), свяжите его со своим GH-аккаунтом:

1. Зайдите в раздел SSH and GPG keys в настройках Гитхаба.

2. Нажмите на зелёную кнопку “New SSH key” в верхнем правом углу.

3. Придумайте и введите говорящее название для вашего ключа. Например, ubuntu-ssh.

4. Оставьте окно открытым – оно скоро пригодится. Пока не нажимайте “Add SSH key”!

Отобразите ключ на экране:

cat ~/.ssh/id_ed25519.pub

Он должен начинаться с “ssh-ed25519” и заканчиваться на email, который вы ввели ещё при настройке Гита.

Продолжаем:

1. Выделите и скопируйте весь свой ключ.

2. Вернитесь к окну Гитхаба, которое вы не закрыли (п.4 из предыдущего списка).

3. Вставьте скопированный ключ в поле “Key”.

4. Тип ключа (Key type) оставьте на “Authentication Key”.

5. Нажмите “Add SSH key”.

Теперь вы с SSH-ключом. Проверьте, всё ли сделано правильно. Если нет – пройдите этот подраздел заново.

Работа с репозиториями

Репозиторий – это хранилище кода и истории его изменений. Существуют два типа:

• Локальный репозиторий. Создаётся с помощью Git, хранится на вашем компьютере и доступен только вам.

• Удалённый репозиторий. Хранится в интернете – например, на серверах GitHub. Все участники команды отправляют сюда изменения из своих локальных репозиториев.

Научимся работать с обоими типами. Ссылки ниже на английском (на момент написания статьи); если не владеете – воспользуйтесь автопереводом в браузере:

1. Создайте удалённый репозиторий на Гитхабе.

2. Клонируйте его на свой компьютер с помощью SSH-ссылки (не HTTPS, а то потом получите ошибку “Support for password authentication was removed …”).

Теперь у вас есть локальная копия репозитория. Создайте в ней текстовый файл (например, test.txt) и напишите в нём что угодно.

Чтобы отправить эти изменения в удалённый репозиторий, переместитесь в папку локальной копии с помощью терминала:

cd соответствующий_путь

Вы должны быть внутри самой копии. Теперь проверьте состояние рабочего каталога:

git status

Вы увидите, что ваш текстовый файл написан красным цветом в разделе “Untracked files”. Это значит, что его нужно добавить в область подготовки (staging area):

git add

Вновь проверяем статус. Файл будет написан зелёным цветом в разделе “Changes to be committed”. Это значит, что изменения занесены в область подготовки и ожидают коммита (грубо говоря, фиксации).

Коммитим, указывая в кавычках комментарий об изменениях (например, “Add test.txt file”):

git commit -m "Add test.txt file"

Проверяем статус и видим “nothing to commit, working tree clean” – это значит, что правки зафиксированы. Теперь пушим (отправляем) изменения из локального репозитория на удалённый:

git push

Если получили ошибку “Support for password authentication was removed …”, значит вы сделали неправильно – клонировали по HTTPS-ссылке, а не SSH. Следуйте этой инструкции, затем повторите пуш.

Проверяем статус в последний раз. В выводе будет написано “Your branch is up to date with ‘origin/main’. nothing to commit, working tree clean”.

Обновите страницу репозитория на Гитхабе. Там будет тот самый .txt из локальной копии.

Вы можете редактировать любой загруженный файл прямо в интерфейсе Гитхаба:

1. Кликните на этот .txt (в окне удалённого репозитория).

2. Нажмите на значок письменной ручки – он в правом верхнем углу области с содержимым файла.

3. Внесите любые изменения в текст.

4. Нажмите на зелёную кнопку “Commit changes…” в правом верхнем углу.

5. Появится окно “Commit changes”. В нашем случае радиокнопка должна быть выставлена на “Commit directly to the main branch”. Если хотите, добавьте развёрнутое описание изменения в поле “Extended description”.

6. Нажмите на зелёную кнопку “Commit changes” в правом нижнем углу этого окна.

Или создать любой файл:

1. Нажмите на вкладку “Code”, чтобы вернуться на главную страницу репозитория.

2. Нажмите на кнопку, которая слева от зелёной “<> Code” – она может называться “Add file” или просто “+”.

3. Выберите “Create new file”.

4. В поле “Name your file…” напишите название файла и его расширение. Например, “test2.txt” (без кавычек).

5. По желанию, напишите в поле “Enter file contents here” любой текст.

6. Нажмите на зелёную кнопку “Commit changes…” в правом верхнем углу.

7. Появится окно “Commit changes”. Радиокнопка должна быть выставлена на “Commit directly to the main branch”. По желанию добавьте развёрнутое описание коммита в поле “Extended description”.

8. Нажмите на зелёную кнопку “Commit changes” в правом нижнем углу этого окна.

Как только переместитесь на главную страницу репозитория, вы увидите там новый файл.

Чтобы перенести изменения из удалённого хранилища на локальную копию, используйте эту команду:

git pull 

Теперь у вас есть базовый опыт работы с Гитом и Гитхабом! Для лучшего закрепления можете попрактиковать этот раздел ещё раз (или два и более). Если хотите удалить репозиторий – следуйте этой инструкции.

Автотесты с GitHub Actions

GH Actions – это функция Гитхаба для автоматизации процессов CI/CD. Мы рассмотрим её фундамент. За основу я взяла вот эту англоязычную статью.

Процесс будет состоять из трёх этапов:

1. Загрузить проект на GH.

2. Настроить автозапуск проекта с помощью GH Actions.

3. Получить результат.

Проект

Для учебных целей воспользуемся материалом автора оригинальной статьи. Это простая функция на Node.js, которая идёт вместе с тестовым скриптом. Проект старый, поэтому его основная ветка называется “master”, а не “main” (в нашем случае это не критично).

Откройте репозиторий по этой ссылке и скопируйте его к себе – нажмите на “Fork” в правой верхней части окна. Клонировать, как в подразделе выше, не надо.

Вы можете ввести любое название для вашего форка в поле “Repository name” или оставить дефолтное. Пункт “Copy the master branch only” должен быть отмечен. Писать “Description” или нет – на ваше усмотрение.

Нажмите на зелёную кнопку “Create fork” и дождитесь окончания операции. Вы автоматически попадёте на страницу своего форка. Репозиторий успешно скопирован!

К сожалению, автор не убрал кое-какие конфигурационные файлы. На данном этапе они будут только сбивать вас с толку, поэтому удалим их сами. Кликните на директорию “.github/workflows”

Нажмите на кнопку “…” в правой верхней части экрана (справа от “Add file”).

Нажмите на “Delete directory” в появившемся окошке.

Зафиксируйте изменения, нажав на “Commit changes…”.

Убедитесь, что в появившемся окне “Commit changes” радиокнопка выставлена на “Commit directly to the master branch”. По желанию добавьте подробное описание изменения в поле “Extended description”. Нажмите на “Commit changes”.

Результат – всё тот же форк, но уже без директории “.github/workflows” и с сообщением “Directory successfully deleted”.

Если хотите вернуться на главную страницу, то в левой верхней части окна нажмите на вкладку “Code” или название форка (выделено синим).

Actions – конфигурация

Проект полностью готов, теперь настроим автозапуск теста. Перейдите во вкладку Actions.

Здесь мы можем создать файл с настройками для автозапуска. Гитхаб предлагает шаблоны на выбор, исходя из содержимого репозитория. Но нам нужно другое.

Вводим “Node.js” (без кавычек) в поле “Search workflows”, жмём Enter. Кликаем “Configure” на шаблоне с названием “Node.js”.

Теперь он доступен для редактирования.

Название файла можете поменять с “node.js.yml” на любое другое. Например, на “tests.yml”.

Название конфига – в параметре “name”. Можно поменять его с “Node.js CI” на “Tests”.

Секция “on” – это список событий, при которых действие (action) будет запускаться автоматически. В нашем случае – при каждом пуше (отправке изменений в репозиторий на ГХ) и пулл реквесте (запросе на слияние изменений с основной веткой проекта). Полный список событий доступен здесь.

Секция “jobs” – это задачи, которые будут выполняться. В нашем примере только одна задача, названная “build”. Можно переименовать её, например, на “test”. Далее:

• runs-on – в какой среде выполнять задачу. Обычно выбирают последнюю версию Ubuntu – ubuntu-latest. Можно прописать и другую ОС.

• strategy matrix – на каких версиях языка проводить запуск.

Подсекция “steps” – это шаги, из которых будет состоять действие. Разберём их чуть подробнее:

• uses: actions/checkout@v4 – проверка кода в рабочей среде. Это необходимый шаг, его нельзя удалять. Версия checkout может со временем меняться.

• uses: actions/setup-node@v4 – установка Node в рабочей среде (ведь проект написан на этом языке).

• node version – какие версии Ноды устанавливать. В нашем случае – те, которые прописаны в strategy matrix.

• run: npm ci – установка зависимостей. Команда аналогична npm install, только без обновления пакетов.

• run: npm run build --if-present – запустить сборочный скрипт. Флаг “--if-present” означает «если таковой есть в проекте». У нас его нет, так что этот шаг можно удалить.

• run: npm test – запуск нашего теста. Это главный шаг, ради которого мы всё настраивали.

Нажмите на “Commit changes…” в верхнем правом углу.

Появится уже знакомое вам окно “Commit changes”. Убедитесь, что радиокнопка выставлена на “Commit directly to the main branch”. По желанию добавьте подробное описание изменения в поле “Extended description”. Нажмите на “Commit changes”.

Вы окажетесь в директории .github/workflows и увидите в ней файл tests.yml. Если хотите вернуться на главную страницу, то в левой верхней части окна нажмите на вкладку “Code” или на название форка (выделено синим).

Настройка завершена! Теперь, как вы и задали, действие будет само запускаться при каждом пуше и пулл реквесте, и делать то, что указано в steps.

Actions – автозапуск

Перейдите во вкладку Actions. В левой боковой панели выберите созданный вами процесс (у нас это “Tests”).

Кликните на последний коммит. В нашем примере – “Create tests.yml”.

Везде зелёные галочки – тесты были автоматически запущены и с кодом всё нормально. На боковой панели слева перечислены версии языка, на которых выполнена задача. Просмотрим, например, “test (18.x)”.

Мы здесь ради главного шага – “Run npm test”. Кликаем на него, чтобы увидеть результат.

Как мы видим, тест успешно пройден.

Теперь давайте сломаем код и посмотрим на результаты проверок. Перейдите на вкладку “Code” и откройте index.js.

Нажмите на значок письменной ручки в правом верхнем углу области с кодом.

Сломайте что-нибудь. Можно так:

Закоммитьте изменения (зелёная кнопка “Commit changes…” в верхнем правом углу). Убедитесь, что радиокнопка выставлена на “Commit directly to the main branch”. По желанию добавьте подробное описание изменения в поле “Extended description”. Нажмите на “Commit changes”.

Нажмите на вкладку Actions и перейдите в ваш рабочий процесс. Последний коммит находится вверху списка, и он может быть «жёлтым» – т.е. в процессе выполнения.

Но он станет «красным». Тест ожидаемо не пройден, потому что мы намеренно подпортили код.

Нажимаем на «красный» коммит. Смотрим на боковую панель слева.

Провал на всех версиях языка. Выбираем любую «красную» задачу – например, всё ту же “test (18.x)”. Открываем шаг “Run npm test” и видим подробную сводку.

-Можете вернуться обратно во вкладку “Code”, починить “index.js” и закоммитить изменения. Сразу после этого будет автоматически запущен тест кода, как и в прошлые разы. Вам нужно только зайти в “Actions” и проверить актуальный коммит. Как только процесс будет завершён, все результаты должны быть «зелёными».

Теперь у вас есть понимание, как настроить автозапуск тестов при тех или иных событиях с кодом. Если хотите, попрактикуйте Actions от начала до конца ещё раз (или больше) – это поможет закрепить знания. Чтобы удалить учебный форк, воспользуйтесь всё той же инструкцией, которую я привел в разделе «Работа с репозиториями».

Вы можете организовать actions для других проектов, написанных на любом языке. Главное, выберите подходящий шаблон для yml-конфигурации или напишите её самостоятельно (для этого нужны более продвинутые знания).

Как вести свой Гитхаб

Придерживайтесь этих правил:

• Адаптируйте и редактируйте свой профайл.

• Храните только актуальные материалы.

• Выкладывайте только рабочие проекты.

• Оформляйте их презентабельно.

Объясню подробнее.

Храните только актуальные материалы

Не превращайте свой Гитхаб в барахолку. Держите в нём лишь актуальные материалы по тестированию. Если работодатель увидит хаотичный хламовник из чего попало, то он может подумать, что вы неряшливы и непоследовательны (берётесь за всё подряд).

Выкладывайте только рабочие проекты

Сырые заготовки никому не интересны. Нужен код, который можно скачать и запустить. Само собой, проект должен работать. Это и только это продемонстрирует работодателю ваши профессиональные скиллы.

Оформляйте свои проекты презентабельно

Никаких ненужных файлов в репозиториях, кучи закомментированного кода, методов без аннотаций и т.д. Позаботьтесь, чтобы у всех ваших проектов было описание (зачем нужны, что делают). Это визитная карточка, по которой вас будут оценивать как специалиста.

FAQ

Q1: Нужен ли GitHub мануальным тестировщикам?

• Хотя мануальные тестировщики могут не использовать Git в своей повседневной работе, базовое понимание системы контроля версий может быть полезным для лучшего взаимодействия с командой разработчиков и доступа к документации и тест-кейсам.

Q2: Какие основные преимущества использования GitHub Actions для автоматизации тестирования?

• GitHub Actions позволяет автоматизировать тестирование, обеспечивая непрерывную интеграцию и доставку. Это помогает быстрее обнаруживать ошибки и улучшать качество кода.

Q3: Можно ли использовать GitHub для тестирования проектов, написанных не на Node.js?

• Да, GitHub Actions поддерживает множество языков и технологий. Вы можете настроить автоматизацию тестирования для проектов на Python, Java, Ruby и других языках, выбрав соответствующий шаблон или настроив свой собственный.

Q4: Что делать, если я случайно закоммитил изменения, которые не хотел отправлять?

• В работе с Git бывают ситуации, когда необходимо отменить изменения или вернуться к предыдущему состоянию репозитория. Вот несколько полезных команд:

  1. Отмена изменений в рабочем каталоге:

• Чтобы отменить изменения в файле, которые еще не были добавлены в индекс (staging area), можно использовать команду:git checkout -- <имя_файла>

• Эта команда вернет файл к состоянию последнего коммита.

  2. Отмена добавления файла в индекс:

• Если файл уже добавлен в индекс, но вы решили не коммитить его, используйте:git reset HEAD <имя_файла>

• Это уберет файл из индекса, но оставит изменения в рабочем каталоге.

  3. Отмена коммита:

• Чтобы отменить последний коммит и вернуть изменения в индекс:git reset --soft HEAD^

• Если нужно отменить изменения в коммите и в индексе, оставив рабочий каталог без изменений:git reset --hard HEAD^

• HEAD^ указывает на коммит перед последним.

  4. Возврат к определенному коммиту:

• Для возврата к определенному коммиту и отмены всех изменений после него:git reset --hard <commit_hash>

• <commit_hash> — это идентификатор коммита, к которому вы хотите вернуться.

Q5: Как защитить свой email в GitHub?

• В настройках аккаунта GitHub можно выбрать опцию "Keep my email addresses private" и использовать сгенерированный GitHub адрес для коммитов, чтобы скрыть свой настоящий email.

Эти ответы и рекомендации помогут лучше понять и использовать возможности GitHub в контексте тестирования.