Рынок ИТ переживает не лучшие времена: охлаждение спроса как на специалистов, так и на ИТ-продукты, уменьшение налоговых льгот для ИТ-компаний, а для ИТ-специалистов — ухудшение условий по ипотеке, рост налогов, наем сократился или вовсе остановился. Это ведет к тому, что компании ищут способы достигать целей при ограниченных ресурсах, уменьшать свои расходы за счет повышения эффективности труда. Один из методов — оптимизация рабочих процессов, в том числе QA.
Меня зовут Юнес, я Senior SDET в Т-Банке и провожу аудиты уже три года. За это время изучил десятки проектов и помог командам в оптимизации процессов. На одном из последних проектов удалось снизить соотношение дефектов прод/тест за месяц с 0,49 в августе до 0 в ноябре. В статье расскажу, как мы с коллегами выполняем аудит, о наиболее частых ошибках аудиторов и о том, как начать выполнять аудиты в компании.
Введение в аудит
Сначала определим значение слова «аудит». Я буду использовать определение ISTQB.
Аудит (audit) — независимый анализ рабочего продукта или процесса, выполняемый третьей стороной с целью оценки его соответствия установленным критериям.
В нашем случае третья сторона — QA- или SDET-инженеры, которые не связаны с анализируемым продуктом или процессом. Если речь о продукте, то они не вносят туда изменения, не управляют им и не заинтересованы в его восхвалении или принижении. В случае с процессом — они не занимались его созданием, не подчиняются владельцам этого процесса, не управляют им в данный момент.
Критериями являются стандарты и рекомендации внутри Т-Банка, которые устанавливают не аудиторы, а ответственные за это QA-эксперты. Так мы стремимся к максимально объективной оценке.
Аудиты являются краткосрочной активностью, не более трех недель. Большую часть времени аудиторы работают на своем проекте — выделять целый квартал на менторинг и развитие проекта они не могут.
Цель аудита процессов
Аудит никогда не выполняется спонтанно. Аудиторы не заходят на проект как санинспекция в продуктовый ларек, чтобы найти доказательства кривых QA-процессов. Лид не прячет метрики под ковер, тестировщик не закидывает Allure-отчеты в шреддер, стажер не съедает неудачный баг-репорт.
Аудит запрашивают. Это может быть инициатива команды, лида или руководства. Причин заказать аудит много: от желания оптимизировать процессы до необходимости решить сложную проблему.
Что нужно перед началом аудита
Необходимо тщательно подготовиться, прежде чем бросаться в пучину метрик. Подготовку начинают те, кто заказывает аудит.
Важно определить цель. Чаще всего просят найти слабые места, которые могут доставить проблемы. Исходя из нашего опыта, команды с высоким уровнем компетенций запрашивают помощь в ситуации, когда нужно второе мнение: взгляд со стороны позволяет найти проблемы, которые за годы работы на проекте перестали мозолить глаза команде. Команды без старших инженеров могут прийти с совершенно разными запросами. Пару раз приходили с конкретной проблемой, которую сами не могли решить.
Например, в одном проекте некорректно записывались логи автотестов при параллельном выполнении: записи смешивались между собой, а иногда дублировались. Своими силами не удалось побороть проблему, и решили заказать расследование, чтобы разобраться. Иногда просят оценить масштабируемость («Мы планируем увеличить покрытие в два раза. Наша текущая архитектура тестов осилит еще 500 тест-кейсов?») или найти точки роста («Хотим писать тесты лучше, но не знаем, в какую сторону копать»).
Говорят, что правильно заданный вопрос — половина ответа. Не всегда нужен именно аудит. Может, требуется короткая консультаци�� или менторинг.
Если все же нужен аудит, важно ввести аудитора в контекст ситуации. Для этого коллеги заполняют анкету, в которой рассказывают о своем проекте. Самые важные части анкеты:
Метрики проекта (все, что есть).
Описание проекта (состав команды, чем занимаются, какие нюансы).
Описание процессов (как проходит релиз, как разбираются баги, как ставятся задачи и пр.).
Состояние автоматизации на проекте (что по покрытию, какая пирамида, кто пишет тесты и когда).
Из-за чего обратились.
Анкета подробная, есть искушение пропустить шаг и просто обсудить словами, но она решает много проблем:
Не позволяет потеряться информации: они забыли рассказать, мы забыли спросить или записать. Например, команда перевезла часть автотестов в новый проект, но ссылку аудиторы получили только на старый.
Избегает неточности: вроде покрытие 80%, в прошлом квартале слышал такую цифру. Конечно, аудиторы могут найти или посчитать все сами, но это увеличивает время работы при нулевом КПД. Большинство данных уже есть в готовом виде, просто их нужно передать.
Не допускает лишней траты денег: лид собрал всю команду на созвон с аудиторами, чтобы гарантированно ответить на их вопросы. В итоге на все вопросы отвечает лид или наиболее разбирающийся QA, а остальные молчат и тратят свое время впустую.
Исключает незафиксированные договоренности («Мы думали, вы поймете сами, что нам нужен аудит не всего проекта, а только наиболее актуальных тестов»).
Когда анкета готова, аудитор ее изучил и у него не возникло дополнительных вопросов — начинается аудит.
Как проходит аудит
В начале аудитор готовит пространство для работы: получает доступы, запасается ссылками на документацию, клонирует репозиторий с тестами и прочее. Затем приступает к анализу.
У нас нет жестко зафиксированного процесса аудита («Сначала смотри X, потом Y, потом Z»), есть только рекомендации и практический опыт. Мы у себя выделяем два подхода, как лучше проводить аудит: снизу вверх и сверху вниз.
Подх��д «снизу вверх» заключается в том, что мы сначала смотрим код автотестов, потом инфраструктуру, потом процессы и метрики. Подход «сверху вниз» — в обратном порядке: начинаем с метрик и процессов, а потом идем вниз, до инфраструктуры и кода. Каждый вариант имеет свои преимущества.
Если начать с метрик и процессов, то проще заранее понять проблемы проекта и их масштаб, примерно оценить влияние проблемных процессов на уровни ниже. Это экономит время, особенно если речь о больших проектах. Если метрики искажены или их вовсе нет, подход снизу вверх позволит увидеть сначала симптомы и ситуацию «на земле», которую ежедневно наблюдают коллеги в своей работе, а потом перейти к процессам для поиска причин обнаруженных проблем. Но оба подхода должны в итоге дать аудитору полный список проблем на проекте и причину их появления, чтобы команда в полной мере понимала свою ситуацию.
Этап работы с кодом прост: изучаем глазами и линтерами. Важно понять:
как пишутся тесты;
насколько хорошо организованы проверки;
какова архитектура тестов;
какие паттерны или антипаттерны есть в проекте;
правильно ли используются инструменты.
Рубрика советов для аудитора
Некоторые аудиторы слишком погружаются в детали и мелочи, забывая о первопричинах и глобальной картине. «Вы тут оставили код для дебага, тут метод неправильно назван, а в этом классе неиспользуемый метод. Исправьте, чтобы этого не было». Получается такой человек-линтер. Это не помогает предотвращать ошибки, процессы не меняются, подход ос��ается прежним.
Чаще всего проблемы в коде или инфраструктуре — это симптомы незрелых или проблемных процессов. Плохое код-ревью, отсутствие линтеров или работы с техдолгом — пробоина, из которой льются ошибки и баги, которые команда может вычерпывать, тратя драгоценное время и ресурсы каждый спринт. Цель аудитора — найти эту пробоину в проекте и придумать, как закрыть с максимальной эффективностью.
Этап инфраструктуры требует комплексного подхода, так как тянет за собой длинную цепочку сторонних интеграций. Нужно ответить на вопросы:
хорошо ли написан пайплайн;
стабильны ли запуски;
что с тестовыми контурами и так далее.
Кто бы ни отвечал за CI/CD — DevOps, разработчики или тестировщики, — инфраструктура должна работать на пользу проекту, а не вставлять палки в колеса.
На этапе работы с процессами важно тщательно ознакомиться с тем, что описали в анкете. Если что-то неясно — запросить дополнительную информацию. В идеале у аудитора должна быть полная картина процесса разработки: от написания кода до деплоя.
Еще нужно понять, как текущие процессы влияют на продукт и как их улучшить. Например, команда работает с тестовыми данными, которые готовит вручную. QA вели таблицу в Confluence, где указывали, какой тестовый клиент для чего нужен, какой из них невалиден. Такая сложная система требовала регулярной и трудоемкой актуализации и поддержки. Нужно было откатывать изменения для каждого клиента после прогона тестов в полуавтоматическом режиме, о параллельном прогоне тестов не могло быть и речи.
Выяснили, что такая ситуация сложилась из-за того, что генерация данных требует времени, а интеграции нестабильны. В ответственный момент тестовые данные могут не создаваться, а тестировать надо. В итоге решили генерировать их, но заранее и с запасом в специальный пул данных.
После анализа процессов смотрим метрики. Сами по себе они не показывают причину проблемы — как температура тела не говорит нам о том, чем заразился пациент. Но это важный индикатор, который дает подсказку о том, что происходит.
Выделю группы метрик и пояснения к ним:
Метрики по тестам. Охват тестами (включая пирамиду тестов), частота запусков, объем покрытия, время выполнения регрессионного тестирования и другие показатели эффективности тестов.
Метрики по багам. Соотношение количества выявленных дефектов к числу завершенных задач, количество багов, попавших на продакшен, уровень критичности обнаруженных ошибок и динамика их устранения.
Метрики по релизам. Время выхода на рынок (TTM), Lead Time, стабильность релизов, длительность каждого этапа цикла разработки: анализ → разработка → тестирование.
Рубрика советов для аудитора
Не стоит пытаться все аудируемые проекты приводить к своему проекту. Эта ошибка иногда встречается у новичков-аудиторов. «„Мы на проекте используем Cucumber, и это очень удобно, поэтому напишу, чтобы тоже переходили“». При этом на проекте тесты уже расписаны через Allure Steps и в отчетах есть описание тестов, понятное аналитикам.
Опыт аудитора — это ценно и важно, набитые шишки позволяют помочь другим не повторять ошибок, но важно учитывать контекст другого проекта. Если что-то работало — нет гарантии, что сейчас тоже сработает. Это лишь повод для изучения, будет ли это работать тут, в конкретных обстоятельствах, и стоит ли оно переделок и вложенного труда.
Как формулировать рекомендации
Все замечания, мысли и вопросы фиксируются в заметках. Когда все изучено, аудиторы составляют рекомендации. Сначала определяется первопричина. Например, в проекте много проблемного кода: неиспользуемые классы и переменные, недостижимый код.
Проблема не в процессе ревью — такое там легко пропустить. Проблема в том, что нет линтера, он ловит такие ошибки и блокирует попадание такого кода в репозиторий.
Далее пошагово описывается инструкция, что делать: какой линтер выбрать и почему именно его, как настроить и подключить. Указывается важность и эффективность для каждой рекомендации аудитора. Эффективность показывает импакт изменений на проект, а важность — как быстро стоит исполнить данную рекомендацию.
Высокая важность и высокая эффективность — такие советы являются приоритетными, так как могут оказать значительное положительное влияние на качество тестирования.
Высокая важность и средняя или низкая эффективность — рекомендации важны, но их влияние на проект может быть небыстрым или легко заметным. Команде может потребоваться больше времени или усилий, чтобы увидеть результаты, это работа на долгосрочный результат.
Средняя или низкая важность и высокая эффективность — советы могут быстро и эфф��ктивно влиять на проект, но их общее влияние на качество тестирования может быть ограничено. Они могут быть полезными для решения конкретных проблем или для быстрого улучшения в узкой сфере.
Средняя или низкая важность и средняя или низкая эффективность — советы не приоритетны, так как не приносят быстрых или значимых результатов. Их можно рассматривать как дополнительные или экспериментальные и осуществлять при выполнении более приоритетных действий.
Все зависит от контекста. Если проект завален плохим кодом и это мешает поддерживать тесты, то важность и срочность будут выше. Если исправление проблемы не даст ощутимого положительного эффекта — важность и приоритет снижаются.
После аудита
По результатам выполненного анализа аудитор готовит отчет. Затем проводит встречу с заказчиком и обсуждает результаты, отвечает на вопросы. Команде требуется от пары дней до недели, чтобы ознакомиться с отчетом, задать дополнительные вопросы, завести задачи на исправление.
Рекомендации не обязательны: команда сама выбирает, что взять в работу, что оставить до лучших времен, а что не делать вовсе. Это защищает от ситуации «я начальник аудитор, ты — дурак», когда происходит навязывание изменений вместо убеждения команды в их необходимости.
Через один-два квартала аудитор заходит узнать, как изменилась ситуация: что команда уже сделала, что планирует, как меняется эффективность проекта и метрики. Важно не работать вслепую, а оценивать, насколько полезны советы и рекомендации. Хоть это и не всегда возможно, ведь многие изменения могут работать вдолгую, да и команда вносит свои коррективы.
Чем полезен аудит
Аудиты — важная часть процесса обеспечения качества, так как помогает понять, правильно ли мы движемся, оптимально ли то, что мы делаем.
Быть аудитором непросто, но интересно и полезно. Повышается насмотренность: много разных комбинаций инструментов, процессов и команд, которые всегда делают что-то уникальное. Вместе с этим аудитор влияет на большое количество людей: помогает коллегам найти проблемы, узнать что-то полезное, да и сам обучается в процессе. Происходит как бы взаимное опыление знаниями и опытом. Плюс нетворкинг: аудитор пересекается с людьми, с которым в обычной работе бы не встретился.
Заказчики получают бонусы в виде готовых рецептов для решения назревших проблем. Команда получает новые знания, видит зоны роста.
Руководителям приходит дополнительная информация о том, что происходит на проекте, повышается прозрачность. Происходит оптимизация процессов контроля качества, что приводит к улучшению результатов: лучше продукт, меньше багов и так далее.
Как запустить процесс аудитов
С чего начать выполнять аудиты? Если в компании они уже проводятся, то остается пройти обучение и влиться в коллектив.
Если в компании нет такого процесса, но чувствуется, что он будет полезен, рекомендую такой план:
Определить потребность. Если команды не хотят слушать стороннего эксперта, а руководитель потенциального аудитора не готов к тому, чтобы часть рабочего времени уходила на улучшения в других проектах, то шанс на успех невелик. Если затея встречает сопротивление, можно сделать пилотный проект, привести цифры результата, который ожидается от внедрения аудитов.
Найти точку опоры. Должны быть стандарты, на которые можно опираться. Это важно, чтобы не было ситуации как в басне Крылова, когда один аудитор за классическую пирамиду тестирования, второй ставит все на e2e-тесты, а третий считает, что интеграционные тесты — все, что необходимо. Должны быть какие-то базовые соглашения между всеми участниками.
Подготовить описание процесса. Четко расписать, как, когда и зачем выполняется аудит. Кто может его заказать, чего ожидать и прочее. Чем прозрачнее процесс будет для всех, тем лучше.
Запустить пилотный проект. Лучше набить шишки заранее, чем подготовить полноценный процесс с онбордингом, наградами, грамотами и шоколадными медалями. Окажется, что аудит выполняется не неделю, а три, руководству такое не нравится и процесс нужно менять.
Когда процесс аудита доработан, имеет смысл описать способ стать аудитором. Это важно, чтобы не было конфликтов и онбординг новичков был проще.
Грамотно выстроенный аудит будет приносить пользу всем. При этом он должен развиваться вместе с самими аудиторами. С опытом становится понятнее, как в конкретной компании можно улучшить аудит, чтобы он был еще полезнее и эффективнее, начиная от базы знаний или калибровки аудиторов до системы наград и отдельных грейдов.
Выводы
Сейчас компании сфокусированы на оптимизации проектов и процессов, а не на вливании в них бюджетов. Нужны специалисты, которые находят способы сделать эффективнее, не тратя больше ресурсов.
Аудиты — отдельный уровень влияния для опытных QA- и SDET-инженеров. Они позволяют показать на практике, насколько хорошо и эффективно находятся проблемы и пути их решения, создавая более оптимальный процесс обеспечения качества.
А в вашей компании проводят аудиты?
