Привет, я Евгений Иванченко, лидер Web QA Гильдии в Dodo Engineering. При иных обстоятельствах я мог бы оказаться главой отдела тестирования, но у нас нет такого отдела. Нет, это не результат техногенной или юридической катастрофы. Мы его просто распустили.
Разумеется, это не значит, что мы перестали тестировать наши продукты. Мы только избавились от выделенной команды тестирования. Как в Dodo Engineering провели глобальную перестройку процессов и чем в этом помог Kaiten — читайте под катом.
Распиливаем QA-монолит
Прежде чем рассказывать как, стоит обсудить зачем. Анализируя свои процессы, мы пришли к выводу, что их «бутылочным горлышком» стало взаимодействие команд разработки и тестирования.
Разработка и тестирование — две стороны одной медали. Пока фича не протестирована, ее, по сути, и вовсе нет. Задача девелопера не может считаться завершенной, пока не проведены тесты. Это значит, что любая задержка между разработкой и тестированием увеличивает время выполнения задачи. А чем сложнее взаимодействие между разработчиком и тестировщиком, тем больше эта задержка и тем больше TTM.
В идеальном мире каждый разработчик сам себе тестировщик, но не у каждого есть все необходимые компетенции: непонятно, кто должен отвечать за интеграционные тесты, и прочие подобные нюансы. Однако хорошо, когда тестировщик сидит за соседним столом с разработчиком. У Milfgard была недавно статья про осьминога. Там сказано, что, грубо говоря, у осьминога в каждом щупальце свой микромозг. Там, где нужно снизить latency, часто помогает децентрализация.
Мы решили попробовать себя в роли осьминога. Теперь написанием базовых автотестов у нас занимаются сами разработчики. Когда им нужно покрыть продукт какими-то более сложными тестами, они обращаются к тестировщикам из своей команды. Теперь разработка и тестирование близки, как процессор и кеш первого уровня.
Значит ли это, что каждый тестировщик теперь сам по себе? Разумеется, нет, ведь есть еще QA-гильдия. Она используется для «слабого связывания» тестировщиков — не как жесткая организационная единица, а как комьюнити и как мозговой центр для «мета-QA», для работы над нашими QA-процессами.
Теперь я расскажу, как мы организовали все эти рабочие процессы с помощью Kaiten.
Долой дедукцию, даешь продукцию
Как устроена работа в продуктовой команде? В Kaiten для каждой команды выделено свое рабочее пространство. Там создаются карточки задач, и там они проходят некий предопределенный жизненный цикл.
Стартовое поле для всех карточек — доска Inbox. Туда попадают любые задачи, которые мы не можем решить в моменте. Необязательно это задачи, связанные с разработкой. Например, там может быть карточка о том, что надо снять видео в пиццерии, где будет показано использование нового функционала.
Помните сцену из «Гарри Поттера» с Распределяющей шляпой? Вот примерно это происходит с карточками дальше. Задачи с доски Inbox разбираются на стендапе, и для каждой из них решается два главных вопроса:
Делать сейчас или отложить на потом. Карточка либо попадает в бэклог текущего спринта, либо просто в бэклог, откуда ее достанут перед одним из следующих спринтов.
Если карточка попадает в текущий бэклог, ей нужно выбрать «факультет», то есть тип. Бывают задачи технические, исследовательские, бизнесовые; бывают карточки с багами и, наконец, просто вопросы. Дальше определяется срочность задачи. Expedite — те, которые нужны чем скорее, тем лучше. Sprint Goal — задачи, связанные с целью спринта. Остальные становятся «волшебниками вне категорий» и получают срочность Miscellaneous.
На доске спринта происходит настольная игра, хорошо знакомая всем пользователям Agile-методологий. Карточки задач по мере выполнения перемещаются из колонки в колонку. Сперва задача попадает в To Do. Когда за нее кто-то взялся, она переходит в In progress. Когда появляется какая-то фича, готовая к деплою, задача предсказуемо оказывается в колонке Deployment. Если есть какие-то вещи, которые нужно проверить после деплоя, для этого есть колонка Post production.
Обратите внимание на отсутствие колонки, посвященной тестированию. Как говорилось выше, тестирование — часть разработки. Задача не считается завершенной, пока по ней не написали и не прогнали все необходимые тесты.
Стандартные юнит-тесты разработчик вполне способен написать самостоятельно. Иногда, когда задача лежит в колонке In progress или Deployment, разработчик понимает, что количество потенциальных граблей больше обычного, и убедиться в их отсутствии — это уже задача со звездочкой. Тогда он тегает тестировщика (того самого, что за соседним столом). Тот подключается к тестированию и вскоре составляет исчерпывающий список багов.
Kaiten полезен не только тем, что превращает рабочий процесс в настольную игру. Например, у нас реализована интеграция с GitHub. В сообщении в коммите можно указать номер задачи в Kaiten, и в комментарий к карточке задачи автоматически подтянется ссылка на коммит и его автора.
Как пройти в Гильдию QA?
Децентрализация таит в себе потенциальную опасность. Если просто посадить в каждый отдел по тестировщику, замкнутый в рамках своей команды сотрудник в лучшем случае будет постоянно изобретать велосипеды, в худшем — закиснет в одиночестве и перестанет профессионально расти. Гильдия объединяет тестировщиков определенного направления (напомню, я лидер Web QA Гильдии, у тестировщиков мобильных приложений своя песочница и свои куличики). Задача Гильдии — cоздание единого профессионального пространства, совершенствование инструментов, методологий и процессов.
Рабочее пространство Гильдии в Kaiten чем-то похоже на командное. Есть стартовая клетка — одноколоночная доска Inbox, и есть доска, где происходит работа по задачам. На второй доске — колонки, соответствующие этапам жизненного цикла: To Do, In progress, Done.
Характерный пример задачи Гильдии — внедрение Allure TestOps. Такие вещи нужно делать в масштабах всей компании — для отдельной команды это и не так полезно, да и сложновато. Но если сделать это глобально, вырастает качество в целом.
Еще один пример, по которому у нас есть отдельная статья, — внедрение практики написания постмортемов. Вроде бы интуитивно понятно, что когда случается критичный баг на проде, недостаточно его просто пофиксить, надо сделать какие-то выводы. Но в разгаре работы выводы делать некогда, а потом очень легко забыть и забить. Именно поэтому появилась практика написания постмортемов — практика обязательная, контролируемая и детализированная. И появилась она благодаря Гильдии.
Когда я сказал, что у нас больше нет отдела тестирования, я чуть-чуть, самую малость слукавил. Иногда Гильдия работает как отделозаменитель. Каждая команда работает над своим микросервисом, но в итоге мы все делаем единый продукт, монолит. Задачи, связанные с тестированием монолита, нельзя отдать какой-то одной продуктовой команде, поэтому их берет на себя Гильдия.
Поскольку ни одна команда не является владельцем монолита, возникает вопрос: кто должен отвечать за его релиз? Этот вопрос мы также решаем децентрализованно. По специальным правилам выбирается «релизмен», которые становится ответственным за данный конкретный релиз. Его обязанности не очень сложные, но с непривычки в них можно и запутаться, поэтому Гильдия QA сделала специального бота. Он создает в Kaiten карточку с чек-листом, по которому должен пройти релизмен, а также колонку этого релиза на доске монолита, чат в Slack, pull request на GitHub и другие вещи, которые легко автоматизировать. Про бота у нас тоже есть отдельная статья.
Что важнее: инструменты или процессы? Вопрос из разряда «что было раньше: курица или яйцо?». Процесс создает спрос на инструмент, однако без подходящего инструмента процесс не наладить.
У Kaiten много достоинств: низкий порог входа, глубокие возможности кастомизации, да и страна-производитель сегодня очень важна. Делает ли это его серебряной пулей? Нет. Но нам и не нужна серебряная пуля. Нам был нужен надежный стальной молоток с эргономичной ручкой. Мы его нашли и с его помощью сколотили свои новые процессы.
Какими системами визуального управления проектами вы пользуетесь на работе? Чем они вас радуют, с чем приходится кое-как мириться? Пишите в комментариях.
Кроме Хабра я пишу в телеграм-канал QAжется работает, подписывайтесь. Недавно делился схемой, которая заменяет QA-инженера (меня) в команде разработки в части небизнесовой прожарки задач.