От рутины к эффективности: как QA-инженер может изменить релизный процесс в большой команде
<img src="https://habrastorage.org/getpro/habr/upload_files/27b/48e/e34/27b48ee34983170d40ef8e70d3415373.jpeg" /><p>Привет, Хабр! Меня зовут Елена Бабенко, я QA lead в одной из продуктовых команд Pangolin в Сбертехе. Мы разрабатываем СУБД, процесс это сложный и интересный, ведь помимо теории программирования и тестирования нам нужно разбираться и в работе PostgreSQL. Но здесь я хочу рассказать не про ежедневные задачи тестирования, а про релизы и роль выпускающего QA-инженера (обычно эту роль у нас берёт на себя один из QA‑лидов). Эта статья будет интересна тестировщикам, которые работают с крупными продуктами, чьи релизы занимают не час, а обычно пару недель.</p><p>СУБД Pangolin — один из таких больших продуктов, и примерно четыре раза в год у нас случается релиз. В каждую версию входят новые фичи, багфиксы, иногда — рефакторинг и другие улучшалки. В общем, большое количество нового кода. Конечно, каждая отдельная задача уже протестирована, но перед выходом в эксплуатацию необходимо стабилизировать уже всю сборку как цельный продукт.</p><p>От релиза к релизу мы улучшаем наши процессы и ускоряем разработку. У нас есть много Quality Gates для проверки — помимо стандартных юнитов, мы запускаем регрессы в различных вариациях (состояние сборки по умолчанию, кастомные комбинации, например с разными типами лицензий), обновления с предыдущих версий (здесь же и откаты), совместимость с разными ОС и другое.</p><p>Для многих запуск всех проверок — это муторная и неинтересная работа, которая ещё и занимает порядочно времени. А ведь потом надо все эти проверки сверить, проанализировать падения тестов, разобраться с багами (если такие будут), починить флакающие тесты... И в конце концов запустить это всё ещё раз для финального сбора отчётов.</p> <a href="https://habr.com/ru/articles/1077512/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1077512#habracut">Читать далее</a>