QAжется, работает!

Как я перестал читать логи упавших тестов и начал их видеть Продолжаем истории про тестирование Умного Трекинга. Для освежения контекста можно почитать предыдущие посты (раз, два, три) В предыдущих постах не упомянул ещё один недостаток статичных тестов, который решил с помощью ИИшки. Точнее, упоминал его, но хочется остановиться на нём подробнее. Нам тяжело было анализировать результаты тестирования. Вот представьте, у вас тест public async Task RunStandardGroupingScenario(RoutingTestData testData) { ... var order1 = new TestOrderBuilder(1) .PlacedAt(currentDate.AddMinutes(-40)) .WithMeterOffsets(724, 1000) .Please(); ... await Runner .WithContext<AutoAssignmentContext>() .RunScenarioAsync( ... _ => _.OrderPlacementSteps.GivenOrdersAreOnTheShelf(order1), ... _ => _.when_GroupOrdersForDelivery_iterate(), _ => _.then_ORDERS_are_grouped(order1.Number, order2.Number, order3.Number) ); } Тут ключевое, на что нужно смотреть, — WithMeterOffsets. Это смещение заказа от координат пиццерии в метрах. Сделали метод для упрощения написания тестов, чтобы не нужно было искать координаты каждого заказа. Просто указываешь смещение от пиццерии по направлению север-юг и смещение по направлению запад-восток, а тестовый метод сам высчитывает координаты. И вот перед очередным релизом этот тест падает, и ты видишь буквально: Orders are not in the same group Found groups: [{"TravelMode":0,"Orders":[3,2]}], [{"TravelMode":0,"Orders":[1]}] И что с этим делать? Напомню, что мы тестируем результаты работы алгоритма группировки. Как понять расположение заказов относительно друг друга и пиццерии? Можно, конечно, вспомнить, что первый аргумент в методе WithMeterOffsets — это отклонение по направлению север-юг, но, возможно, и отклонение по направлению запад-восток. Затем мысленно представить себе карту и наложить на неё заказы. Но у меня не получалось. Что я сделал? Правильно, навайбкодил html, который получал последний запрос к солверу, парсил его и рисовал карту. На карте отмечал маркеры заказов и группы заказов, ну и вообще отображал весь контекст того, какие данные были засетаплены до этого. Затем сделал генерацию такой карты после каждого теста и приложил её в ТестОпс. Теперь можно легко смотреть на итоги теста, и разбирать упавшие тесты стало сильно легче. Раньше, без ИИшки, я бы даже не взялся за это, а сейчас в перерывах между тестированием создал вспомогательный инструмент, который плотно засел в тестах. У меня есть ещё один похожий инструмент для других тестов, но о нём расскажу дальше, когда буду рассказывать о динамических тестах в Умном Трекинге.

Как автотестируем систему батчинга заказов ч.2 Времени на нормальную отладку тестов у нас не было, мы сразу стали использовать эти тесты для проверки группировок и соответствия системы требованиям. Потому что нам надо было очень быстро тестить гипотезы и мы не могли долго разрабатывать и тестировать. Перед релизом новой версии группировщика запускали тесты, брали упавшие и начинали разбирать. Из инструментов для разбора - только логи системы, мы даже визуально не могли представить где находятся эти заказы. Вот есть координаты пиццерии 30, 31. И у нас есть метод который принимает отклонения в метрах от этих координат, дальше метод сам вычисляет координаты по методу линейного приближения сферических координат. Заказ создается таким образом var order1 = new TestOrderBuilder(1) .PlacedAt(currentDate.AddMinutes(-7)) .WithMeterOffsets(-2500, -3000) .Please(); Если создано 2-3 заказа, то в целом это можно как-то представить в уме, но у нас были кейсы с 12-15 заказами (в след посте расскажу как вайбкодинг помог решить эту проблему). Также всплыла проблем с тем, что до написания теста мы не знали ожидаемый результат каждого теста. Тут нам на помощь пришли требования - мы зафиксировали цели оптимизации, по приоритету: 1. Развезти все заказы 2. Отдать наименьшее количество сертификатов 3. Дать наилучший сервис (минимальное время от получения заказа до выдачи клиенту С2E) 4. Обеспечить справедливость распределения заказов на курьеров. Если с 1 и 2 требованием все просто, то с расчетом C2E были проблемы. Представьте у вас 7 заказов и 3 курьера, вы можете возить заказы по 1, по 2 и по 3. Сколько комбинаций получится? Клод посчитал 30 240 комбинаций. Чтобы понять соответствует полученная группа требованию или нет сидели и считали С2E для разных вариаций групп, которые на наш человеческий взгляд выглядели логично. Пришлось даже написать вспомогательную утилиту, которая принимала лог с заказами и считала С2E разных групп. По итогу задача оказалась сложнее чем ожидали - не были уверены какой результат должен быть в тесте, не видели заказы и как они сгруппированы, не могли быстро посчитать c2e. Но все равно даже с такими проблемами, мы поймали несколько проблем и исправляли логику группировок чтобы она стала соответствовать требованиям.

