Тестирование IT-систем *

Тест на тестировщика: что в коробке?

Ответ: Это Shield box — экранированная коробка, внутри которой размещаются сотовые телефоны. Ее используют тестировщики телеком-оборудования. Коробка обеспечивает изоляцию сигнала и предотвращает возможность подключения сторонних абонентов к «тестовой» сети.

Если вы знакомы с этим оборудованием или хотите с ним познакомиться, вас могут заинтересовать несколько вакансий в команде Телекома в YADRO. 

→ Некоторые из них требуют образования по специальностям Радиотехнологии или Телекоммуникации и опыта работы с системами GSM/LTE. 

Test Engineer (LTE/GSM Radio Subsystem)

Команда занимается тестированием функционала базовой станции LTE/GSM на системном уровне в лаборатории или на площадке заказчика. Специалисту нужно будет разрабатывать тестовые сценарии и готовить требования к тестам радиоподсистемы LTE/GSM. Здесь у кандидата должно быть высшее образование в области телекоммуникаций или радиотехнологий, а также знание стандартов GSM//LTE, топологии и интерфейсов мобильной сети.

Field Test Engineer (LTE/GSM) 

Команда готовит тестовые сценарии для драйв-тестов, проводит их по подготовленным тест-планам и измеряет ключевые показатели производительности базовых станций LTE/GSM с помощью измерительных комплексов. Здесь также от кандидата требуются знания принципов и законов радиосвязи, базовое понимание теории антенн и их характеристик.

→ А вот несколько вакансий, где глубокое знание телеком-технологий не является решающим фактором при отборе кандидатов. 

Test Engineer (Performance Test)

Команда занимается тестированием собственного железа и ПО. Направление создает конкурентную линейки RAN-продуктов для мобильных сетей последних поколений — базовые станции LTE/GSM и удаленные системы управления ими. Опыт работы с телекоммуникационными системами GSM/LTE будет преимуществом. 

QA Automation Engineer 

Команда ищет инженеров по автоматизированному тестированию в несколько команд в направление разработки решений для телекоммуникаций. Необходимый опыт в автоматизации с использованием Jenkins GitLab — от двух лет. Здесь ждут кандидатов с уверенным знанием Python, Linux и пониманием сетей, базирующихся на TCP/IP.

Test Engineer Manual 

Вам больше по душе ручное тестирование? Есть вакансия и для вас. Здесь ждут кандидатов с уверенным знанием теории тестирования (опыт — от трех лет), Linuх и пониманием сетей, базирующихся на TCP/IP.

О направлении 

Команда Телеком с нуля создает телекоммуникационные решения для беспроводных мобильных сетей и сопутствующих услуг. Инженеры разрабатывают первые в России базовые станции стандартов GSM/LTE, реализуя полный стек телекоммуникационных протоколов для базовых станций и элементов ядра сети, а также системы управления и мониторинга. Здесь вы будете в хорошей компании: продукт создают профессионалы с многолетним опытом, многие из них работали в ведущих мировых телекоммуникационных корпорациях.

А как тестируют функции базовой станции, читайте по ссылке → 

Друзья, ночи доброй.

Если позволите, вкратце о себе. Зовут меня Саней. Имею опыт в тестирование более 3-х лет. В послужном списке тестирования были desktop-приложения для операторов БПЛА, системы защиты информации, система кредитования физических лиц и многое другое.

В настоящий момент работаю в компании QA-специалистом и одновременно являюсь ментором для людей, решивших стать тестировщиками.

Имеется богатый опыт теории и практики в тестировании, а также есть желание поделиться с ним.

Пишу пост на Хабре впервые и хочу узнать, "стоит ли игра свеч" и будет ли кому-то это интересно. Буду раз в неделю выкладывать статью о профессии QA, делаю упор на практику, которая вам в последующем пригодится на работе. И не будем забывать о теории, чтобы успешно пройти интервью)))

Всем огромное спасибо!

ИИ-агенты в Альфа-Банке: нейросети создают автотесты без участия человека

Не фантастика, а реальность: в Альфа-Банке мы внедрили ИИ-агентов, которые проектируют, разрабатывают и проверяют автотесты. При этом полностью автономно, как настоящие QA-инженеры, но в разы быстрее и точнее. Это первый в России кейс, когда нейросети полностью закрывают цикл создания тестов — от анализа требований до пул-реквеста.

✨ Что умеют наши агенты?

