В 2ГИС продакт-менеджеры отвечают за полный цикл фичи: важно не просто запустить её, но и рассказать о ней. Подробно, честно, с деталями: как появилась идея, какие были сложности, что в итоге получилось и какие первые результаты. Это не просто «мы добавили кнопку, и теперь всё классно» — это история про поиск решения, процесс, ошибки и инсайты. 

Этим опытом мы делимся в «Доставили» — нашем блоге о продукте, который со временем стал не только инструментом коммуникации, но и частью продуктовой культуры. В этой статье о том, почему мы вкладываемся временем и менеджерскими ресурсами в написание статей и не боимся откровенно делиться результатами.

Меня зовут Вера Романцова, я работаю в 2ГИС в команде компьютерного зрения. Мы создаём ML-модели и сервисы, которые автоматизируют работу с картами и данными. 

Но перед тем, как обучить модель и выкатить сервис, есть ещё много работы по сбору датасетов и разработке моделей. И обычно все эти задачи выполняли ML-инженеры. В один из моментов моя будущая команда пришла к выводу, что для эффективных процессов разметки, сбора и валидации данных нужна отдельная роль — менеджер данных. Этим первопроходцем в нашей компании стала я. 

В этой статье я расскажу:

🌚 Кто такой менеджер данных и чем он занимается.

🦾 Как эта роль помогла нашей команде ML-инженеров.

🔜 Когда такой специалист может понадобиться вам.

🔎 Как найти подходящего кандидата на эту позицию.

Локаторы — важная часть автоматизации тестирования. Они позволяют находить элементы на странице для взаимодействия с ними в тестах. Но что делать, если стандартные методы, такие как CSS-селекторы и XPath, становятся громоздкими, ломаются при изменении структуры страницы или не поддерживают уникальные особенности элементов? Решение — кастомные локаторы.

Меня зовут Лёша, и я занимаюсь тестированием в 2ГИС. Моя команда работает над сервисом по бронированию отелей Отелло. В этой статье я расскажу, как использовать кастомные локаторы, чтобы тесты оставались стабильными и поддерживаемыми даже при изменениях в приложении. В примерах я использую Python, но не стоит пугаться, если вы не знакомы с этим языком, каких-то сложных операций мы сегодня выполнять не будем.

Если вы когда-нибудь сталкивались с автотестами, которые ломаются на ровном месте, не дают предсказуемых результатов или отнимают больше времени, чем ручное тестирование, — эта история для вас.

Наша команда столкнулась с похожей проблемой: тесты, которые должны были ускорять разработку, превращались в источник боли и хаоса. Мы больше не доверяли их результатам: красные прогоны стали «фоновым шумом», а зелёные — чем-то из области фантастики.

В этой статье я расскажу, как мы разбирались с нестабильностью, рассмотрев три разных подхода (быструю починку тестов, создание идеальной базы данных и генерацию тестовых данных), и выбрали тот, который позволил нам ускорить CI/CD и вернуть контроль над автотестами.

Привет! Меня зовут Катя, я тестировщик.

Когда я только пришла работать в 2ГИС, я занималась тестированием фронтенда карты. Всё было чётко и понятно, ведь был один проект. Но когда я переключилась на тестирование бэкенда, ситуация радикально изменилась. В работу команды, связанной с пользовательским контентом, входило 30+ проектов разного размера и приоритета, с разным уровнем покрытия тестами. Из общего только, что все проекты разработаны на Go, а автотесты — на Python.

Ситуация была настоящий «омагад🫣». Даже опытным сотрудникам было сложно ориентироваться в каждом проекте, не говоря о новом члене команды. Это приводило к неприятным последствиям. Например, перед внедрением фич мы часто не могли прогнозировать время тестирования и оценивать необходимые усилия. Бизнесу давались одни сроки, но на практике они сдвигались из-за неожиданно обнаруженных проблем. В результате доставка фич на бой затягивалась или срывались сроки, нарастал техдолг, и вся эта вакханалия повторялась по кругу.