Как автотестируем систему батчинга заказов ч.1 Это продолжение предыдущего поста. У нас в проекте написаны интеграционные тесты, которые тестируют нашу систему в интеграции - мы поднимаем БД в Docker, запускаем тестовый хост SUT (System Under Test) и запускается Kafka с помощью TestContainers. Но мы не только публикуем события в Kafka но и еще потребялем их. Поднимается отдельный хост с консьюмерами. И тесты проверяют опубликованные события. Ну и 25 фейков внешних зависимостей. В общем-то и все. В тестах мы сетапим данные, выполняем действий, проверяем результаты. Часть тестов написана на голом nUnit, а часть с помощью LightBDD (из названия следует, что это обертка для описания шагов в тесте в BDD стиле). Эти тесты проверяют функционал самой кассы доставки: работа с чеками, курьерами, движение заказов, применение группировок. В общем мы подумали, что наилучшим решением будет писать такие тесты рядом с этими интеграционными тестами, на уже готовой инфраструктуре. НО если все существующие тесты тестировали всю систему в изоляции (кроме перечисленных зависимостей), то у нас появляется внешняя зависимость в виде самого группировщика, который хостится в DataBricks. На самом деле на отдельном эндпоинте хостится Решала (Solver) - который говорит как объединить заказы на основе переданных данных, а логика создания и применения групп на основе его ответов лежит в нашей системе, но для простоты буду называть его группировщик. Мы явно решили ходить из нашей системы во внешнюю потому что целью наших тестов было проверить как группировщик объединит заказы в поездку при определенных условиях. Вот мы задаем заказы, время их принятия, курьеров, вызываем группировщик - получаем группы и проверяем что группы применились. Напомню количество переменных которые влияют на группировку: 1. Заказы: a. Статус; b. Время от принятия c. Прогнозное время до конца готовки; 2. Курьеры: a. Статус; b. Прогнозное время возращения; 3. Текущая нагрузка на пиццерию; 4. Прогноз спроса в пиццерии; 5. Маршруты: a. Координаты заказов; b. Чистое время в пути от Яндекса; c. Время на сборку заказа (зависит от текущей нагрузки и кол-ва коробок в заказе); d. Время дойти от пиццерии до машины (у каждой пиццерии разное); e. Время дойти от каждого заказа до клиента (у каждого заказа разное); f. Время дойти от машины до пиццерии (у каждой пиццерии разное). Сначала я написал тесты основываясь на требованиях, а требования для такой системы у нас - двухстраничный документ. Я считаю должно быть минимум 3. 😏 Потом в процессе написания тестов решили, что стоит и дописывать кейсы с реальной пиццерии. Например заметили или пожаловались на кринж группу, мы воспроизводим такой кейс, чтобы убедиться, что проблема действительно ушла. Таким образом написали 60+ тестов. И тут начинается самое интересное. Я в предыдущем посте писал, что у нас было 3 группировщика, которые группировали по разному, поэтому мы подошли к этапу, когда часть тестов не проходила на одном группировщике, часть тестов не проходила на другом группировщике. Как-то мы дошли до того, что у нас был только один группировщик, но сейчас их снова два и у них есть разные версии которые могут работать одновременно на разных пиццериях, плюс у обоих группировщиков есть разная конфигруация работы автоназначения.

