🛠️Инструменты
В этой статье показано, как превратить баг-репорты Jira в воспроизводимые Playwright-тесты с помощью ChatGPT.
В этой статье расскажу, как мы используем связку Proxyman + HAR, чтобы готовить mock-данные сетевых запросов для интеграционных UI-тестов одного из iOS-приложений. Такой подход выручает, когда для тестов нет возможности поднять сервер с нужным наполнением или сервер не предоставляет дополнительных методов API для имитации определенного сценария — например, переписка в чате с собеседником, обновление статуса заказа.
С выходом Playwright 1.56 в инструменте появились три новых агента: Planner, Generator и Healer. Они помогают создавать сценарии, поддерживать тесты и выявлять нестабильное поведение.
Забыть про лишние переустановки приложений в Appium, динамически переключаться между сборками, не меняя код – с этим помогут разные комбинации noReset и fullReset
В этой статье представлены Chrome-расширения для QA-инженеров, которые не повторяют функции DevTools, а дополняют их. Эти инструменты помогают автоматизировать рутинные задачи, ускоряют проверку форм и API, упрощают анализ данных и визуальное тестирование, а также открывают возможности для проверки сценариев, которые сложно реализовать стандартными средствами браузера.
В этой статье мы разберём общую концепцию локаторов, критерии их качества и ограничения классических подходов. Затем рассмотрим, как Playwright переосмыслил эту философию.
Список не про генерацию тест-кейсов или чек-листов — про это уже написаны километры текстов.
Сегодня поговорим о сценариях, которые редко обсуждают, но которые могут сразу и заметно улучшить вашу работу с ИИ.
👔Собесы
Да, на Хабре много постов о том, как проходят такие встречи и как к ним подготовиться. Но сегодня хочу поделиться именно своим опытом: подскажу, какие книги прочитать, чтобы укрепить базу, — шок-контент, но их всего две.
Почему оффер ломается не на алгоритме, а на вопросе «кем вы видите себя через 5 лет?» — разбираю шесть таких ловушек и показываю сильные ответы.
✍️Рассказы
2025 год начался с короткого затишья текущих проектов, возникла идея поковырять тему нагрузочного испытания радиоподсистемы Wi-Fi. Основная сложность и основной вопрос всех нагрузочных тестов — Чем нагрузить? Вот этот вопрос попробуем разобрать в этой статье …
Спойлер: рассчитывать можно на многое, но и вложиться придётся основательно. Парой промптов тут, к сожалению, не обойтись.
У нас есть веские причины на то, чтобы пока не присоединяться к таким компаниям, как Anthropic (генерируется 80%), Microsoft (30%) и Google (25%).
Пока нам недостаёт в них некоторых жизненно важных элементов. В статье мы расскажем, почему это важно, и что нужно, чтобы закрыть эту нехватку.
Пример из практики: комплексный проект по рефакторингу системы управления доступами. Интеграция приложения по управлению доступами на основе ролей и привилегий (это наша Новая система) с другими информационными системами (ИС) в контуре предприятия (например, управление учетными записями, авторизация пользователей и прочие).
Иногда в процессе разработки внезапно выясняется, что привычные подходы к тестированию перестают работать: автотесты громоздкие, данные — одноразовые и неудобные, а тестовые фреймворки уже не спасают. В такой момент команда или буксует, или придумывает что-то новое.
Пишу, потому что на текущем проекте прямо сейчас живу эту боль: всем включили Cursor «для скорости», а нормальных автотестов так и не завезли. Может, кто-то уже описывал этот кейс, но я не нашёл — поэтому делюсь своей ситуацией и тем, как это надо было делать с самого начала.
В последние годы спрос на 2D/3D-инструменты в веб-сервисах растет довольно стремительно, технологии развиваются, появляются новые подходы и библиотеки — а вместе с ними растёт и путаница: что где использовать, где грань между похожими решениями и почему у разработчиков часто возникают противоположные мнения?
Так что я решила устроить небольшой тест 2D-решений: посмотреть, на что они реально способны, понять, почему результаты местами вызывают большое удивление, и ответить себе (и вам) на вопрос: а WebGPU вообще зачем?
Основное направление моей работы — это исследования программных сетей, сетевых сервисов и их производительности. В этой статье хочу рассказать, как я искал точку отказа прокси-балансировщика. Расскажу и про метрики, и про инструменты, и как я автоматизировал измерения. Путь оказался весьма извилист, наполнен граблями и шишками, зато результат был познавательными. Статья будет интересна разработчикам сетевых сервисов, DevOps-инженерам и тестировщикам, исследующим проблемы производительности сети и сетевых сервисов.
И вот вы, фронтенд-разработчик, сидите с открытыми DevTools десктопного браузера, используете симуляцию мобильного устройства, и локально все идеально. А тестировщики все несут и несут баги. Верстка убегает, само веб-приложение тормозит, часть UI просто не достать пальцем, да и в целом жесты работают так, как им захочется.
Например, в управлении транспортом статичные данные (например, сет за «типичный вторник») не дают протестировать систему в условиях праздника, крупной аварии, сессии у студентов, скидки 99% на Лабубу в крупном супермаркете и так далее.
В этом посте хочется поделиться 20-летним личным опытом в тестировании и приходу к частичному отказу от тестовой модели с использованием тестовых кейсов. Переход был плавным. Не планировала загружать статью сложными метриками и цифрами, но хотела показать постепенную эволюцию сквозь призму личного опыта в стиле некоторого ревью.
Однажды я пришел на проект, на котором выполнение некоторых тест-сьютов занимало больше часа, настолько медленно, что запускать их на каждый merge request (MR) было просто нереально. Мы хотели запускать автотесты на каждый коммит в MR, но с такой скоростью это было невозможно. В результате мне удалось, за счёт серии небольших, но точных изменений добиться 8,5-кратного ускорения — без переписывания тестов с нуля.
Когда ты тестируешь интернет-магазин, пропущенный баг — это съехавшая вёрстка. Но если ты тестируешь высоконагруженную СУБД — это остановка бизнеса федерального масштаба. Разбираем внутреннюю кухню QA в Postgres Professional: от борьбы с утечками памяти через ASAN и Valgrind до «вайб-кодинга» с ИИ.
Расскажем о необычном, но интересном опыте автоматизации и роботизации тестирования банкоматного ПО в Т-Банке, для которого мы использовали коллаборативного робота.
💡Философия
Я всегда интересовалась здоровьем и фитнесом, потому что хочу жить долго и полноценно. Но с возрастом я поняла, что методы, которые раньше помогали мне оставаться в форме, перестали работать: я постепенно набрала 30 фунтов (~13,5 кг) и поняла, что нужно что-то менять. Изменения были внедрены, и я вернулась к своему прежнему весу.
В последнее время я много говорила о качестве программного обеспечения и о том, почему командам сложно внедрять хорошие практики. И сегодня меня осенило: между поддержанием здоровья по мере взросления и поддержанием «здоровья» программного обеспечения много параллелей. Давайте рассмотрим распространенные оправдания, которые мешают оставаться «в форме».
Первоначальный энтузиазм быстро сменяется осознанием: тестирование робота — это проверка его способности взаимодействовать с хаотическим миром. И самый сложный вопрос — не «как тестировать?», а «что именно и в каком объеме нужно тестировать?».
📺Видео
- 👀The mobile testing paradox ⏱️1 час
In episode 114 of This Week in Quality, co-hosts Ben Dowen and Simon Tomes are joined by Dan Caseley and Maithilee Chunduri for a focused and practical conversation about the realities of mobile testing. The group begins by reflecting on recent discussions in the community before shifting into the core theme of the episode: how mobile testing has become both simpler and more complex at the same time.
- 👀Как погрузиться в автоматизацию за 60 дней ⏱️45 минут
Расскажу о собственном опыте, как я будучи QA-lead ручного тестирования 2 месяца погружался в автотесты на Playwright + TypeScript
- 👀Проверка и отладка Accessibility ⏱️45 минут
Первый запуск скринридера может напугать и даже причинить боль. Без понимания его работы начинающий специалист может увеличить количество ошибок вместо их устранения. В интернете полно теории про требования контраста, семантическую вёрстку и другие основы доступности. Но когда дело доходит до поиска причин некорректной работы, не знаешь куда смотреть, тратишь лишнее время, и хочется всё бросить.