🧠 Анализировать контекст из Jira и Confluence, вычленяя суть задачи.
🔍 Прогнозировать риски, зависимости и даже «пограничные» сценарии.
🛠️ Генерировать DTO для REST API и превращать ручные сценарии в Java-тесты за минуты.
✅ Сверять код с бизнес-логикой и техстандартами Альфы, защищая прод от случайных ошибок.
🌐 Создавать вариативные проверки — от позитивных кейсов до сложных негативных условий.
⚡ Автоматизировать рутину — и это лишь часть их скиллов.

В ИИ-команде QA есть несколько агентов, каждый работает над своей частью из перечная выше. Сейчас решение пилотируется в нескольких продуктовых командах, но результаты уже впечатляют: меньше ошибок в проде, предсказуемые дедлайны и высвобожденные ресурсы для творческих задач.

«Одна команда ИИ-агентов экономит десятки часов работы, увеличивает скорость релизов и находит на 30% больше багов», — делится Святослав Соловьев, Директор по генеративному ИИ в ИТ Альфа-Банка.

🔜 Скоро расскажем подробнее — как устроены агенты, какие технологии behind the scene и как мы измеряем их эффективность. Оставайтесь с нами!

Дашборд — лицо системы: как сделать его удобным для команд из более 100 инженеров

Переосмысление дашборда стало одной из важных задач в процессе обновления интерфейса TMS TestY.

Разработчики сохранили общий принцип навигации после входа в приложение. Пользователь попадает на борду, где ему доступен переход на овервью, тестовые сьюты и тестовые планы. Сохранили возможность фильтрации по избранному, показ архива, статистику по проектам.

В Testy 2.0 можно выбрать, на каком языке будет работать система. Раньше интерфейс TMS был полностью англоязычным, теперь пользователям доступен русский язык — как часть плана поддержки локализации.

Добавили поиск по проектам и табличное представление, в котором доступно то же самое, что и на карточках: переходы, добавление в избранное, переключатели Only Favorites и Show Archive

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

Какие еще обновления появились в TMS с открытым исходным кодом, читайте в статье.

Зачем нужны юнит-тесты

Код в проекте всегда развивается итерационно. Функционал развивается и дорабатывается, внешний мир меняется и требует каких-то изменений, обнаруженные баги требуют фиксов. В результате много времени разработчик тратит на чтение кода и его модификацию. Чем больше проект, тем больше времени требует отладка для выяснения места возникновения ошибки, а после модификации требуется тонна времени на проверку, что ничего не сломалось.

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

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

Бонусом юнит-тесты улучшают код. Грязный код с большим количеством внешних зависимостей, со множеством задач в одной функции, десятками вложенных if, глобальными переменными и прочими плохими практиками тестировать сложно. В результате необходимость написать юнит-тест толкает разработчика на декомпозицию функции на более простые, которые легче покрыть тестами. Но эти же функции становится легче понять стороннему разработчику.

Кстати, ИИ нынче отлично умеет писать тесты. И полезно не забывать про антипаттерны тестирования ПО.

«Слово о нагрузочном тестировании: курс на успешную миграцию»

📅 13 февраля, 16:00

А как тестируете вы?
📈13 февраля на онлайн-митапе обсудим преимущества и недостатки различных методов проведения нагрузочного тестирования. На примере реального кейса миграции СУБД представим нашу собственную методику оценки производительности информационных систем!

👨‍💻 Спикеры мероприятия:

— Роман Севрук, менеджер по развитию решений СУБД

— Александр Зубков, инженер по автоматизации нагрузочного тестирования

— Алексей Сатин, архитектор инфраструктурных решений

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

Почему совершать ошибки — полезно: рассказывают наставники Практикума

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

Тест, который не работал
Рассказывает Дарина Кухтина, наставница на курсе «Аналитик данных»

Я руковожу отделом аналитики в мобильном геймдеве. Мы запустили А/В-тест для игровых автоматов, чтобы проверить разные расстановки. Более успешные слоты поставили в начало. 3а две недели эксперимента не произошло никаких изменений. 

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

Выводы:

• Нужно пользоваться своим продуктом: заходить на сайт или играть в игру, над которыми идет работа.

• Ошибка может быть в любом месте.

• Чем раньше заметить ошибку, тем лучше. Это экономит время, а время — деньги.

• Никому нельзя верить, даже себе.

Самокаты начали сигналить по всему городу
Рассказывает Андрей Шевченко, наставник на курсе «Инженер по тестированию»