Тестирование сложных систем Я уже рассказывал, что плотно сижу на проекте «Умный трекинг» — это ключевой проект b2b-направления Додо Пиццы. Мы все помним, что он не умный и не трекинг (мы начинаем задумываться о ребрендинге), но это уже мало кого смущает и для простоты буду называть его УТ. Контекст, что такое УТ, вот тут. Решил рассказать, как мы тестируем его. Поэтому ждите в ближайшее время посты про тестирование УТ. Итак, погнали. Первым этапом тестирования являются функциональные автотесты, которые запускаются на каждый коммит. Но это тесты без внешних зависимостей, все зависимости зафейканы (ML-калькуляторы, прогнозы приготовления, гео и т.д.). В этих тестах проверен базовый функционал системы управления доставкой, внутри которой мы создаём свою систему батчинга. В базовый функционал входит получение оффера на заказ курьером, формирование групп, отказ от оффера, принятие оффера и т.д. Как работает группировка Автотестов, которые проверяют бизнес-требования группировки, не было. И вот тут начиналось ручное тестирование. Базово УТ работал так - мы каждые 30 секунд запускаем итерацию УТ, плюс эти итерации запускаются при различных триггерах, например когда заказ упаковали или когда появился новый курьер. На то, как будет сформирована группа влияет что-то в районе 10 показателей, которые меняются прям на ходу. Прошло 1, 2, 5 минут, группы уже будут другими. Появился или исчез курьер - группы будут другими. Появился новый заказ - думаю вы поняли логику. Все эти показатели основываются на штрафах и бонусах. Задача группировщика найти такой вариант группировки, где суммарный штраф минимален (это очень упрощенное объяснение). Внимание вопрос, как я, ручной тестировщик, создавший на тестовом стенде 5-10 заказов, могу посчитать штрафы всех заказов по всем показателям (учитывая что есть штрафы которые меняются каждую минуту)? Сам пересчет и запрос к группировщику запускается каждые 30 секунд. Это невозможно. Для понимания масштаба проблемы предлагаю вам прочитать недавнюю статью на хабре про алгоритмы в лифтах (просили кого-то на собесе протестировать лифт?). Вот у нас примерно тоже самое, только подвижных частей - больше. Как мы тестировали требования Мы проверяли основные требования. Что соседние заказы должны объединяться, заказы в разные стороны не должны группироваться, принятые заказы не должны группироваться с готовыми и т.д. Но даже тут были проблемы — заказы, по которым должны быть выданы сертификаты на пиццу. Чтобы заказ был близок к сертификату (чем ближе тем больше штраф), тебе либо нужно идти в БД сервиса и руками менять время принятия заказа, чтобы система посчитала его просроченным или близким к просрочке (но тогда данные могут разъехаться, если забыть поменять значение в какой-то другой таблице или базе), или сидеть ждать почти час, пока заказ просрочится. Ну и конечно же в таком режиме мы не могли не пропускать баги. Например, был прикол — решили реализовать требование не группировать заказы, угол между которыми больше 120 градусов (в основании угла пиццерия). Создали заказы, посмотрели, что пары заказов с таким углом не группируются. Я специально выделил слово «пары», потому что на проде тройки заказов группировались и на 180 градусов. Между 1-м и 2-м заказом 70°, между 2-м и 3-м — 90°. А между 1-м и 3-м — 160°. Ну и ещё заодно проверяли, что техническая интеграция всех систем прошла успешно. Какие выводы я сделал А вывод такой, что ручное тестирование таких комбинаторных систем - то еще приключение. Сколько бы ты не тестировал, все равно не сможешь провести исчерпывающее тестирование. И из этого следует простая и очевидная мысль - надо навалить автотестов на это дело. В следующем посте расскажу как мы это дело автоматизировали и что из этого вышло.

