tgoop.com/notes_about_QA/256
Last Update:
Зачем нужен CI/CD (ручному тестировщику и не только)
CI/CD - методология разработки, которая позволяет автоматизировать процесс сборки, тестирования и развертывания приложений. Простыми словами - это автоматическая сборка вашего ПО с уже настроенными этапами запуска, тестирования (автотесты) и разворачиванием на сервере (например, где уже вы будете тестировать руками).
Иногда вы можете задаваться вопросом: но я тестирую руками/пишу автотесты, как мне это может помочь?
Вот несколько пунктов, чем вам поможет CI/CD:
➡️ автоматически без дополнительных действий со стороны разработчика получать новый функционал и разворачивать себе стенд одной кнопкой: без настроенной сборки приложения надо настраивать окружение, прописывать скрипты и прочее. А если CI/CD настроено, то можно просто нажать кнопку и вы уже готовы тестировать.
➡️ не получать неработающую сборку: не знаю, как у вас, а у меня бывали в работе задачи, которые просто приводили к падению при их запуске. И каждый раз нужно дойти в логи, узнать, это у меня не работает или разработчик отдал сырую задачу, идти к разработчику, ну и так далее. А тут с настроенным CI/CD (и хорошими тестами) задача просто бы не развернулась, и я не тратила бы время на выяснение причин.
➡️ автоматический прогонять автотесты, регресс и составлять отчеты: прогон автотестов на дальней дистанции позволит вам узнать, какой функционал чаще всего приходит в негодность и чему нужно уделить особое внимание. А еще вам просто не нужно будет ругами прогонять тесты и занимать мощности своего компьютера.
Чем CI/CD поможет именно команде:
➡️ настроить сбор метрик на проекте и, благодаря этому, мониторить их: например, собирать данные о производительности приложения: среднее время ответа, количество запросов к приложению и т.д.
➡️ создать нормальное количество unit-тестов со стороны разработчика: при настройке CI/CD можно настроить несколько этапов, одним из которых может быть количество покрытых тестами функциональности. Таким образом непокрытый (и хотя бы частично непротестированный!) функционал просто не дойдет до тестировщиков (и вы не будете страдать)
➡️ уменьшить количество исправлений на код-ревью: также один из этапов quality gate - это запуск задач, которые направлены на проверку качества кода. Это поможет нам меньше возвращать функционал на этапе код ревью кода.
➡️ упростить и автоматизировать "уход" до клиента: первоначальная цель CD заключалась именно в этом: правильно настроенные quality gate позволят нам в автоматизированном режиме отдавать новый функционал нашим клиентам и таким образом сокращать время между разработкой и поставкой функциональности.
К слову, CI/CD это не панацея: у нас все еще присутствует человеческий фактор. Например, на одной работе devOps решил выключить прогон unit-тестов, благодаря чему баг, который они бы словили, успешно проник на прод. Не будьте как этот devOps.
Полезные материалы
Почитать:
📄Что такое CI/CD
📄Зачем CI/CD тестировщикам?
📄Хорошая статья про CI/CD в целом и конкретный кейс
📄Вопросы по CI/CD на собеседованиях
📄Инфраструктура и пайплайн (CI/CD) (qa bible): много полезных ссылок
Послушать/посмотреть:
🎦Лайв-кодинг: GitLab CI as Quality Gates: CI глазами тестировщика" / Александра Пшеборовская