Около года назад команда 2gis.ru приняла решение перейти от репозитория с одной dev-веткой на систему бранчевания и процессы GitHub Flow.
Инфраструктура была готова к новым процессам и новым скоростям. Но команде пришлось серьезно перестроиться. Особенно острой стала тема тестирования.
В GitHub Flow нет тестировщиков, пример брать было не с кого, и нам самим пришлось придумывать как встроить тестирование в новый процесс.
Нам нужно было решить:
— Что значит выпускать продукт без тестировщиков? — Где ввел в заблуждение GitHub Flow?
— Что такое “всегда стабильная master-ветка” и как эту стабильность обеспечить?
— Что делать с долгой регрессией и отладкой в связи с учащением релизов?
— Как ускорить написание и поддержку АТ?
— Что будет с качеством продукта?
Я расскажу о том, как мы «гнули» тестирование и как изменились роли тестировщиков в команде, работающей по адаптированному GitHub Flow.
48. Как тестируем
• автотесты всегда, везде и всей
командой
• чините причины багов
• сотрудничайте с разработкой
48
49. • автотесты всегда, везде и всей
командой
• чините причины багов
• сотрудничайте с разработкой
• stable master
• командные соглашения
Как тестируем
49
58. Почитать
GitHub Flow — немного сложнее, чем на бумаге
http://techno.2gis.ru/lectures/13
GitHub Flow: рабочий процесс GitHub
http://habrahabr.ru/post/189046/
Как релизится GitHub
http://habrahabr.ru/post/197026/
58