💡 TestEngineer
Попытка создания интегральной метрики качества продукта

Каждая метрика рассказывает свою историю, но не всю. Цель QE-балла — объединить их в один целостный показатель качества, который можно отслеживать со временем, использовать совместно с другими командами и применять для принятия решений.
Тестирование в залогиненном состоянии с расширением Playwright MCP

Если вам когда-либо приходилось тестировать приложение, требующее аутентификации, вы знаете, как это неудобно: приходится логиниться каждый раз или, еще хуже, передавать учетные данные в LLM. С новым расширением для браузера Playwright MCP для Chrome и Edge в этом больше нет необходимости. Теперь вы можете запустить сервер MCP, используя существующий профиль браузера, который уже залогинен, и тестировать ваше приложение.
Быстрый рефакторинг e2e автотестов в Copilot

Не «Проведи рефакторинг этих файлов так как надо», а: «Я извлек свойства и методы в эти объекты страниц, теперь проведи соответствующий рефакторинг прикрепленных файлов спецификаций e2e».
Как работает Playwright MCP — подробно

Чтобы понять, как AI-агенты могут выполнять осмысленные задачи —запускать команды, искать файлы или взаимодействовать с системой — сначала нужно разобраться, как устроен вызов функций LLM.

Критическое мышление, креативность и способность мыслить нестандартно — незаменимы.
💬 Также
Кэширование — это невоспетый герой современных приложений: оно повышает производительность и сокращает время загрузки. Но в автоматизированном тестировании этот же герой может превратиться в нарушителя порядка, вызывая нестабильность и несогласованность результатов. Кэши на фронтенде — такие как хранилище браузера или service workers — и на бэкенде — например, CDN или кэширование запросов к базе данных — могут сделать тесты ненадёжными, если с ними неправильно обращаться. В этой статье мы рассмотрим влияние кэширования на автоматизацию тестирования, выделим основные проблемы и предложим практические стратегии, которые помогут обеспечить стабильную работу тестов при каждом запуске.
Мнение: неизвестные пробелы в тестовом покрытии
Тестирование — это наука не о том, чтобы доказать, что программа работает корректно, а о том, чтобы доказать, что она работает НЕкорректно. И если доказать это не удалось, то с какой-то вероятностью программа работает корректно. Остается некоторый пробел. Давайте рассмотрим, что за это за пробелы, откуда берутся и как можно их минимизировать.
Что показали 15 лет работы с пирамидой тестирования
Пирамида тестирования давно считается классикой QA, но ее реальное применение зависит от множества факторов. Архитектура, команда и доверие к тестам сильно влияют на баланс юнит-, интеграционных и E2E-тестов.
Все, что нужно знать о регрессионном тестировании в 2025 году
В статье рассмотрены подходы — от смоук-тестов до полной регрессии, а также роль автоматизации и приоритизации.
Как тестировать взаимодействие с голосовыми интерфейсами и виртуальными помощниками
Голосовые ассистенты прочно вошли в нашу жизнь, трансформировавшись из модного гаджета в полноценный бизнес-инструмент. Они управляют умным офисом, интегрируются с корпоративными системами (CRM, ERP), автоматизируют процессы бронирования и клиентской поддержки. Для QA-специалистов это означает появление нового, сложного и крайне перспективного объекта для тестирования. Голосовой интерфейс (VUI — Voice User Interface) ломает все традиционные парадигмы веб- и мобильного тестирования, требуя совершенно иного подхода к построению стратегии обеспечения качества.
⚙️Хабр
MES-система глазами тестировщика
Привет, дорогой читатель! Я, Владимир Зиновьев, ведущий тестировщик в ИТ-команде «Северстали». Если тебя заинтересовала эта статья, то скорее всего ты такой же тестировщик, как и я, и задаёшься вопросом, как эффективно выстроить свою работу. Здесь я поделюсь долгим путём нашей команды со всеми «шишками» и успехами тестирования наших систем в большом MES-проекте. Особенно я бы порекомендовал обратить внимание на раздел с тестированием «Legacy-системы», так как там применялись довольно нестандартные и интересные подходы, по-моему мнению, конечно. Давай погружаться.
Core Web Vitals на практике: как инфраструктура убивает ваш SEO (и что с этим делать)
И вот что интересно: по моему опыту работы с несколькими десятками e-commerce проектов, в 60-70% случаев узким местом оказывается именно инфраструктура. Не JavaScript. Не картинки. А сервер, который медленно отвечает, или отсутствие кэширования, или shared hosting с перегруженными соседями.
Сегодня я расскажу, как инфраструктура влияет на Core Web Vitals, покажу реальные кейсы с цифрами и дам чек-лист для аудита. Без воды, только практика.
Как тестирование влияет на репутацию бренда
Экономическая ценность репутации в российском контексте
Деловая репутация российских компаний сегодня измеряется не только лояльностью клиентов, но и конкретными финансовыми показателями. Согласно исследованию, проведенному в 2024 году, организации с высоким уровнем доверия к своему бизнесу и клиентам демонстрируют заметно более высокую рентабельность, что подтверждено на примере финансового сектора и сферы розничной торговли. Укрепление доверия способствует увеличению прибыли и устойчивости компаний благодаря повышенной лояльности клиентов и эффективности управления. В частности, рентабельность капитала в банковском секторе в 2024 году достигала около 24%, что частично связано с ростом доверия клиентов и партнеров.
Восстановление репутации после кризиса зачастую требует значительно больших ресурсов, чем профилактика инцидентов и проблемных ситуаций. Например, после масштабного сбоя в системе онлайн-банкинга одного из крупнейших российских банков в 2023 году, банк понес многомиллионные затраты на компенсации клиентам, а также на маркетинговые и PR-кампании, направленные на восстановление доверия. По оценкам экспертов, эти затраты могли быть в 5-7 раз выше, чем стоимость превентивного тестирования и мер по предотвращению подобных инцидентов. Такие кейсы демонстрируют, что инвестиции в профилактику, безопасность и качественную подготовку инфраструктуры значительно экономят средства и помогают минимизировать репутационные риски.
Как наша команда QA в 3 раза ускорила работу с помощью собственного ИИ-агента
Наверняка всем тестировщикам знакома ситуация, когда остаётся всего пара дней до релиза, а команда тестирования всё ещё работает над задачами по новым фичам и не может приступать к регрессу? Или перед передачей новой версии заказчику тестировщики успевают проверить только smoke-сценарии, засиживаясь допоздна? А до написания чек-листов и тест-кейсов по новым функциям руки дойдут вообще не скоро. У нас тоже такое нет-нет, да и случается.
Самое первое, что приходит в голову после таких авралов – нам нужна автоматизация регресса. Но как в кратчайшие сроки сделать из ручных сценариев автотесты, если никто в команде тестирования не пишет код и нужно изучать всё с нуля, и это при том, что и так ни на что не хватает времени? На помощь придёт вездесущий AI!
Способы стабилизации автотестов на backend: опыт сервиса Звук
Привет, Хабр! Меня зовут Надежда Буртелова, я ведущая тестировщица в музыкальном сервисе Звук. В тестировании с 2014 года, с 2022 года работаю в Звуке: тестирую backend и менторю коллег. Последние два года активно пишу автотесты.
Закончила МФТИ: факультет аэрофизики и космических исследований.
В статье разберу причины нестабильности автотестов на бэкенде и предложу способы их стабилизации. Расскажу, как из одного «флакающего» теста сделать три стабильных, стоит ли автоматизировать изначально нестабильные сценарии и когда лучше что-то убрать из автотестов и сохранить адекватное покрытие.
Сколько трафика выдержит сайт на Next.js: нагрузочные тесты, SSR и предрендеринг
Команда JavaScript for Devs подготовила перевод статьи о том, сколько трафика реально выдерживает сайт на Next.js. Автор провёл нагрузочные тесты, сравнил VPS и выделенный сервер, проверил разницу между предрендерингом и SSR и сделал вывод: для сайтов с потенциальными всплесками трафика предрендеринг — спасение, а SSR может стать бутылочным горлышком.
Автоматизируем синхронизацию тест-кейсов в ТестОпс: больше никаких ручных обновлений
Сейчас работаю Head of QA в Альфа-Банке (Беларусь). За эти годы я успел поработать с десятками инструментов, написать сотни тест-кейсов и… потратить неприлично много времени на рутину, которую можно было автоматизировать ещё вчера.
Знаете, есть такая особенность нашей профессии — мы автоматизируем всё вокруг, но часто забываем автоматизировать собственную боль. Сегодня хочу поделиться решением одной из таких «болей», с которой сталкивается каждый QA-инженер, работающий с ТестОпс: необходимость вручную синхронизировать тест-кейсы после каждого прогона автотестов.
От запахов к стабильности: рефакторим тесты на JUnit + Selenide
Нам показалось интересным подойти к этой проблеме не со стороны теории, а со стороны практики: какие частые ошибки можно встретить в тестах, как их исправлять, и почему именно тесты нужно писать так, а не иначе? Мы продемонстрируем всё это для стека JUnit + Selenide.
Performance monitor и не только: продолжаем тестировать производительность в Chrome DevTools | Сбер
Привет! Продолжаем разбирать малоизвестные, но крайне полезные фичи Chrome DevTools. Материала набралось так много, что мне пришлось разбить его на две статьи. Сегодня мы поговорим об утилите Performance monitor, инструменте Chrome Task Manager и о том, как вывести FPS сайта на экран.
11 способов мышления тестировщика: как и зачем переключаться между подходами
Тестирование давно перестало быть «механическим прогоном чек-листов». Настоящая ценность работы тестировщика рождается в умении мыслить — критически, исследовательски, системно и иногда вопреки привычным схемам. В этой статье поговорим о том, какие типы мышления помогают находить ошибки и принимать верные решения, и как разнообразие «майндсетов» делает профессию не только глубже, но и гораздо полезнее для всей команды разработки. Статья будет полезна в первую очередь начинающим тестировщикам.
🔥Нашумевшее
Искра Жизни: как рождаются продукты