Расскажу, что мы сделали, чтобы навести порядок. Это история о том, как системный подход упростил жизнь нашей команде, ускорил тестирование и повысил прозрачность процессов. 

Привет! Я Иван Косолапов, тимлид команды ETA/RTA. Мы часть сервиса Data Science и занимаемся анализом данных и машинным обучением для задач навигации в 2ГИС.

Наша команда появилась несколько лет назад, чтобы сделать точным прогноз времени в пути на автомобиле. Это важно не только для пользователей нашего навигатора, но и для бизнеса: например, для такси и служб доставки. Несколько специалистов по машинному обучению объединились с инженерами из команды навигации и создали решение, которое отвечает строгим требованиям по качеству, снизив ошибку на 20 процентов. Недавно мы также помогли сделать так, чтобы автобусы на карте отображались точно, и начали предсказывать время их прибытия на остановки. И это лишь часть задач, над которыми мы работаем.

Сейчас тема AI, машинного обучения у всех на слуху, и со стороны может показаться, что те, кто этим занимается — маги, которые берут нейросети, прикладывают их к правильным местам, и все проблемы решаются.

На самом деле применение сложных алгоритмов требует большой подготовительной работы по наведение порядка  в процессе разработки, что занимает 90 процентов всего времени, если не больше. Более того, как только процесс налажен, может оказаться так, что никакой дополнительной магии машинного обучения уже и не нужно добавлять. 

Под наведением порядка в процессе разработки я подразумеваю решение четырёх задач: выбор правильной метрики, подготовка данных, построение воспроизводимой системы экспериментов, перенос алгоритмов туда, где их проще всего развивать.

Расскажу, как решая эти задачи, мы добились более точного отображения автобусов на карте в 2ГИС, упростив существующую на тот момент сложную систему.

Мы делаем карты 2ГИС реалистичными, чтобы приложение максимально детально отражало город вокруг: чтобы у зданий были не гладкие стены, а настоящий фасад, в парках росли деревья и стояли лавочки, а скульптуры выглядели точно так же, как и в реальности. Такая реалистичность помогает в навигации: гораздо проще сравнивать то, что ты видишь в реальности, с моделью этого здания, а не с гладкой коробкой. Поддержка освещения объектов, которую мы добавили на 2gis.ru — ещё один шаг к реалистичности.

Расскажу, чего мы добились на сегодня, на какие компромиссы пришлось пойти и чуть-чуть о том, что под капотом движка освещения и теней.

Бывает, что в командах тестирования грезят об автоматизации процессов, но почему-то боятся внедрять даже такие простые вещи как хуки: «Они очень усложняют процесс, и писать их тысячу часов». С этим я категорически не согласен, ведь реализовать хуки очень просто.

Меня зовут Денис Федоров, я тестировщик в команде 2ГИС ПРО, сервисе геоаналитики для бизнеса. Рассказываю, что такое гит-хуки, чем они могут быть полезны и как их можно реализовать у себя. 

Привет, меня зовут Андрей Рягузов, в 2ГИС я разрабатываю внутренние продукты для актуализации справочных данных на .NET.

Несколько лет назад для работы с настройками мы в команде пользовались самописным методом. Пока приложения были простыми, нас всё устраивало, однако при масштабировании начали вылезать неприятности. Так мы начали искать альтернативу.

Расскажу, почему изначально решились на нестандартный метод, с какими трудностями столкнулись и что решили улучшить, какие варианты рассматривали и какие преимущества получили от «коробочных» инструментов.

Привет! Я Катя Глушанина, тестировщик в 2ГИС. В далёком 2019 год в нашей компании было не так много сотрудников, а тестировщиков в веб-отделе — ещё меньше. Мы все работали в офисе, много общались и решали вопросы на месте. Ламповость атмосферы была включена по умолчанию. Компания начала расти, и с этим пришли новые вызовы. Стало больше команд, тестировщиков, появились удалённые сотрудники.