Команда тестировала новую фичу для кикшеринга самокатов перед продакшном. Тогда мы не нашли одну из моделей самокатов и не перезапустили сервисы после доработки. 

Со следующим обновлением они перезапустились сами, в том числе единственная модель, которую мы не протестировали. Две тысячи самокатов сигналили два часа подряд. Было неприятно, но мы быстро собрались и вместе устранили проблему.

Выводы:

• Команда всегда тебя поддержит.

• Если ты где-то облажался, то облажалась вся команда.

• Окружение важно! Покройте проверками максимум.

• Перезапускайте сервисы после обновлений.

• Ошибок не допускает только тот, кто ничего не делает.

Есть ли ошибка, которая помогла вам стать лучше? Расскажите об этом в комментариях.

Последний Go-митап в этом году: как Go меняет подходы к разработке и тестированию

Уже через несколько часов, в 19:00, начнется онлайн-трансляция финального в этом году Go-митапа, где разработчики и технические лидеры сообщества обсудят инструменты кодинга на Go. В мероприятии примут участие эксперты из YADRO, Wildberries, Weborama и Ви.Tech. Регистрируйтесь на онлайн-участие. 

Программа:

Приветственное слово: Руслан Барсуков, ведущий инженер по разработке ПО в YADRO, и Виталий Левченко, технический менеджер в Wildberries, расскажут о планах Go-сообщества в Нижнем Новгороде.

«Генерация стабов для тестирования микросервисов по gRPC»

Кирилл Шувалов, разработчик дивизиона Телеком в YADRO, покажет, как с помощью Protoc стандартизировать тесты, упрощая их написание и повышая читаемость.

«Стриминг данных из Snowflake в Couchbase»

Александр Ванюшкин, разработчик в Weborama, поделится опытом создания плагина для Redpanda/Connect для оперативной обработки данных.

«Сборка проектов на Go: от Make до Mise»

Даниил Подольский, эксперт по разработке ПО в YADRO и один из лидеров внутреннего Go-сообщества, расскажет о развитии инструментов сборки и выборе оптимальных решений.

«Почему мы пилим монолит без микросервисов»

Кирилл Кузин, старший golang-разработчик, Ви.Tech, объяснит, как команда поддерживает сложную архитектуру и избегает ошибок при распиле монолита.

Пришлем ссылку на онлайн-трансляцию после регистрации на сайте →

Написание тестов и крепкие нервы

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

Тесты могут причинить немало хлопот, если нет систематизированного подхода к их написанию. Самый нашумевший из них – TDD.

TDD (Test-Driven Development)

Разработка через тестирование - этот подход имеет как минимум пару особенностей:

• Тесты пишутся до написания кода. Потом обеспечивается их прохождение и рефакторинг кода. И так по кругу.

• Не так легко сходу начать применять его, особенно, когда над ухом слышишь, как спрашивает бизнес: «Ну что, готово?». Нужна практика и время.

Моя стратегия написания тестов, обычно, сводится к следующим двум подходам (аббревиатура из головы):

БКТ (блок кода, тест)

Использую чаще всего. Он не заставляет судорожно бегать по коду и анализировать, все ли кейсы были учтены. Минус в том, что написанное может не пригодится в итоге. Стирается код, удаляются тесты. Как итог - выкинутое в мусорку время.

ВКТ (весь код, тесты)

Сначала пишется код, потом ищутся случаи, которые нужно протестировать. Благо, если заранее, в тестовом классе, были описаны ветвления тестирования с комментариями, типа:

// API (Контроллер)
  // Запрос на получение данных
    // запрос пустой
      // ок – вернуть все данные
	// иначе
      // проверить корректность полученных данных
         // корректно – вернуть данные
      	 // иначе – сообщить об ошибке
…
// Сервис (бизнес-логика)
…
// Инфраструктурный слой (получение данных из другого сервиса, бд и пр.)
…

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

А какие подходы к тестированию применяете вы?

Все переплетено: как устроен тестовый стенд для базовой станции

Так выглядит схема тестового стенда, с помощью которого тестируют важную фичу базовой станции — handover. Handover помогает мобильным телефонам, ноутбукам и другим гаджетам «перескакивать» с одной БС на другую и не терять сигнал.

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

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

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

О других особенностях тестирования handover читайте в статье → 

Дневник тестировщика. Записки разных дней.

Баг был, а теперь его нет. Куда пропал?

Я смеялась, когда они говорили: “Справимся за 2 дня.” Я плакала, когда справились.