Хотели бы вы найти багулю в самолёте? Я если честно не очень. Вот @DanilBabich нашел, порадуемся за него, что хотя бы не крит баг 😬 Если хотите заебать утомить соседа своими выходками, то вы сели в правильный самолёт 😏 Если вдруг вам интересно погрузиться немного в дизайн вещей, которые вас окружают, то можно почитать The Design of Everyday Things (в русском переводе Дизайн привычных вещей). Не так давно узнал об этой книге на уроках английского. Еще не читал, но отзывы на амазоне внушают оптимизм.

Погружайтесь в бизнес Почти всю прошлую неделю я провел в пиццериях своего города. К нам наконец докатился проект Умный Трекинг. Я сразу же пошел смотреть как им пользуются. Что такое Умный трекинг (УТ) Напомню, что УТ - это система батчинга заказов на доставку. Такие есть или должны быть у всех агрегаторов и служб доставки. А так как Додо пицца развивает свою доставку, нам тоже такая нужна. Сейчас курьеры сами набирают себе заказы, а вообще не должны. Представьте если бы водители в Яндекс Такси видели весь список заказов и выбирали бы кого они повезут и в каком порядке. Посмотрел бы я как вы уедете из какой-нибудь деревни. Что узнал Пока я наблюдал за работой системы и курьеров, я выяснил несколько схем обхода нашей системы. 1. Курьеры в моем городе привыкли возить по 2-3 заказа, поэтому они совершают некоторые манипуляции, чтобы система отдавала им группы по 2-3 заказа, даже если в моменте система считает что нужно съездить на один заказ. Они искусственно снижают количество доступных курьеров для системы и получают более плотные группы. 2. Курьеры используют лазейку, которую мы оставили, чтобы не везти заказы в строгом порядке. Помечают первый заказ который не по пути проблемным и им открывается возможность развозить остальные заказы. Теперь мы будем считать количество этих событий и знать, что в пиццериях с аномально большим количеством этих событий - фродят. Значит мы не можем полагаться на метрики этой пиццерии и делать выводы о качестве работы нашей системы. А еще я заметил, что курьеры ооооооочень долго собираются на заказ. Недавно еще внедрили новый функционал сбора на заказ из-за чего время могло вырасти. Так вот мы в своей системе закладываем 2 минуты на сборку, а среднее время которое тратят - 7 минут. Поэтому наша система более оптимистична настроена и может отправить курьера на 3 заказа с учетом сбора 2 минуты, а из-за того что курьер собирается 7 минут, можем на последний заказ не успеть. Если бы система знала что курьер будет собираться 7 минут, то мы бы отправили только 2 заказа. Теперь задача на анализ времени сборки заказа ушла в команду аналитики и по результатам будем принимать какие-то меры. Также услышал что думают о разрабатываемой системе курьеры. Пришел курьер на работу, хотел взять 2 или 3 заказа, но нагрузка на пиццерию - минимальная. Мы предлагаем ему отвезти 1 заказ, он выдает обратную связь: "Что за хуйню вы сделали?". В другой пиццерии сказали что наша система "шляпа". 😏 К чему я это все, как вы считаете, узнал бы я об этом сидя в офисе? Думаю ответ очевиден, не узнал бы. Поэтому, если вы в работе автоматизируете реальный бизнес и у вас есть возможность наблюдать за тем как пользуются вашим софтом (удаленно или на месте) или хотя бы если вы можете сами попользоваться этим софтом (но тут тоже может быть искажение, вы знаете как он работает его логику и она может казаться вам даже вполне хорошой, но ваши пользователи не знают и не должны знать, поэтому этот подход не так хорош), то вам прям категорически, прям катастрофически нужно это делать. Пойдет и то, если вы будете пользоваться своим продуктом. Под шумок напоминаю вам, что у меня по этому поводу есть старая статья на хабре, которая между тем не потеряла своей актуальности.