Это привело к трём «побочным эффектам»:

Сложности коммуникации. У нас 11 часовых поясов, и это иногда тормозит доставку фич. Например, у меня возник вопрос, а тот, кто может с ним помочь ещё не начал работать или уже закончил.

Нет обмена знаний. В распределённых командах могут чаще придумываться велосипеды.

Чувство изоляции. Одному дома может быть грустно: даже мем не с кем обсудить.

И мы поняли, что нужно что-то менять.

Привет, меня зовут Андякина Ольга, я QA‑инженер в компании 2ГИС, тестирую сервис по бронированию отелей Отелло. В этой статье расскажу про плюсы и минусы разных подходов к генерации данных и поделюсь хорошими практиками подготовки данных на примере пакета библиотек d42 и нашего проекта. В первую очередь, наш опыт будет полезен тем, кто занимается автоматизацией тестирования фронтенда.

Автоматизированное тестирование сложно представить без использования тестовых данных. Например, при интеграционном тестировании нужно записывать данные в базу и валидировать полученные данные, в нагрузочном — выполнять запрос с уникальными параметрами. Также данные могут потребоваться при фронтенд‑ и e2e‑тестировании, чтобы наполнить блок текстом или ввести ФИО в форму. Есть различные подходы к получению тестовых данных для автотестов, и генерация данных — один из самых удобных и гибких подходов.

Меня зовут Женя Тютюев, я iOS-разработчик в компании 2ГИС. Хочу поделиться, как адаптировал наше приложение под VoiceOver: 

— Делюсь историей про сдвиг парадигмы и как перешёл из стадии «делать, потому что Эпл советует» в совершенно новую — «делать для людей». 

— Как разработал новый вид snapshot-тестирования, чтобы ничего не ломалось при добавлении новых неадаптированных элементов. 

— И описал несколько нюансов, которые важно учесть в работе: escape, динамический расчёт доступности, укрупнение элементов.

Надеюсь, мой опыт вдохновит принести неоценимую пользу и сделать собственные приложения доступными для большего числа пользователей.

Привет, меня зовут Роман Брылунов, я QA Automation в команде сервиса транспорта 2ГИС. Мы автоматизируем сервисы транспортных сценариев, таких как построение маршрутов для разных видов транспорта, построение пешеходных маршрутов, решение задачи коммивояжера. Основная часть наших тестов — функциональные тесты логики приложения.

С сервисами общаемся по HTTP, но есть и несколько внутренних сервисов со взаимодействием по gRPC. Все ответы, полученные от сервисов, мы предварительно валидируем перед обработкой в тесте. Для валидации используем библиотеку Pydantic. Это позволяет нам описывать формат взаимодействия с помощью моделей и обрабатывать ответы в виде Python-объектов вместо словаря после стандартного парсинга JSON. Тесты встроены в CI, успешное прохождение тестов является блокирующим условием для влития кода. Таким образом, чтобы внести изменения в API, необходимо актуализировать модели в тестах. В противном случае ответ от сервиса не пройдёт валидацию при прогоне тестов. 

Мы стараемся всесторонне подходить к контролю качества продукта, в том числе хотим, чтобы у продукта была красивая и актуальная документация. У наших сервисов была документация, но она обновлялась вручную. А у нас есть модели запросов и ответов, которые точно соответствуют текущему формату API. Мы подумали, что будет здорово использовать эти модели для формирования документации. Попробовали и успешно внедрили. Расскажу о том, как можно это сделать.

Привет, я Фируз Шоев, тестировщик в Отелло — сервисе бронирования отелей от 2ГИС. Мы в стадии активного роста и постоянно усиливаем команду. Несколько месяцев назад я подключился к найму тестировщиков и с тех пор провожу собеседования практически каждую неделю. За это время я стал замечать, что многие кандидаты не уделяют должного внимания тестированию фронтенда.

Почти в каждом втором собеседовании я слышу следующее:

