Привет, Хабр! Меня зовут Максим Бутаков, я работаю руководителем отдела контроля качества и тестирования в компании «ВТБ Лизинг». Сегодня я хочу рассказать о создании этого направления: о том, как нам удалось менее чем за три года улучшить качество продукта и существенно уменьшить количество багов. Думаю, под катом найдётся чем вас удивить.
Бизнес — это всегда гонка. И в ней, как правило, побеждает не умный, а быстрый. Однако закон этот работает только на коротких дистанциях. Одержать победу в сражении не значит выиграть войну.
То же и с информационными системами. Можно быстро вывести продукт на рынок, но что станет с ним спустя время?
В крупных компаниях для информационных продуктов существует два пути развития:
Проект превращается в большой, медленный и неповоротливый монолит, неспособный к дальнейшему развитию и обслуживанию потребностей бизнеса и клиентов.
Компании вовремя адаптируются, меняют первоначальные подходы, и проект получает вторую жизнь.
Исходное состояние
В компанию ВТБ Лизинг я устроился в начале осени 2018 года на должность руководителя группы тестирования. Одна из основных систем, с которой мы работали и работаем по сей день, называется Microsoft Dynamics CRM. Она создана для организации, консолидации и структурирования информации при взаимодействии с клиентами. Наш CRM помогает бизнесу избавить внутренних пользователей от путаницы и хаоса на всех этапах рабочего процесса. Для разработки это коробочное решение даёт инструменты, позволяющие гибко расширяться и модифицироваться. Работа менеджеров в системе организована по принципу ведения рабочих потоков.
Рабочий поток — это контейнер для обогащения, маршрутизации и назначения рабочих элементов. Правила маршрутизации для рабочего потока состоят из правил классификации работ и правил «маршрут в очереди».
На момент моего прихода группа контроля качества и тестирования (ГККиТ) только формировалась. Единого процесса проверки функциональности не существовало. Контроль качества осуществлялся условно: что-то проверяли разработчики совместно с аналитиками, что-то смотрели бизнес-пользователи. Официально релизы выходили один раз в два месяца, и зачастую получалось так, что в прод уходил сырой релиз, успешный только формально (поставленный в запланированный срок). После каждого такого релиза прод могло лихорадить по две недели, пока нон-стопом лились хотфиксы. Нередко случались и сбои. Особый негатив испытывали бизнес-пользователи, т. к. им часто приходилось полностью вживаться в роль тестировщиков. Очевидно, подобный подход демотивировал сотрудников, да и время их — само по себе дорогое удовольствие, особенно когда они вынуждены с головой погружаться в не совсем понятный для себя процесс тестирования и «тушить пожары» вместо выполнения бизнес-задач. Надо было срочно исправлять проблемы, влияющие на качество продукта и бизнес-процессы.
Первые трудности
Мы организовали команду тестирования и формализовали алгоритм выпуска. На всех стадиях разработки к процессу стали подключаться тестировщики.
Тестировщик — нулевой пользователь системы, который должен хорошо знать продукт как снаружи, так и изнутри. Его работа направлена прежде всего на обеспечение корректного опыта пользователя.
Проблема номер раз
Первой большой проблемой стало то, что лишь малая часть информации по продукту была зафиксирована в едином структурированном формате. Чаще это были небольшие описания атомарных доработок, из которых трудно сложить общую картину. Наиболее полными знаниями о работе системы обладали лишь несколько ключевых сотрудников. На начальных этапах формирования базовых дымовых и сквозных тестов эксперты и аналитики работали с постоянным перегрузом, принимая на себя весь поток вопросов от тестировщиков системы. Бывали дни, полностью состоявшие из сессий вопросов и ответов.
Словарь терминов
Дымовые тесты — минимальный набор тестов, позволяющий сделать вывод о работоспособности основных функций и модулей системы и о наличии быстро обнаруживаемых критических и блокирующих дефектов.
Сквозные тесты — набор тестов, позволяющий пройти полный пользовательский путь бизнес-функции вместе со всеми интеграциями системы.
Регрессионные тесты — набор тестов, направленных на обнаружение дефектов в уже протестированном функционале приложения, который находится в проде. Эти тесты позволяют убедиться, что обновлённая сборка не создаёт новых дефектов.
Проблема номер два
После того как у команды тестирования появилось понимание системы и стали регулярно проводиться регрессионные тесты, мы столкнулись с новой проблемой: тестировщики отлавливали множество дефектов. Находились и курьёзные кейсы, когда пользователи выстраивали хитроумные цепочки действий с целью обхода ошибок, потому что никто не хотел тратить время на их починку.
Проблема номер три
Ещё одной трудностью стало общее с разработкой окружение. Часто фиксировались конфликты доработок и недоперенесённых решений. Также из-за параллельной разработки и множественных обновлений стало очевидно, что мы не можем гарантировать попадания функционала на продакшн в том виде, в котором он был протестирован (а не в изменённом, например, свежей правкой разработчика).
Подумав над решением, мы добавили испытательные стенды и строго разделили зоны влияния. У нас получилось три стенда:
разработка (DEV);
тестирование (TEST);
препрод (PREPROD).
Работа на стендах в процессе разработки, тестирования и внедрения новой функциональности стала жёстко регламентироваться.
Стенд разработки предназначен только для разработчиков и аналитиков. На нём создаются новые решения и происходит первичная приёмка аналитиками.
Для тестировщиков создан отдельный стенд, на котором осуществляется полная проверка функциональности.
Последний стенд — препрод — предназначен для приёмки бизнесом. Здесь исключается конфликт версий. Конечный релиз ставится сюда точно в таком виде, в котором он попадёт на продакшн. У тестировщиков есть доступ к этому стенду; на нём они готовят тестовые данные и координируют тестирование решений бизнес-пользователями. Через этот процесс теперь проходит каждый релиз.
У каждого этапа разработки и внедрения есть свой куратор. Перенос функционала между средами осуществляется только с его согласия. После каждого переноса проводятся обязательные дымовые тесты.
Такое многофазное тестирование позволило сильно снизить риски возникновения ошибок на проде. А за счёт чёткого разделения зон ответственности ошибки, связанные с внедрением, стали случаться крайне редко и их всегда удаётся быстро локализовать, оперативно выкатив хотфикс в течение одного-двух часов.
Следующий этап эволюции ГККиТ
Время шло. Количество кейсов, выполняемых тестировщиками, увеличивалось. Бизнес всегда нацелен на развитие: росло количество идей, но вместе с ним возрастала и цена ошибок. При этом качество продукта, скорость его разработки и удовлетворённость пользователей тоже должны были показывать положительную динамику. Оказалось, что в отсутствие автоматизации тестирование стало узким горлышком всего процесса разработки. Мы поняли, что необходимо продолжать эволюцию. К счастью, в нужный момент компания обеспечила для этого комфортные условия.
В конце 2019 года у меня сменился руководитель, который поставил перед нами довольно амбициозные цели:
Создать «метрики» прозрачности.
Провести пилотирование гибких методологий разработки (agile) и сформировать первые кросс-функциональные команды.
Масштабировать штат управления на 60+ % .
Развить автотестирование и внедрить автоматический мониторинг доступности бизнес-процессов в проде.
Сделать первые шаги к DevOps.
И всё это на фоне карантина и всеобщего локдауна, когда компания полным составом перешла на удалёнку.
Забегая вперёд, могу сказать, что по всем этим пунктам мы показали хороший результат. Эффективность работы управления за время карантина даже подросла.
Первое, что надо было сделать — прокачать спецов для написания автоматизированных тестов и выбрать подходящую систему для их создания. Ведь на качество влияют не только скиллы и профессионализм тестировщиков, но и то, какими сервисами они пользуются. Вообще говоря, навыки даже прокачанных специалистов всегда нуждаются в апгрейде.
При выборе системы автоматизации мы остановились на «Хамелеоне». Этот фреймворк отвечал всем нашим требованиям. Собственно, он и нацелен на ускорение старта проектов, повышение качества тестирования и упрощение введения новичков в работу.
Чтобы проект жил и развивался, необходимы частые изменения. Но при этом нужно быть уверенным, что они ничего не сломают. С помощью «Хамелеона» мы автоматизировали большую часть регрессионного тестирования. Функциональные тесты готовятся с момента согласования требований, поэтому можно с уверенностью утверждать, что весь наш проект отвечает такому важному критерию как тестируемость. После внедрения функционала на прод написанные тесты становятся регрессионными и передаются в автоматизацию.
Нужно больше качества
Может показаться, что всё уже было хорошо, однако мы не собирались останавливаться на достигнутом. Двигаясь в сторону непрерывной интеграции и развёртывания (CI/CD), мы унифицировали процесс разработки и доставки функциональности на производственные среды. Работа с задачами ведётся в JIRA, а процесс отлажен таким образом, что позволяет осуществлять внедрение задачи по готовности. В целом на текущий момент мы внедряем 1–3 крупных функциональных блока и порядка 20 мелких задач в неделю.
Каждый день мы продолжаем наращивать покрытие автотестами. На текущий момент более 50 % всей функциональности проекта проверяется автоматически.
Ко всему прочему, автотесты запускаются каждую ночь на тестовом и препродовском стендах. Утром дежурный автоматизатор анализирует прогон и фиксирует дефекты в JIRA. Совместно с техподдержкой мы ввели регулярное измерение количества пользовательских обращений по инцидентам, долетающим до команды разработки. Постоянно синхронизируем эти данные с бизнесом, чтобы сформировать реальную картину и выделить проблемы, которые нужно решить в первую очередь.
Кроме того, за прошедший год мы разработали и внедрили систему бизнес-мониторинга. Написана она на чистой Java. Суть её заключается в следующем: наши роботы-тестировщики циклически проверяют функциональность в режиме реального времени. Особенность системы в том, что роботы не просто тестируют доступность сервиса, а полностью проверяют бизнес-цепочки действий в приложении (юзер-стори), так как именно они представляют ценность для конечных пользователей. Все проверки визуально отображаются в Grafana. Каждый сотрудник компании может в любой момент проверить статус мониторинга, перейдя по специальной ссылке. В случае провала теста данные о сбое отправляются в телеграм-бот. В будущем мы планируем установить на каждом этаже физические мониторы с непрерывной демонстрацией статуса систем.
Рецепт успеха. Итоги
Итак, с чего мы начали и к чему пришли?
Менее чем за три года нам удалось не просто стабилизировать качество IT-систем и бизнеса — мы изменили процессы и сам подход к оценке качества. Благодаря нашим показателям бизнес чётко осознал важность функции тестирования в компании. Всё большее количество IT-систем переходит на тестирование, и мы планируем довести этот показатель до 100 %. Выросла и численность сотрудников, а наша группа трансформировалась в отдел контроля качества и тестирования (ОККиТ).
Как руководитель основное внимание я уделяю атмосфере в команде и людям. Если сотрудник не вовлечён в работу, то и результат будет соответствующим. Несмотря на то, что в каждой задаче есть элемент рутины, у нас в тестировании довольно трудно заскучать. Меняются процессы, меняются инструменты, меняется сам бизнес — сейчас каждый член команды осознает свою значимость, а также видит и чувствует, как его деятельность улучшает показатели всей компании.
Около половины команды у нас состоит из сотрудников подрядных организаций. Зачастую аутстафферы придерживаются правила «выполнять свои таски и не вмешиваться» — это может быть некритично в других направлениях, но только не в ОККиТ. Ведь качество продукта — это не только про соответствие озвученным требованиям, но и про сами требования. Про дополнение явных критериев оценки своими, ориентированными не на потребности заказчика, а на удобство конечного пользователя. Пользовательский опыт, юзабилити, интерфейс, отзывчивость, скорость релизов, их стабильность — всё это тоже относится к качеству продукта. Это своего рода минное поле и место для постоянных сомнений: «А будет ли так удобно пользователю?», «Повлияют ли те или иные изменения на работу другой части системы?» и т. д. И чтобы не подорвать доверие пользователей, нужно на каждом этапе разработки смотреть, что можно улучшить. Нужно постоянно сомневаться и думать.
Удалось ли мне и моей команде в конечном итоге улучшить качество? Безусловно! Но главное, что у нас получилось — это наладить прозрачное и понятное взаимодействие в коллективе, пробудить заинтересованность в проекте у каждого участника процесса, превратить команду в единый организм, стремящийся к общим целям.
В конечном итоге перед нами стоят глобальные цели по трансформации подразделения. В ближайшее время начнётся работа по построению пайплайнов и CI/CD, а кроме того, мы стали принимать на сопровождение всё больше IT-систем. При этом мы продолжаем учиться, смотрим вперёд, выявляем процессы, которые можно автоматизировать, применяем новые методы по контролю качества и всегда стремимся стать лучше. А как обстоят дела в ваших командах? Делитесь своим опытом в комментариях!