Чюваки запилили топовую визуализацию карты телеграмм каналов. Близкие по тематике каналы собираются в кластер. Нашел себя в кластере QA но чуть в сторонке. Воспринимаю это как то, что у меня канал с особенностями😏 Заходите позалипайте, мне понравилось.

Allure TestOps MCP А вы знали, что есть MCP сервер для работы с TestOps? Помните я ныл что в Allure для .NET не работает плагин для бронирования AllureID, разработчики обещали починить, чинили чинили, да не починили. По крайней мере когда я последний раз пытался - не работал. Чтобы вы понимали уровень боли: Наши разработчики в компании делали в GitHubActions отдельные дожбы, которые получают AllureID (на 1 скрине) 🤯 Использовали http-клиент в Rider, прихранивали в репозитории проекта .http файл, куда нужно было подставить api ключ от TestOps, который выполнит http-запрос, описанный в файле. Суть запроса - сходить в API TestOps, получит AllureID и вернуть его 🤯🤯 Но теперь это нахрен не упало, ни плагин, ни клиенты, ни джобы. Продуктовая стратегия разработчиков TestOps "подождем пока проблема как нибудь сама рассосется" сработала. Теперь за вас все будут делать роботы (если вы конечно пользуетесь агентами для написания кода). Спасибо хорошему человеку, которые сделал это 🙏 MCP дает возможность работать с тест кейсами, создавать тест кейс и возвращать его AllureID, работать с запусками, степами, кастомными полями, проектами и много чего еще. Мне очень удобно. Можно добавить правило в свой агент, чтобы при написании нового теста он сам ходил и добавлял AllureID, либо просить его сделать это. Я регулярно пользуюсь для проставления AllureID, поиска дубликатов и методов где AllureID отсутствует. Короче если вы работаете с агентами и TestOps - эта штука для вас обязательна к ознакомлению.

Традиционные итоги года канала. Можно сравнить с предыдущим годом Если коротко, то текущий год не такой успешный как предыдущий. Самый популярный пост про вакансию🤷‍♂️ В следующем году буду исправлять ситуацию. Предлагаю сделать упражнение - накидывайте в комменты свои итоги года, чтобы осознать какие вы молодцы❤️

Кто-то забыл протестить карусель с изображениями 😏 А что творится в горзонтальной ориентации, лучше вообще не видеть 🩸 (закину видос в комменты)

Решил поныть рассказать о том, над чем сейчас работаю и с какими сложностями столкнулся. Моя команда взяла в разработку проект по батчингу (группировке) заказов на доставку. Есть курьеры и есть заказы, которые нужно развезти как можно быстрее, но при этом не очень долго (в рамках 60 минут чтобы не отдать сертификат) при доступном наборе курьеров. А от меня как тестировщика этого функционала ждут, что я протестирую качество группировки до того как мы выйдем на реальную пиццерию. Казалось бы задача не сложная, подавай на вход курьеров и заказы с адресами, получай на выходе батчи и назначай на курьеров. Но есть нюансы бизнес-ограничения, нельзя возить заказ в разные стороны (хотя я считаю это плохим ограничением), у заказов есть разные статусы, от которых тоже зависит возможность объединения. Например готовый заказ не долежн ждать не готовый. Но не всегда, иногда должен подождать. А кроме этого мы можем придержать заказ и не показывать его если нет свободных курьеров, которые его повезут. Есть прогнозное время приготовления заказов (со своими приколами), которое тоже влияет на то, можно ли применить получившуюся группу. У курьеров тоже не все так гладко, есть курьеры которые находятся в пиццерии, а есть курьеры которые едут с заказами и вернутся в пиццерию через Х минут. А этот Х минут - это прогноз, который не всегда точен. А еще есть максимальная вместимость курьера, когда он не может взять больше 3 заказов (хотя возможно справедливее тут считать в коробках, но не суть). А еще ест разные типы курьеров, пеший, вело, авто. А еще есть настройки пиццерии, которые у каждой уникальные, например сервисное вермя, которое курьер тратит на каждую поездку - дойти от пиццерии до машины и обратно, а также сервисное время на каждый заказ - дойти от машины до клиента и обратно. Все осложняется тем, что прямо сейчас разработаны и проверяются 3 разных инструмента для группировки заказов. Все они принимают отличающийся набор данных и в итоге по разному группируют 🤯 Изменение любого из этих параметров-ограничений на минимальное значение может кардинально изменить группировку. И мне нужно протестировать это и написать интеграционные автотесты, которые проверяют качество группировки. Тесты то написать не проблема (на самом деле некоторый набор уже написан), но нужно написать тесты которые отражают реальное поведение, а не синтетические кейсы, которых на проде практически не встречается (такие тоже написаны) и еще желательно не раздувать сьют, чтобы он проходил за вменяемое время, если мы хотим это встроить в пайплайн. В общем как-то так, ничего не понятно, но очень интересно.

