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

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

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

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

Чюваки запилили топовую визуализацию карты телеграмм каналов. Близкие по тематике каналы собираются в кластер. Нашел себя в кластере 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 минут

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% эндпоинтов, а остальные не вызываются? Или надо наращивать покрытие?CoverageНарушаю долгое молчание небольшим подведением итогов того, чем занимался на работе. В прошлом квартале сфокусировались на внедрение сбора метрики покрытия: code coverage и покрытие API методов автотестами по Swagger документации (назовем его Swagger-coverage, для простоты). Мы планировали внедрить сбор и code coverage и Swagger-coverage во всех сервисах критического пути. Но удалось сделать только добавить Swagger-coverage во все сервисы.Как это работает: 1. берем актуальное описание API в Swagger документации;2. в http-клиент для API-тестов добавляем handler, который логирует, какие эндпоинты вызываются в тестах, с какими параметрами и какие стат

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

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

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

Как вам такие подсказки на киоске? 😏