Привет! Меня зовут Оля Шнайдер, я QA-инженер в Авито. В начале этого года я провела исследование рынка QA, чтобы понять, как сейчас работают тестировщики: с чем сталкиваются каждый день, что мешает в работе, а что, наоборот, помогает.
За последние годы роль QA заметно изменилась (или мне так хочется думать). От нас ждут большего — не только непосредственно тестирования и ответственности за результат, но и участия в процессах и много чего ещё. При этом сами процессы не всегда становятся лучше.
Прокси — один из основных инструментов в арсенале QA-инженера. Charles Proxy, Fiddler и Proxyman давно стали стандартом для анализа и изменения сетевого трафика в процессе ручного тестирования. Их принцип работы хорошо известен и подробно описан во множестве материалов.
Однако возникает вопрос: как использовать подобные возможности в UI-автотестах? Как перехватывать или мокать трафик в автоматизированных сценариях? Давайте разберёмся.
Статья рассказывает о внедрении автоматизированных тестов для CROSSOUT.
В статье описан процесс создания тестового окружения и обоснован выбор инструментов, которые позволили нам справиться с требованиями проекта.
Сегодня я расскажу о нашем опыте создания и внедрения автоматизированных тестов в разработку Crossout.
Если вдруг кто-то вдруг еще не поиграл, вот пара слов о ней. Crossout - многопользовательская онлайн-игра в жанре постапокалиптического экшена.
«Машина может пересчитать все звёзды на небе, но не может понять, зачем человек смотрит на них».
— Айзек Азимов
В одну из пятниц у нас была обычная онлайн‑встреча. Еженедельный обмен знаниями, так сказать. Коллега решил показать что‑то «интересное про MCP» — и началось всё безобидно, с классического объяснения теоретической части. Но спустя час было очень тихо на звонке. Никто не перебивал, не шутил, не задавал вопросов, просто все слушали и пытались осознать происходящее. Тема оказалась куда глубже, чем мы ожидали, и, как выяснилось, напрямую касается того, чем мы занимаемся каждый день.
Я — Маша Лещинская, Head of QA в Surf. Постоянно вижу, как в мобильной разработке все гонятся за ускорением релизов и внедряют ИИ везде, где можно. Но не видят корень проблемы: раньше поймал ошибку — меньше потратил и быстрее выпустил. Мы в Surf сделали из этого систему: применили shift-left подход, запретили разработчикам писать код, подключили ИИ на каждом этапе и ускорили релизы вдвое.
Мы построили три линии обороны, где AI ловит баги раньше всех. Больше примеров и лайфхаков про внедрение ИИ-технологий — в канале нашего CEO.
Shift‑left Читать полностью »
Привет! Мы команда из отдела разработки ПО для банкоматов Т-Банка: Александр, Владислав, Иван и Денис.
Продукты класса ContentCapture работают с большими объемами документов, и для бизнеса критична скорость их обработки. Но как убедиться, что система не замедлится после выхода очередного релиза? Здесь на помощь приходит тестирование: наши QA-инженеры регулярно проводят замеры скорости распознавания — например, при обновлении технологии или перед запуском нового проекта.
Казалось бы, все просто: автоматизируешь тесты, замеряешь время — и получаешь объективные метрики для оптимизации. Но на практике даже идеальная автоматизация не спасает от неожиданных сценариев.
Бывали ли у вас ситуации, когда для тестирования нужен сервис, а он ещё не готов, нестабилен или доступ к нему ограничен? В такие моменты на помощь приходят стабы и моки. Один из самых удобных инструментов для этого — WireMock. Он позволяет легко эмулировать работу backend-сервисов, подменяя реальные ответы на заранее подготовленные.
В этой статье я расскажу, как запустить wiremock-standalone.jar, и покажу, почему этот инструмент одинаково полезен как мануальным тестировщикам, так и автоматизаторам.
В системах интеллектуальной обработки документов корректность извлечения данных — это лишь половина дела. Гораздо важнее, чтобы при скачке нагрузки сервис не превратился в бутылочное горлышко.
В этой статье расскажем, как мы:
автоматизировали нагрузочное тестирование, сократив ручную работу инженеров на 85%;
встроили стресс-тесты в CI/CD, чтобы каждая фича доказывала свою устойчивость перед релизом;
научились предсказывать поведение системы не на глаз, а по данным — даже при росте объемов в несколько раз.
Метрики — это количественные показатели, которые помогают отслеживать эффективность процесса тестирования и выявлять области для улучшения. Например:
Процент дефектов в критических модулях: Этот показатель помогает понять, насколько стабильны ключевые компоненты приложения, важные для пользователей.
Скорость обнаружения дефектов (Defect Discovery Rate): Оценка того, насколько быстро обнаруживаются баги. Чем быстрее инженер находит дефекты, тем быстрее они могут быть устранены.
Ретесты и регрессии:Читать полностью »