В тестировании что главное? Правильно — не спать. А то разработчики сами всё протестируют.

Иногда, чтобы найти баг, нужно узнать, кто не писал код.

Как выпустить релиз без багов? Слёзно просить работать по процессам и перечитывать требования не помогает. Я проверяла.

— Нужно делать по правилам! — кричал зелёный QA Engineer.
— А ты попробуй, заставь! — бурчал седой разработчик.
— Вы зря пыжитесь, — ухмылялся Legacy-код.

Я думала, этот функционал тестирует мой коллега. Он думал, его тестирует третий. Третий ушёл в отпуск.

Просили фичу. Получили баг.

Как выпустить релиз без багов? Слёзно просить раскоммитить и пофиксить flaky-тесты не помогает. Я проверяла.

Тестировала, тестировала — да не вытестировала. День, когда деплой уронил продакшн.

Обожаю IT-фэнтези. Часто пишу его в тикетах.

Чем дольше я на проекте, тем проворнее баги. Эволюция?

Деплой не сошёл с ума. Он удивляет.

Красивый был баг. Жалко, что пофиксили.

Так выглядит измерительный стенд инженеров, разрабатывающих операционную систему kvadraOS

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

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

Оценить константную нагрузку несложно:

• Сначала зарядим планшет до 100%, выдернем шнур USB и дадим планшету полежать с выключенным экраном ровно 2 часа. В нашем эксперименте планшет за два часа разрядился на 1%. Это уровень потребления устройства в состоянии покоя. Значит, все потребление энергии, которое мы измерим потом, будет скорее связано с дополнительными нагрузками.

• Затем запретим экрану выключаться, опять зарядим планшет до 100%, выдернем шнур USB и дадим планшету полежать уже с включенным экраном, тоже ровно 2 часа. На этот раз планшет разрядился на 9%. Если первая проверка, с выключенным экраном, проверяла, что нет катастрофических аномалий с железом, то эта проверка говорит, что эти 9%, собственно, накладные расходы от включенного экрана и активного CPU с запущенной на нем ОС.

Для каких экспериментов понадобилась такая константа, читайте в статье → 

Друзья, в рамках запуска комплексной программы «Fullstack-тестировщик» решили поговорить о том, как может выглядеть карьера в тестировании. 19 ноября приглашаем вас на онлайн-встречу «От ручного к Fullstack: как строить карьеру в тестировании» с Исангуловым Тимуром, ведущим инженером-тестировщиком IBS AppLine Innovation.

Тимур работал в различных командах и занимал разные должности, что дало ему богатый опыт в тестировании. Он подробно расскажет, как начал свою карьеру и каким образом из новичка в ручном тестировании превратился в ведущего Fullstack-тестировщика. Также он поделится ценными советами для тестировщиков.

Вы можете задать Тимуру вопросы о работе QA прямо в эфире или оставляйте их в комментариях к этому посту, а ответы приходите слушать 19 ноября.

📅 Дата: 19.11.2024

⏰ Время: 16:00-17:00 (Мск)

👨‍🎓 Спикер: Исангулов Тимур — ведущий инженер-тестировщик IBS AppLine Innovation.

👉 Записаться на встречу «От ручного к Fullstack: как строить карьеру в тестировании» 👈

Не знаю на сколько это свежая новость ибо прочитал в новостях, но факт занимательный. JetBrains (опять) изменила лицензирование сделав IDE для Rust, JavaScript, C# и тестирования бесплатными для некоммерческого использования.

На сколько это следствие продвижения ИИ в средствах разработки - поди знай, но уж больно совпало по времени.

Призы для самых ловких – мы подвели итоги конкурса и готовы рассказать результаты

25 сентября у нас был День компании, и этот праздник мы отмечали с хабравчанами – вместе с Хабром собрали игру-раннер с сюрпризами и подарками для самых ловких пользователей. Розыгрыш призов уже закрыт, но игра ещё доступна, если захотите попробовать поиграть – переходите по ссылке. 

В игре было три карьерные дорожки: изобретательный Java-разработчик, вдумчивый системный аналитик и зоркий QA-тестировщик. Игроки проверяли свою ловкость, обходя препятствия и отвечая на рабочие вопросы по теме выбранной карьеры. Все, кто успел сыграть в период проведения розыгрыша и набрал более 200 очков – получил промокод на сервис Wink и попал в турнирную таблицу. Дальше среди участников таблицы при помощи рандомайзера мы разыграли 30 различных призов лично от нас – по 10 для каждого направления игры.

