Чему научили меня первые месяцы работы в должности главного инженера? Прежде всего тому, что руководство — это не столько знание ответов на все вопросы, сколько умение задавать правильные вопросы — чаще всего самому себе. Например, такие:
Почему при тестировании постоянно упускаются из виду крайние случаи? Почему требования иногда кажутся загадками? Почему инженерные и продуктовые команды говорят как будто на разных языках?
В 1-й части своих признаний я поделился впечатлениями от происходящего в первые дни моего пребывания в новой должности. Я чувствовал себя так, словно попал в шторм — отказы приложений, всплески ANR и объявление одного аврала за другим. Этот хаос заставил меня переосмыслить процесс разработки, что привело к внедрению поэтапного тестирования (Milestone Testing) — структурированного способа выявления проблем на ранней стадии. Но совершенствование процесса тестирования было лишь частью большого пазла. Оставался еще один пробел, который мы полностью не устранили: отсутствие согласованности между инженерами и специалистами по поддержке продукта по тестовым случаям и требованиям.
Попадался ли вам этот классический мем о разработчиках и тестировщиках? Забавная и до боли знакомая ситуация. Что-то похожее я наблюдал в разработке с тех самых пор, как пришел в компанию. После того, как инженеры завершают свою работу, за дело берутся специалисты по поддержке продукта, чтобы устроить большую сессию тестирования Bug Bash. Конечно, в итоге такая работа помогает справиться с задачами. Но при этом обнаруживает разрывы в коммуникации, путаницу в сценариях тестирования и раздражение с обеих сторон. Кажется, что мы действуем изолированно, перекладывая ответственность друг на друга, вместо того чтобы работать как единая команда.
Изначально я стремился не просто к повышению качества тестовых примеров. Я добивался налаженного сотрудничества и ясности в коммуникации. Мне хотелось, чтобы инженеры и специалисты по поддержке продукта перестали говорить на разных языках и писали одну и ту же историю, по одному четкому и согласованному тестовому примеру за раз. О том, как искра этой идеи разгорелась в пламя продуктивного процесса, и пойдет речь во 2-й части моих признаний.
Катализатор: почему нам потребовался BDD-подход
Если бы в прошлом году вы поинтересовались у трех наших проектных команд, как они документируют требования, то получили бы три разных ответа. В одних проектах были хорошо структурированные пользовательские истории, в других — требования высокого уровня без учета крайних случаев. В таких случаях тестовые примеры менялись в ходе тестирования, что приводило к периодическим пробелам в понимании со стороны инженерных команд.
На каждом уровне, от сбора требований до разработки, у нас был свой канал коммуникации. Из-за этого не раз возникала ситуация, когда сотрудники, обсуждая одно и то же, не достигали взаимопонимания, поскольку каждый исходил из собственных технических представлений. Такая несогласованность затрудняла совместную работу. Инженеры создавали функции без стандартизированного способа определения ожидаемого поведения, а специалистам по поддержке продукта часто приходилось интерпретировать требования по ходу дела.
Результат?
- Непонимание, приводящее к пробелам в тестовом покрытии.
- Возложение всей ответственности за результаты тестирования на команду контроля качества.
- Неоднозначность требований, приводящая к доработкам и задержкам.
- Различные форматы тестовых заданий, создающие разобщенность между командами.
Нам нужен был общий язык, средство, объединяющее всех участников процесса в понимании того, что создается и как будет тестироваться с учетом мельчайших требований, невыполнение которых чревато серьезными проблемами после проверки качества. Таким средством объединения требований, тестовых случаев и команд стала для нас методология BDD (Behavior-Driven Development — поведенчески-ориентированная разработка). В Википедии есть четкое определение того, что такое BDD в двух словах.
Посев семян: как возникла идея внедрить BDD
Не буду приписывать себе заслугу в изобретении BDD — это далеко не так. Если честно, я даже не был инициатором внедрения BDD в нашей компании. Им был Шива (lsivaranjan) — старший Android-инженер из моей команды. Когда я представлял процесс поэтапного тестирования, он предложил: «Почему бы нам не начать писать тестовые случаи по методологии BDD? Это позволит унифицировать наши требования и тестовые случаи и даже запустить их в Android-проекте».
Это был момент озарения. Простая идея, способная преодолеть разрыв между инженерами и специалистами по поддержке продукта и заложить основу столь необходимой культуры общего понимания требований.
Когда Шива впервые заговорил о BDD, я, признаться, засомневался. Специалисты по поддержке продукта в основном отвечали за написание тестовых примеров. А инженеры писали только модульные тесты. Как убедить их всех перейти на новый формат? Это казалось сложной задачей, поскольку нам, людям, свойственно неохотно покидать зону комфорта.
В то время мы модернизировали функцию онбординга нашего приложения. Это был крупный проект и идеальная экспериментальная площадка. То, что начиналось как робкая инициатива, быстро перерастало в нечто более серьезное и масштабное, поскольку все больше членов команды начинали осознавать ценность такого подхода.
К моему удивлению, один из наших ключевых специалистов по поддержке продуктов (назовем ее К) сразу же проявила энтузиазм. Она увидела потенциал BDD в создании более понятных и структурированных тестовых примеров. Не раздумывая, она объединилась с Шивой и Android-разработчиком Энди Вангом (Andy Wang), изучила новый формат и начала писать в стиле BDD тестовые примеры для проекта онбординга.
Так были посеяны первые семена BDD.
BDD: что это такое и почему так важно
Прелесть тестовых примеров BDD в том, что их можно создавать на доступном английском языке, но очень подробно, чтобы было понятно всем и каждому. Они фокусируются на поведении программного обеспечения с точки зрения пользователя и обладают несколькими очевидными преимуществами:
- Понятны всем, а не только инженерам.
- Способствуют эффективной коммуникации и разъяснению требований.
- Легко трансформируются в UI-тесты для AN, iOS, Web.
BDD-тестирование следует подходу Given-When-Then — простому формату для написания тестовых примеров, включающему три блока:
- Given (дано/ввод) — предусловие для получения результата.
- When (когда/действие) — действие, которое необходимо выполнить для получения результата.
- Then (тогда/вывод) — ожидаемый результат сценария/требования.
BDD: глубокое погружение
Иногда при BDD-тестировании не получается завершить одной строкой блоки Given, When и Then. Тогда вводится оператор AND. Given, When и Then могут содержать любое количество AND для связи/операции, необходимой для выполнения данного требования. Рассмотрим продвинутые форматы BDD с использованием синтаксиса Gherkin, который обычно применяется для определения тестовых примеров BDD.
Feature: User Login
Background: Given the app is installed and launched
Scenario: Successful login with valid credentials
Given the user is on the login screen
When the user enters a valid email “user@example.com”
And the user enters a valid password “Password123”
And taps on the “Login” button
Then the user should be navigated to the home screen
And a welcome message should be displayed
Scenario: Login with incorrect password
Given the user is on the login screen
When the user enters a valid email “user@example.com”
And the user enters an incorrect password “WrongPass”
And taps on the “Login” button
Then an error message “Invalid credentials” should be displayed
Совместное развитие: влияние BDD
Наш пилотный эксперимент с BDD, реализуемый в рамках проекта онбординга, стал не просто подтверждением концепции — он показал, чего может достичь структурированное, ориентированное на поведение тестирование. Воодушевленные первым успехом, мы решили пойти дальше: начали писать тестовые примеры в формате Gherkin непосредственно в Android-проекте, чтобы интегрировать их в набор средств автоматизации. Но реальность быстро охладила наш энтузиазм — настройка унаследованного кода не позволяла запускать инструментальные тесты в репозитории приложения. Как бы нам ни хотелось двигаться вперед, мы должны были признать свои технические ограничения. UI-автоматизацию на основе BDD пришлось на время отложить.
Это не конец пути — просто пауза. Мы не отказались от идеи интегрировать тестовые примеры BDD в UI-автоматизацию. Мы намерены осуществить ее в 2025 году.
Тем временем влияние BDD уже распространялось. Этот структурированный формат позволил нам более эффективно создавать сценарии, а К, взявшись за написание тестовых примеров, проделала феноменальную работу по обеспечению их ясности и покрытия. Убедившись в ценности этого подхода на собственном опыте, мы распространили его не только на другие проекты. Лидер команды поддержки продукта, А, быстро перешел на этот формат, доказав, что BDD — не просто оптимизированный процесс разработки, это изменение мышления.
То, что начиналось как эксперимент, теперь превратилось в распространяющийся передовой опыт, который будет определять наши подходы к качеству и сотрудничеству в ближайшие годы.
Признание: урок, которого я не ожидал
Когда мы внедрили поэтапное тестирование, эффект был почти мгновенным. Процесс стал напоминать хорошо отлаженный механизм, быстро осваивался командой и через несколько месяцев вошел в ее привычную практику. Поэтому, естественно, когда мы начали экспериментировать с BDD, я ожидал аналогичной траектории успеха — плавного перехода на новую методологию, явных побед и ощутимых изменений в подходе к тестированию.
Но у реальности были другие планы.
Да, мы добились прогресса. Мы написали структурированные тестовые примеры, укрепили сотрудничество и увидели, что специалисты по поддержке продукта внедряют BDD быстрее, чем я мог себе представить. K и A без колебаний приняли этот формат, доказав, что эффективный процесс, если его корректно внедрять, не обязательно встречает сопротивление. И все же, когда дело дошло до интеграции автоматизации в Android-проект, мы уперлись в стену. Настройки унаследованного кода сдерживали нас, заставив временно отказаться от автоматизации BDD.
Поначалу это казалось неудачей. Но, поразмыслив, я кое-что понял: перемены должны происходить поэтапно, а не мгновенно.
Пусть BDD-подход не изменил нашего процесса автоматизации в одночасье. Зато он изменил наше представление о качестве, что не менее важно. Вместо того, чтобы рассматривать тестирование как отдельный шаг, мы сформировали общее мышление в командах. Инженеры и специалисты по поддержке продукта перестали работать изолированно. Обсуждения требований стали более понятными. Сценарии тестирования — более структурированными. Мы заложили основу, хотя финальная часть — автоматизация — все еще ожидает своего завершения.
Впереди я вижу еще большие возможности. Что, если BDD использовать не только для тестовых примеров, но и для определения самих требований? Представьте себе будущее, в котором команда разработчиков публикует требования непосредственно в формате BDD, создавая единый источник достоверности с самого начала. Затем инженеры могли бы применять те же самые тестовые примеры и внедрять интеграционные и инструментальные тесты, используя такие платформы, как Cucumber. Разрыв между тем, что уже создано, что протестировано, и тем, что ожидается, значительно сократился бы. Мы еще не достигли этого, но уже посеяли семена будущих достижений. Теперь все дело в том, чтобы поддерживать процесс и наблюдать за его развитием.
Таково мое долгосрочное видение.
Читайте также:
- Шаблоны функционального программирования. Рецепты
- Реализация ролевого контроля доступа в Elasticsearch
- Почему борьба GitHub с тостовыми уведомлениями — плохая новость для специалистов по доступности
Читайте нас в Telegram, VK и Дзен
Перевод статьи Arighna Maity: Confessions of a First-Time Engineering Manager — Part 2