— Во фронтенде можно максимум вёрстку протестировать отдельно от бэкенда.

— Фронтенд тестируем через end-to-end тесты, но они сложные и нестабильные.

— А как вообще тестировать фронтенд изолированно?

— Про моки слышали, но не использовали их и не думаем, что на них стоит полагаться.

В этой статье я хочу рассказать о важности тестирования фронтенда и пользе моков. Мокирование вносит весомый вклад в обеспечение качества приложений 2ГИС, поэтому надеюсь, что этот подход принесёт пользу и другим.

Меня зовут Игорь Буняков, я был фичекрайним за реалистичные дороги в 2ГИС. Недавно они вышли в навигаторе, а позже будут доступны в режиме карт на мобильных устройствах и на 2gis.ru. Реалистичные дороги оказались невероятно большими, невероятно сложными, невероятно красивыми. При этом реалистичность — это не столько про красивость, сколько про функциональность. Мы даём пользователям нашего навигатора новый опыт.

Про техническую реализацию у нас отдельный пост, а этот — менеджерская история для разработчиков. Тут я рассуждаю, кто же на самом деле такой фичекрайний и что он делает, какие стадии проходит во время проекта и почему же всё-таки так классно инженеру прочувствовать роль менеджера.

Мы добавили реалистичные дороги в навигатор 2ГИС. Теперь дорожное покрытие, разметка, объёмные развязки, съезды, островки безопасности и опоры на многоуровневых дорогах выглядят как в жизни. Под капотом — решение задачи по превращению «плоской» геометрии в объекты с реалистичными шириной и высотой. Чтобы не замедлять обновление дорожной сети, нам требовалась минимальная задержка между изменением дороги и обновлением её «объемного» представления.

Расскажу, как в одном сервисе формируем очереди в RabbitMQ, а в других — читаем и при помощи библиотеки NetTopologySuite превращаем плоские объекты в реалистичные. Выбранный нами подход с потоковой обработкой изменений универсален, поэтому статья может быть интересна всем, кто работает с геометрией и системами реального времени в целом.

Привет! Меня зовут Алина Бузинова, я менеджер продукта Отелло, сервиса бронирования отелей от 2ГИС.

Для молодого продукта на конкурентном рынке часто важна скорость доставки полезных решений. Планировать шестимесячную разработку и не получать ожидаемого профита — непозволительная роскошь. Так, после генерации идей, направленных на поиск решений для роста конверсий продукта, мы решили, что готовы выделить на проверку каждой из гипотез не более трёх дней, а на дорогие интеграционные — максимум две недели.

В статье расскажу о том, как нам удалось за две недели реализовать пользовательский сценарий, разработка которого оценивалась в полгода. И каких принципов можете придерживаться вы, чтобы применить такой подход в своём продукте.

На разработку и успешность сервиса влияет то, как его будут запускать — внутри существующего продукта или отдельным приложением. В этом посте Михаил Мельников, продакт-лид Отелло, рассказывает, как мы в 2ГИС решаем, где запускать: внутри или снаружи.

Всем привет! На связи Саша Сырков из 2ГИС, и это рассказ, как чуть больше недели мы разрабатывали приложение на Vision OS, разбирались в особенностях Reality Composer Pro, ловили всевозможные текстурные баги, а в итоге всё же получили заветный апрув от Apple за 17 часов до официального открытия продаж VR-гарнитуры.

Под катом хронология событий от идеи до рабочего продукта и технические подробности создания нашего первого VisionOS-приложения — краткого справочника с 3D-моделями достопримечательностей.

P.S. для самых пытливых в конце вопрос: кто первый отгадает ответ, тому подарим нашего гуся.

Недавно в карте 2ГИС появились небо и туман, которые можно увидеть, увеличив масштаб и наклон. 

В статье расскажу, для чего нам понадобились эти фичи, с какими сложностями столкнулись в процессе исследований и как в итоге реализовали нужную функциональность.