Имена победителей уже известны. Прикрепляем таблицу: вот ссылка. Если вы нашли свой никнейм – поздравляем, вы уже получаете промокод от Wink! Если напротив вашего никнейма написано «суперприз» – поздравляем ещё больше – вы счастливчик, выигравший отдельный приз. Мы свяжемся со всеми финалистами в личных сообщениях и расскажем, как забрать выигрыш.

Сайт, готовый ко всему — Никита Дубко / Ural Digital Weekend 2024

Опубликовали запись доклада секции «Разработка» с Ural Digital Weekend 2024.

Вспомните, где вы обычно тестируете свое веб-приложение. Скорее всего, у вас есть несколько вьюпортов, в которых вы быстро проверяете верстку и, возможно, пишете автотесты. И багов от пользователей почти нет — значит, все делаете правильно. Но как вашим сайтом пользуются на самом деле? Что нужно предусмотреть, чтобы сайт работал действительно почти везде?

В докладе вы найдете множество интересных примеров и отсылок. Заходите посмотреть!

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/NRS

Друзья, в рамках запуска комплексной программы «Fullstack-тестировщик» решили поговорить о том, как может выглядеть карьера в тестировании. 29 октября приглашаем вас на онлайн-встречу «От ручного к Fullstack: как строить карьеру в тестировании» с Исангуловым Тимуром, ведущим инженером-тестировщиком IBS AppLine Innovation.

Тимур работал в различных командах и занимал разные должности, что дало ему богатый опыт в тестировании. Он подробно расскажет, как начал свою карьеру и каким образом из новичка в ручном тестировании превратился в ведущего Fullstack-тестировщика. Также он поделится ценными советами для тестировщиков.

Вы можете задать Тимуру вопросы о работе QA прямо в эфире или оставляйте их в комментариях к этому посту, а ответы приходите слушать 29 октября.

📅 Дата: 29.10.2024

⏰ Время: 15:00-16:00 (Мск)

👨‍🎓 Спикер: Исангулов Тимур — ведущий инженер-тестировщик IBS AppLine Innovation.

👉 Записаться на встречу «От ручного к Fullstack: как строить карьеру в тестировании» 👈

Как Duolingo добилась успеха на рынке и причем тут аналитика

Duolingo — одно из самых популярных приложений для изучения языков (№1 по скачиванию в магазинах приложений). Вместо скучных уроков оно напоминает игру: прогресс, уровни, награды, упражнения мини-игры и др.

По данным компании, около 34 млн. человек используют Duolingo каждый день.

Но что стоит за этим успехом?

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

В любой момент в Duolingo могут проводиться несколько сотен A/B тестов одновременно. Экспериментируют со всем: от мелких изменений интерфейса до запуска крупных функций, как Лидерборды. Для A/B тестирования компания разработала собственный сервис.

➡ Как выглядят эксперименты в Duolingo: статья.

➡ Пример A/B тестирования: формирование привычки учиться регулярно: статья.

➡ Какие аналитические инструменты использует компания для анализа данных: статья.

О других принципах успеха Duolingo и работе в этой компании писала тут.

Путь тестировщика: ошибки, опыт, деньги. Вышел новый Sravni Podcast!

В новом выпуске поговорили о сути QA, отношениях тестирования и разработки, неизбежности багов и ответственности за плохие релизы. Гость — Анна Серенькова, QA Mobile Lead Сравни.

В этом выпуске:

• Что должен уметь тестировщик и сколько ему платят?

• В чём разница тестирования в вебе и на мобильных устройствах?

• Почему в ИТ важно доказывать свою ценность, и в чём здесь отличия для женщин и мужчин?

• Право на какое количество ошибок есть у тестировщика, прежде чем его уволят?

Подкаст доступен по ссылкам:

✅ YouTube
✅ RUTUBE
✅ VK
✅ Яндекс.Музыка

Оперативно узнавать о наших новых подкастах, докладах, лекциях и других полезных ИТ-материалах, можно в тг-канале Sravni Tech.

Как в Авито устроено API-тестирование на Go?

В этом видео Глеб Дмитриев, инженер из команды Marketplace, рассказывает о проблемах, с которыми мы сталкивались на этапе выбора фреймворка для тестирования, и показывает, как работает наш собственный фреймворк на основе Testify.

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

Ранее Александр Трифанов, техлид Авито, рассказал о нашем подходе к сканированию данных в API.

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.