«Ты будешь единственным тестировщиком на проекте», — услышал я на знакомстве с командой. Ничего страшного, с кем не бывало? «У нас не было постоянного тестировщика, нужно выстраивать все процессы с нуля», — добавил мой будущий тимлид. А вот это уже интереснее.
Меня зовут Илья, я отвечаю за качество A/B‑платформы в Точка Банке. Сегодня я хочу рассказать, как тестировщику воспользоваться безграничной властью с пользой для всех (и немного для себя).
Вводные
Добавлю контекста: в команде, помимо меня, тимлид, три бэкенд‑разработчика Python, фронтенд‑разработчик и гуру, который глубоко понимает методологию A/B‑тестирования и помогает двигать платформу вперёд на серьёзной базе теории. Разработчики сами тестировали задачи, и ответственность за каждую из них была на том, кто её создал. Автоматизация тестирования была только на уровне unit‑тестов.
В команде никогда не было постоянного тестировщика, не было как такового процесса тестирования, отчётов о тестировании, тестовой документации, метрик. Контроль качества был дополнительным бременем на плечах разработки, которая должна была не только тратить время на реализацию новых фичей, но и постоянно их проверять, что сильно тормозило доставку ценности до пользователя.
Наступил день выхода в команду. Никакой подробной информации о процессах и самой А/В‑платформе у меня ещё не было, зато было предвкушение перед предстоящим выстраиванием процессов. На старте мне дали полный карт‑бланш, и я решил начать с дорожной карты: прописать моё видение идеального тестирования через набор определённых практик, прикинуть сроки, расставить приоритеты.
Разработка дорожной карты
При создании дорожной карты я опирался на свое видение прекрасного. Оно базируется на наборе общепринятых стандартов и практик и опыте их внедрения и использования. Например, это Trunk‑based Development, Zero‑Bug Policy, пирамида тестирования, постмортемы, алертинг, метрики качества и описание процесса тестирования: кто и чем занимается, в каком порядке.
С точки зрения менеджмента и внедрения изменений я руководствовался хорошей, на мой взгляд, моделью ADKAR. Если коротко, ADKAR — это модель, которая состоит из пяти элементов, необходимых для организационных изменений:
A (Awareness) — осознание потребности в изменениях.
D (Desire) — желание их поддерживать.
K (Knowledge) — знание, как нужно изменяться.
A (Ability) — способность реализовать изменения.
R (Reinforcement) — закрепление и поддержка результата.
Переход на следующий элемент последовательности возможен только при реализации предыдущего. Очень советую изучить эту модель подробнее, если планируете внедрять какие‑либо изменения у себя в команде.
Мой план
Прежде чем приступить к изменениям, нужно было придумать и спланировать эти изменения. Написать, что именно мы хотим внедрить и в каком порядке, то есть приоритизировать. Мне нравится пользоваться Obsidian, и я нарисовал в нём такой роадмап, чтобы затем представить его команде:
На схеме неясно, что именно является первым этапом, но в нашей внутренней хранилке я продублировал план текстом. Выглядел он так:
Анализ текущей документации и её актуализация.
Описание и внедрение процесса регрессионного тестирования.
Автоматизация регресса (использование Пирамиды тестирования).
Метрики тестирования.
Я нарисовал красивые схемы, расписал процессы с кучей аббревиатур и с гордостью представил их команде. На встрече я ощущал себя как стендапер, над шутками которого никто не смеётся. Если вы видели такие выступления, то вы меня поймёте.
Дело в том, что команда изначально встретила мою инициативу максимально доброжелательно, все были готовы к изменениям. После презентации практически ни у кого не возникло вопросов. Не потому, что было всё понятно или я блестяще всё презентовал, а потому что в моей презентации было нагромождено столько всего, что разобраться было трудно.
После прошедшей встречи я отрефлексировал, что сделал не так, и пришел к следующим выводам.
Ошибка 1: не нужно грузить коллег
Проблема в том, что каждый кубик этого огромного роадмапа содержит много информации, и это путает тех, кто не в контексте. Если бы я сейчас решал такую же задачу, то каждое изменение вводил бы аккуратно и рассказывал бы про него отдельно. Роадмап был бы нужен только мне и тимлиду, чтобы синхронизироваться по планам.
Такой подход привел к тому, что команда банально не понимала, что и за чем будет внедрено.
С одной стороны, есть роадмап со стрелочками, но что скрывается внутри каждого кубика — это отдельная история, которая имеет свою обоснованность, нюансы реализации, а что‑то вообще в процессе было отброшено. А ведь правильно донести свой замысел, объяснить необходимость изменений и их потенциальную пользу — основа внедрения любых изменений.
На мой взгляд, ошибка крайне грубая и стоила, во‑первых, дополнительного времени на повторные объяснения, и, во‑вторых, дистанцировало меня от команды, так как остальные ребята не могли полностью понять происходящее.
Вторая ошибка касалась не самой презентации, а была гораздо глубже — она касалась самого принципа планирования.
Ошибка 2: нельзя отключаться от реальности
Вместо того, чтобы сыпать аббревиатурами и рисовать схемы, для начала нужно было изучить текущее состояние команды. То, что я описал выше, с точки зрения процессов слишком верхнеуровнево. Тут моя мотивация сделать что‑то «здесь и сейчас» сыграла злую шутку. Например, пресловутый TBD может хорошо подойти нашей команде, но только в будущем. Это большое изменение, а наша команда постоянно находится в процессе внедрения, и нагружать её дополнительными перестройками не нужно — это лишний стресс.
Эту истина мне помог понять тимлид. Мы договорились на активное использование фиче‑флагов, а ветка master без develop уже и так была: это компромисс, от которого все оказались в выигрыше.
В итоге, у нас не TBD, а его начальный этап — зато всем комфортно. Любая хорошая идея может не лечь на контекст команды, поэтому имеет смысл адаптировать её под реальность, а не делать как по учебнику.
Если бы я начал продавливать идею более каноничного TBD, то это могло привести либо к отрицанию командой подобных изменений, либо к полному хаосу. Изменений и так слишком много, коллегам тяжело ориентироваться в динамично меняющихся подходах. Поэтому радикальное изменение подхода непосредственно разработки и ревью привело бы к падению морали, повышения уровня стресса и прочим негативным факторам.
Тот факт, что я вовремя осознал, как следует поступить, считаю большой удачей. Я и не отступился от идеи полностью, сумев принести некоторую пользу и не загрузил коллег до упадка сил.
Перед реализацией планов нужно было исправить ошибку 1 и нормально рассказать о своих планах. Я решил, что лучшим решением будет постепенно объяснять каждый шаг, поэтому больше не проводил никаких больших презентаций, а сфокусировался на отдельно взятой задаче и донесения ее ценности. Первым шагом была работа с документацией.
Анализ текущей документации и её актуализация
Начал с описания того, как должен выглядеть процесс тестирования на практике. Оказалось, что описание уже существует и отлично подходит. Тут хочется подчеркнуть: в начале очень хорошо узнать, что уже сделано на проекте. Мне повезло — нужно было только дописать, что теперь проверками занимается тестировщик, а не разработчик.
После этого я занялся тест‑кейсами. С момента ухода прошлого тестировщика время шло, тесты устаревали, поэтому было принято волевое решение всё удалить и начать заново. Не советую решать похожую проблему таким способом, потому что в итоге вам предстоит убить кучу времени на воссоздание базы тест‑кейсов. Проще актуализировать то, что уже есть. В моем случае тест‑кейсов было не много, они были разными, поэтому проще было всё сделать заново. Так что запишем это в ошибки карандашом.
Описание и внедрение процесса регрессионного тестирования
Как я уже говорил ранее, в команде никогда не проводили регресс, а я твёрдо решил сделать его обязательным перед каждым релизом. Это необходимый этап, без которого мы не можем быть уверены в том, что на проде не окажется багов, не относящихся к новым фичам. Новый код всегда может иметь неожиданные сайд‑эффекты.
Следующие пару недель прошли в написании тест‑кейсов для регресса, которые я отдал на ревью команде — ребята проверили, все ли сценарии я покрыл. Несколько ребят из команды, которых я попросил помочь, очень внимательно все посмотрели и подсветили, каких именно сценариев не хватает. Важность регреса все‑таки удалось донести, поэтому к этой просьбе отнеслись максимально серьезно.
Первый регресс прошел, занял примерно один рабочий день. Было найдено 18 багов. По соотношению багов фронтенда было больше (примерно 70 на 30). Это объясняется тем, что у нас один фронтенд‑разработчик и процессы качества фронтенда находились на более низком уровне, чем у бэкенда. При этом критичных багов найдено не было, потому что они до этого находились пользователями на проде и оперативно фиксились. Все найденные баги были приоритизированы, можно было почувствовать удовлетворение от проделанной работы.
Автоматизация регресса
Мне повезло, потому что для этого этапа техлид уже подготовил тестовый фреймворк. Я пришел из команды, которая работала на Kotlin, и сам автоматизировал на этом замечательном (мне до сих пор нравится) языке программирования — Python приходилось вспоминать. Поэтому готовый фреймворк ускорил процесс внедрения автотестов.
Так появились первые smoke‑ и e2e‑тесты, они были встроены в пайплайн. Регресс ускорился на 10%, smoke‑тесты проверяли, что код не рушит критические бэкендовские методы, всё стало неплохо. Кажется, я забыл про интеграционные тесты.
Иногда кажется, что Пирамида тестирования — это просто популярный вопрос на собеседованиях, но при этом не всегда проговаривают реальную ценность идеи. Так вот, пирамида тестирования — это подход, в рамках которого проверки стараются выносить на как можно более низкий уровень, чтобы получать быструю обратную связь от стабильных тестов. Я это решил подчеркнуть специально, потому что данная идея очень помогла мне двинуть процесс реализации на следующий этап эволюции — увеличение покрытия автотестами тест‑кейсов, связанных с регрессом.
Это именно то, чем я решил заняться дальше, и это принесло ощутимый результат: регресс стал занимать буквально 2–3 часа в зависимости от количества найденных ошибок и стабильности тестового контура.
Внедрение данного подхода считаю идеей, которая себя оправдала. Хотя, конечно, у меня был опыт успешного внедрения тестовой соты, но это подход для чисто бэкендовской команды с микросервисами. Для нашей команды пирамида — это то, что нужно.
Но если с идейной точки зрения удалось принять верное решение, то вот с техническими особенностями я не считался и столкнулся со сложностями.
Ошибка 3: идеальная реализация ≠ подходящая
Я стал реализовать автотесты так, как хочу, без оглядки на технические особенности (да, снова те же грабли).
Дело в том, что я хотел гонять интеграционные тесты на изолированном окружении с мокированием всех внешних зависимостей. Для этого нужно было написать docker‑compose, поднимать весь контекст и уже там гонять тесты. Это хорошая практика, если вы хотите быстрые и стабильные тесты, результат которых не зависит от тестовых сред, которые зачастую полны работ или миграций.
На docker‑compose было потрачено много времени, но результата не было. Мне на выручку снова пришел техлид, который рассказал, что поднять окружения с нашими приложениями в GitLab (без пайплайна это всё не имеет смысла) сложно, поэтому лучше не тратить на это время.
Честно говоря, потраченного времени жаль. Нетрудно представить, что таких кейсов могло быть больше одного. Соответственно, я мог потратить на внедрение изменений кратно больше времени, чем получилось по итогу. Кроме всего прочего, это плохо потому, что длительное отсутствие порядка, к которому мы стремились, накопило бы снежный ком проблем, который пришлось бы решать ещё дольше.
Метрики тестирования
Скажу аккуратно: мне не хватало аналитики касательно того, сколько и каких багов у нас заводится, к каким компонентам это относится. Простой скрипт на Python, который использует API Jira, решил эту проблему меньше, чем за час. Мне хотелось увидеть динамику заведения багов для начала в количественном выражении, а также рассмотреть, есть ли перекос: больше багов бэка или фронта? В итоге я получил небольшую таблицу с историчными данными, которую показал команде. Мы заметили несколько точек роста, в частности, фокус на надёжности фронтенда.
Метрик великое множество, их важно использовать рационально и не в коем случае не ставить на первое место, начиная подстраиваться под них. Мы только в процессе развития, у нас в компании есть инструменты для просмотра большого количества данных о задачах, но в данный момент нам не было это нужно. В будущем к этому обязательно придём.
Текущее состояние и выводы
Сейчас внедрены все основные изменения, которые были нужны. Это заняло у меня практически полгода. Вп��реди только поддержка устоявшихся процессов. Аббревиатуры не были бесполезны, но на практике их не получилось перенести as is.
Приведу пример нескольких метрик. Начнём с Allure.
Статистика на 1 апреля (первый мой рабочий день):
Статистика спустя 6 месяцев:
Все тест‑кейсы написаны с нуля, актуальны и оформлены в едином формате. 44 автоматизированных тест‑кейса покрывают самые трудоёмкие сценарии. Увеличить покрытие — одна из следующих целей, над которыми я работаю прямо сейчас.
Можно посмотреть на следующую метрику:
Здесь наглядно видно, что баги перестали забываться. Постепенно мы внедрили процесс, по которому баги не живут в бэклоге до бесконечности и фиксятся. Единственный баг на графике уже пофикшен.
Самый наглядный график — время задач в тестировании:
Теперь это контролируемый и предсказуемый показатель, который постепенно можно улучшать.
Пять уроков за полгода:
TBD — отличная практика, но для команды в процессе активных изменений это был оверкилл. Мы договорились на фиче‑флаги — и все остались довольны. Роадмап с 10 пунктами и аббревиатурами впечатляет только вас: команда видит кашу и отключается. Презентуйте по одному изменению за раз.
Я потратил недели на docker‑compose, который не взлетел. Простые тесты на тестовом контуре дали результат сразу.
Желание сделать «всё и сразу» привело к тому, что команда не успевала за изменениями. Лучше медленно, но устойчиво.
Гибкость необходима. Нельзя цепляться за изначальный план, если он неверный.
Избыток мотивации может быть минусом, а не плюсом.
P.S. «Когда всем этим заниматься?»
Осталось ответить на этот очень важный вопрос. Поток задач порой бывает безжалостным к любым сторонним активностям. Легко можно себе представить ситуацию, когда времени на внедрение каких‑либо инициатив либо очень мало, либо совсем нет. В этом случае необходим не только и столько грамотный тайм‑менеджмент, сколько коммуникация с командой.
Повторюсь, что потребность настройки процессов проговаривалась с лидером команды в самом начале. Поэтому на это выделили время: ставили задачи, двигались по статусам вместе с другими задачами, а важность данной активности признавалась всей командой. Я не был в ситуации, когда приходится перерабатывать, чтобы успеть то, что тебе нужно или хочется сделать. Но на самом деле сама тема шире: если в вашей команде нет запроса или нет понимания, зачем нужна та или иная инициатива, то процесс внедрения изменений будет выглядеть так:
Совет: сначала получите явную поддержку и ресурсы от тимлида и команды. Узнайте, что бесит коллег в текущих процессах, и решайте эти проблемы. Без этого вы просто выгорите.
На сегодня у меня всё. Моя история — пример того, что некоторые очевидные мысли и идеи не нужно игнорировать, они реально работают. Поэтому ни в коем случае нельзя забыть о том, что на первый взгляд кажется базой. Важно помнить, что коммуникация — краеугольный камень внедрения любых изменений, и те ошибки, которые я допустил в процессе их внедрения, сильно осложнили нашу работу. Это негативно влияет на порядок в процессах, на качество, на атмосферу. Надеюсь, что моя история вдохновит вас начать улучшать мир вокруг себя, делая это максимально вдумчиво и аккуратно.