Напоминание тестировщикам: Тестируйте так, чтобы ваше приложение не заloopилось😏

Преимущества Playwright Как и обещал (хоть и с опозданием и после лёгких пинков от читателя), делюсь преимуществами, которые мы получили после перехода с Selenium на Playwright. Итак, напомню контекст: у нас автотесты монолита запускаются в изоляции (почти). Сначала собираются все компоненты, затем создаются и загружаются их Docker-образы. Затем в тестах запускается docker-compose со всеми сервисами монолита, скачивается и запускается БД — и только после этого стартуют автотесты. Тесты разделены на два уровня: API и UI. В каждом уровне есть по 1–3 тест-сьюта, которые запускаются параллельно. Для каждого сьюта поднимается своё окружение, БД и запускаются тесты. API-тесты в этом улучшении мы не трогали, поэтому оставим их за скобками. Ещё важная ремарка: перед анализом я очистил данные от аномалий (несколько прогонов длились по 800+ и 1000+ минут), а также взял только успешные запуски на main — нашей основной интеграционной ветке, куда попадает уже проверенный и зарелизенный код. Что мы получили: 1. Сокращение времени прохождения пайплайна. Раньше среднее время составляло 22.88 минут, теперь — 20.46. На графике 1 (который, конечно, нарисовал Perplexity) видно ситуацию "до" и "после". Левый и правый "усы" показывают минимальное и максимальное время прохождений, цветная область — 25–75 персентили, а чёрточка внутри — медиану. После внедрения Playwright медианное значение снизилось примерно на 3 минуты. То, что в Selenium было ниже 25-го перцентиля, теперь стало 75-м в Playwright. Экономия выглядит умеренной, но если учесть что мы запускаем пайплайн около 30 000 раз в год (в 2024 году было так) — это примерно 60 000 минут, или 1000 часов экономии времени разработчиков ежегодно. Конечно, обратная связь о коде через 20 минут вместо 22 — совсем не радикальное сокращение, но в масштабе года результат приемлемый. 2. Снижение затрат на GitHub Actions. Раньше у нас было два сьюта UI-тестов — каждый проходил около 10 минут (примерно 4,5 минуты на поднятие окружения и 6 минут на выполнение тестов). Итого — 20 оплачиваемых минут. После перехода на Playwright остался один сьют с тем же количеством тестов, выполняющийся за 10-11 минут. На втором графике — видно насколько сократилось потребление времени для выполнения этих тестов (и, соответственно, денег). Максимальное значение в Playwright теперь ниже медианы Selenium. Если взять стоимость минуты в 0.008 $, то: 30 000 запусков × 9 минут × 0.008 $ = 2160 $ экономии в год. Неплохой результат за счёт одной только замены фреймворка. 3. Единый технологический стек. Приведение всех тестов к единому инструменту и экосистеме — бесценно, особенно для поддержки и найма новых сотрудников. И всё это — при 60 UI‑тестах. А представьте, сколько бы мы сэкономили, если бы тестов было 600 😅