Каждый продукт с чего-то начинается. Иногда с бизнес-плана, иногда с ночного мозгового штурма, но чаще всего с разочарования, озарения, вызванного чем-то обычным, или обнаружения пустой рыночной ниши.
Мнение
Маленький кусочек рынка ИТ под названием «1С» меняется. Если верить публикациям на Хабре, большой рынок ИТ тоже куда-то поворачивает. Я и про рынок труда, и про рынок бизнеса.
Кто-то называет эти перемены кризисом, кто-то – возвращением в нормальное состояние. Вроде как предыдущие 2-3 года были ненормальными, ажиотажными, экстремумом. А то, что сейчас – это как было 2-3 года назад. Потому и не кризис. Скорее 2-3 года были кризисом, только с обратным знаком.
Не буду напяливать на себя костюм с маской эксперта по рынкам, анализировать причины, механику и последствия изменений. Я зашёл поговорить про то, что знаю. Точнее, про тех, кого знаю – про терпил.
Спецы. Это – последние терпилы в моём списке.
Для кого-то экстремум прошёл незаметно – некоторые спецы успели так или иначе огородиться от пассажиров, как от зомби. Либо персонально («идите вы все в задницу, я в вашем вертепе не участвую, буду работать один»), либо командой («нам пассажиров не надо, у нас будет маленькая хорошая команда, а если что-то не нравится – мы все уходим»).
Кому-то же отгородиться не удалось, и пришлось терпеть. Одни мучались в смешанных командах, описанных выше, в пункте про тимлидов. Брать на себя самое сложное, важное и ответственное (как говорил Джон Маклейн в Крепком Орешке 4.0, «просто больше некому»). Другие испытывали неловкость, слушая разговоры пассажиров, и не имея возможности сказать всё, что думают (нельзя, вы что, надо быть нетоксичным, конструктивным няшей).
Небольшому (надеюсь) количеству спецов пришлось терпеть упущенный доход. Зарплата спеца была выше зарплаты пассажира, но, как я писал выше, не в той же пропорции, что навыки и компетенции. Работодатель совсем не против бы платить спецу больше, но денег не хватало – пассажиров тоже кормить надо. А их, как вы поняли, достаточно много.
Сейчас у спецов жизнь должна немного наладиться. Пассажиров с поезда поснимают, но сумеют ли работодатели перераспределить ресурсы в сторону спецов – хороший вопрос. Можно ведь и зажать, под шумок. Тогда спецам, бывшим терпилам, придётся довольствоваться удовлетворённым чувством вселенской справедливости.
В последнее время идут баталии между сторонниками vibe‑кодинга (использование ИИ инструментов без понимания в коде) и сторонниками классического программирования. В зависимости от того к группе менеджеров или программистов относятся первые, их мотивация отличается, но она по сути про одно — менеджерам кажется, что наконец у них появился священный грааль с помощью которого они избавятся от зависимости в «зажравшихся» программистах, на любой проект можно будет посадить несколько человек с улицы. Главное, чтобы могли уметь писать или хотя бы голосом в микрофон излагать связанно мысли.
Тихий апокалипсис: я устал читать сгенерированные статьи
В последние 3-4 месяца, при поиске интересных статей на Хабр, очень часто замечаю полностью скопированные, не отредактированные статьи, которые генерирует ИИ. Появился некий «новый класс контента», ценность которого равна нулю. Честно, терпел долго, ждал изменений, но с каждым месяцем подобного становится всё больше. Пиком стали подобные «блоги компаний», где выходят статьи с аналогичными паттернами
Как я, не разработчик, читаю туториал, который ты, разработчик, написал для меня
код на Hoobijag, иногда на jabbernocks и, разумеется, на ABCDE++++ (но никогда — на ABCDE+/^+; вы что, шутите?); мне нравится работать с Shoobababoo и иногда с клептомитронами. Я устроился на работу в Компанию1 и занимаюсь там кодом для Shoobaboo, поэтому перешёл к использованию Snarfus.
Хватит писать «чистый» код. Пора писать понятный код
Да, это очередная статья по чистому коду. Но по разным источникам, соотношение времени, затрачиваемого на чтение и написание кода, может достигать 7 к 1 и даже больше. Когда вы исправляете ошибку, добавляете новую функциональность или проводите рефакторинг, вы сначала погружаетесь в логику, написанную другими людьми (или вами же, но несколько месяцев назад). Именно поэтому читаемость кода становится более важным фактором, чем скорость его первоначального написания. Нечитаемый код — это технический долг, который замедляет всю команду и увеличивает стоимость разработки в долгосрочной перспективе.
Однажды субботним вечером я, как полагается тру-программисту, пилила новую фичу в своем пет-проекте. И тут зазвонил телефон…
Ограничение контекстного окна GPT-5 и его эффективное использование в Bothub
Контекстное окно устанавливает верхний предел объема данных, которые модель способна обработать за один запрос или диалог. Оно измеряется в токенах — кусочках информации, на которые модель дробит наш текст. Этот параметр определяет возможности работы с крупными документами, сохранения истории разговора и выполнения многоэтапных задач.
Как владение кошкой влияет на мозг человека (и на мозг кошки)
Собаки, как стайные животные, одомашненные для постоянного общения с человеком, почти «запрограммированы» искать зрительный контакт, ласки и одобрение от нас — поведение, которое стимулирует выброс окситоцина у обеих сторон. Кошки, однако, произошли от более одиноких охотников, которым не нужны были явные социальные жесты для выживания. Поэтому они могут не демонстрировать поведение, подпитываемое окситоцином, с такой готовностью или последовательностью. Вместо этого кошки могут приберегать своё поведение, высвобождающее окситоцин, для тех моментов, когда они действительно чувствуют себя в безопасности.
Я сварил палки, выложил на Авито и заработал 10 млн за год
Большинство складов вдоль МКАДа построены не из кирпича и не из бетона.
Берут стальные трубы, сваривают каркас — делают металлоконструкцию. Устанавливают на фундамент, обшивают сэндвич-панелями — и склад готов.
👀Посмотреть
Исследовательский подход в мобильном тестировании ⏱️45 минут
Когда инженеры сталкиваются с исследовательским тестированием, возникает целый спектр вопросов. Какой подход подойдет для решения задачи? Какие инструменты использовать? А как фиксировать результат? В докладе Александр рассказал о полезных инструментах в области мобильного тестирования и о том, как их применять на практике. А еще рассмотрел подходы исследовательского тестирования и порассуждал на тему «Почему каждый тестировщик в душе исследователь».
Тестируем словами: автотест без кода в реальном времени ⏱️50 минут
Идея использовать естественный язык в автоматизации тестирования не нова. Многие помнят BDD и ту боль, что он принёс. Но технологии шагнули вперёд. Сегодня мы возвращаемся к этой мечте, только уже без кода, без локаторов, без инфраструктуры. В этом докладе мы вместе со зрителями напишем и запустим автотест на Vision Language модели: выберем сервис, опишем кейс обычным языком и посмотрим, как работает новый подход. Это не Gherkin и не step definitions — это живое тестирование на языке пользователя. И да, будет интерактив, холивар и ответы на острые вопросы.
Как Flakyzavr съел наши проблемы ⏱️35 минут
Расскажу про подходы и инструмент автоматизации который мы внедрили для снижения когнитивной нагрузки на дежурных, а также всех проблемах с которыми мы столкнулись при этом внедрении и что из этого получилось.
Архитектура LLM — BERT, трансформеры, attentions ⏱️1 час 30 минут
Берты, трансформеры, эмбеддинги, аттеншены, энкодеры с декодерами и другие страшные слова – все это разберем в выпуске с Владиславом Танковым, директором по AI в JetBrains, попутно разложив большие языковые модели на составные части.