Coverage Нарушаю долгое молчание небольшим подведением итогов того, чем занимался на работе. В прошлом квартале сфокусировались на внедрение сбора метрики покрытия: code coverage и покрытие API методов автотестами по Swagger документации (назовем его Swagger-coverage, для простоты). Мы планировали внедрить сбор и code coverage и Swagger-coverage во всех сервисах критического пути. Но удалось сделать только добавить Swagger-coverage во все сервисы. Как это работает: 1. берем актуальное описание API в Swagger документации; 2. в http-клиент для API-тестов добавляем handler, который логирует, какие эндпоинты вызываются в тестах, с какими параметрами и какие статус коды приходят; 3. сравниваем фактически вызванные эндпоинты с исходной схемой и строим отчет, в котором видно что покрыто, а что не покрыто (скрин 1). Текущие показатели этой метрики видно на графике. Разброс от 22 до 92% После вендрения хотели добавлять Quality Gates и фейлить билд если покрытие стало ниже чем было до этого. Но в результате обсуждение с архитекторами и разработчиками решили, что сделаем пока уведомление в корпоративный мессенджер в канал команды-владельца сервиса о том, что покрытие снизилось. Как считаете приемлемо, что у сервиса крит пути в API-тестах хоть как-то вызывается 22% эндпоинтов, а остальные не вызываются? Или надо наращивать покрытие?

Пока готовлю пост про преимущества которые мы получили от внедрения Playwright вместо Selenium, решил поделиться с вами видео. На видео два бага в одном😬(один связан с локалью, а второй с не понятным сообщением об ошибке) Мне кажется любой тестировщик рано или поздно сталкивается с багами связанными с мультиязычностью. Я не исключение. Мы в приложении пиццы долго боролись с тем, чтобы привести все переводы, тексты на картинках и т.д. к отображению на одном языке. На самом деле не до конца еще победили. До сих пор, у нас в приложении такое проскакивает, но в основном не в самых популярных категориях (скину скрин в тред). Казалось бы, ну должен быть текст кнопки на одном языке, а показывается на другом, вообще не проблема. Но иногда это может влиять на бизнес. Я помню времена, когда мы в режиме хотфикса (или просто баг с высоким приоритетом, точно уже не помню) чинили переводы в бэкофисе Dodo IS одной из европейских стран, потому что сотрудники негодовали от того, что русский язык просочился в инетрфейс. Поэтому у меня к вам просьба, если вдруг вы обнаружите в приложении Додо пиццы или Дринкита некорректные переводы - напишите баг репорт, чтобы мы это увидели и починили.

Наконец-то это случилось, ушла эпоха Selenium из Додо пиццы, пришла эпоха Playwright. Если читают те кто участвовал в этом, спасибо всем❤️

Нужно ли тестировать ML прогнозы? Моя команда разрабатывает фичу - группировщик заказов. Мы используем инструмент ORTools от гугла, который, в том числе, разработан для решения задач оптимизации маршрутов. У нас есть заказы, курьеры и различные ограничения на доставку (время за которое нужно успеть отвезти заказ, максимальная вместимость курьера, время через которое курьер вернется в пиццерию, время приготовления заказа, тип курьера и т.д.). Некоторые из этих ограничений предсказываются с помощью ML. Недавно мне задали вопрос "А как вы тестируете ML прогнозы?" Мы не тестируем, но я призадумался, а нужно ли нам тестировать прогнозы? С одной стороны можно рассмотреть прогнозы как обращение к стороннему сервису и ожидать что разработчики сервиса его протестировали прежде чем отдавать нам. Мы же не тестируем браузер перед тем как выкатить фичу. А с другой стороны, если они этого не сделали, мы будем получать невалидные результаты и наш оптимизатор будет работать плохо. Как вы думаете, стоит ли тестировать качество прогнозов или это не наша забота?