В Go нет фикстур, и в интеграционных тестах это быстро превращается в копипаст. Разбираем, как вынести инфраструктуру из автотестов и управлять жизненным циклом ресурсов.
Ранее в статье: Soft Skills для тестировщика: почему «мягкие» навыки важнее «жестких» скриптов я попытался рассказать почему для тестировщика важно развивать Soft Skills, а сейчас разберемся как это реализовать на практике.
Развитие мягких навыков — не разовая акция, а постоянный процесс. Поскольку я работаю QA‑инженером, то данный материал в большей степени будет полезен для QA, но и разработчики и менеджеры и другие участники команды могут найти для себя что-то полезное. Ниже я привел конкретные, проверяемые методы для прокачки ключевых soft skills.
Купили Copilot, раздали команде, через квартал смотрите на цифры — и не понимаете, это AI помог или команда сама выросла. Знакомо?
Мы внедрили AI в разработку 35 инженеров и измерили, что реально изменилось. Не acceptance rate — он врет без baseline. Не DORA в лоб — она не видит разницу между мелкими деплоями и сложными задачами. А метрики, которые честно показывают эффект: откуда брать данные, как избежать игры с цифрами, и почему субъективное ощущение +20% от AI оказалось −19% объективно.
Практический гайд с реальными цифрами, таблицей контрметрик и чеклистом для внедрения.
Многие команды сейчас экспериментируют с ИИ. Ставят ИИ-инструменты и удивляются как резво растёт кодовая база. Но счастье длится недолго. Очень быстро выясняется что количество багов растёт с той же, а порой и опережающей скоростью. А аудиты, хоть ИИ и сделал их доступнее, раздувают бэклог на недели вперёд.
Типичная история 2026 года. ИИ-революция случилась быстрее, чем мы осознали что произошло и что с этим делать. А главное, как выстраивать процессы разработки по-новому, чтобы удержать этот код от взрыва в продакшене.
Когда люди говорят “я отправил 80 откликов и мне никто не ответил”, проблема часто заключается не в рынке а в подходе к поиску.
На входе у тебя ATS. Потом кривое резюме. Потом вакансия, под которую человек подходит только наполовину, но всё равно откликается. Потом ещё один сайт, ещё один фильтр, ещё один PDF, который улетает в пустоту. И уже после этого человек делает вывод, что рынок сломан.
Мы как разработчики talanto.work как раз и начали копать отсюда. Не с красивой идеи “сделаем ещё один job board”. А с более простой: поиск работы в IT слишком часто ломается ещё до первого интервью. На уровне упаковки кандидата, на уровне совпадения с вакансией.
"Скоро сказка сказывается, да не скоро дело делается" - говорится в народной пословице. Вот и мы решили не спешить со второй частью статьи по Junit 5 Extensions, а подойти к ней более основательно! Статья будет полезна QA-автоматизаторам, которые хотят глубже понимать работу с расширениями и выжать чуть больше из связки Kotlin + Junit5. Мы пройдем путь от простой реализации condition-выполнения тестов и источников данных для параметризованных тестов до реализации расширения Микро-DI с рекурсивной инъекцией зависимостей.
Как и в прошлой статье, сделаем акцент на практической части реализации расширений для JUnit 5. В качестве языка - Kotlin. Поэтому, достаем бутерброды, наливаем пиво кофе и приступаем!
Ваш тест на оформление заказа нажимает «Оформить заказ» и видит зелёный тост. Хорошо. Но вот чего он не проверяет: реально ли записалась строка? Правильно ли записались позиции заказа? Уменьшился ли инвентарь? UI написал «подтверждено», но UI иногда врёт — проглоченная ошибка, откаченная транзакция, очередь, которая молча дропнула сообщение.
Классическое решение некрасиво: нужно подключить ORM или низкоуровневый драйвер базы данных внутри тестового харнеса, управлять отдельными учётными данными, писать SQL-ассерты вручную и надеяться, что схема не изменится. Работает. Но это накладные расходы на поддержку, которые вы платите за каждый тест.
Сейчас есть паттерн лучше. И в нём ноль SQL с вашей стороны.
Что если один AI-агент сможет делать обе половины — управлять браузером при оформлении заказа и затем переключиться в базу данных для проверки записи — используя два MCP-сервера?
Именно это разбирается в статье:
Всем привет! Меня зовут Оля Ермолаева, я работаю в сфере обеспечения качества ПО уже больше 17 лет. За это время я успела поработать в самых разнообразных компаниях по очень разным направлениям: от ПО для автозаправок до финтеха, агротеха и ритейла. Пробовала себя и в ручном, и в автоматизированном тестировании. В итоге лет 10 назад ушла с головой в менеджмент и веду свой небольшой ТГ канал про тестирование, менеджмент и всё, что с этим связано.
В начале этого года мы с коллегами зацепились языками по вопросу соотношения тестировщиков и разработчиков в командах разработки в зависимости от разных факторов и мне стало интересно, а как вообще на рынке с этим сейчас обстоят дела. Устроив опрос по разным чатам и сообществам, я готова поделиться с вами этой информацией, погнали!
Привет, Хабр! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. В предыдущих статьях я рассказывал про QA Assist — AI-ассистента для тестирования. Сейчас идёт пилот на реальном проекте, копятся метрики и грабли — но писать об этом пока рано. Результаты будут, а пока давайте поговорим о чём-то другом.
Однажды друг в шутку спросил: «А тестировщики вообще могут верить в Бога? Это же не совместимо, нет?»
Вопрос оказался глубже, чем кажется. Не потому что я хочу обсудить религию на техническом ресурсе (спокойно, не буду). А потому что ответ на него выводит на кое-что полезное: неявные допущения, на которых стоит наша работа, и которые мы почти никогда не ставим под сомнение.
Эта статья — про границы знания в тестировании: что мы на самом деле знаем, что принимаем на веру, а что — на доверие. И почему разница между этими понятиями важнее, чем кажется.
Инжиниринг качества (Quality Engineering) — это современный подход к созданию надёжных и востребованных продуктов, основанный на проактивных методах, автоматизации и анализе метрик. Он помогает компаниям предотвращать ошибки на ранних этапах и обеспечивать высокий уровень качества на всём жизненном цикле разработки.
Сейчас TMS на рынке условно можно разделить на два подхода.
Первый — классический. Система работает как слой управления ручным тестированием: хранит тест-кейсы, формирует прогоны, фиксирует статусы и результаты. Вся логика выполнения при этом остается за пределами TMS.
Второй — с поддержкой автотестов. Здесь появляются интеграции с CI: система умеет связывать автотесты с тест-кейсами, подтягивать результаты запусков, отображать историю и статусы. Иногда добавляется возможность инициировать запуск, но фактическое выполнение и управление пайплайнами по-прежнему остаются в CI.
В новом релизе DoQA 4.0 как раз добавили сценарий с запуском автотестов прямо внутри TMS. Давайте разберем, как это ребята реализовали.
Playwright 1.59 — не очередное инкрементальное обновление. Это заявка на то, куда движется автоматизация тестирования, и это направление глубоко агентное. Если вы ждали, когда инструменты догонят AI-driven воркфлоу, о которых все говорят, этот релиз закрывает разрыв.
Разберём каждую крупную фичу и, что важнее, как каждую из них можно применить немедленно.
Долгое время своей уютной компанией сидели на телеграме. Клиенты, заказчики, лёгкие боты для уведомлений, беседы отделов и прочие прелести всем известного мессенджера. В этой статье поделюсь недостатками, которые мешают нормальному переходу тысяч людей на отечественный MAX (по крайней мере в качестве рабочего мессенджера).
Важная оговорка. Я работаю в малом бизнесе. Тратить лишние несколько тысяч рублей на битрикс или другие аналоги можно, но не хочется. К тому же телеграм закрывал все возникающие вопросы и проблемы. Если уж тысячи людей оставили без выбора, отечественный аналог может просто скопировать функционал телеграма, проверенный годами работы. К сожалению, МАХ является лишь копией ICQ NEW (в последствии VK Teams), застрявших в 2016 году. Некое понятие о работе кода я имею, но программистом не являюсь. Поэтому ниже пойдёт чистый "пользовательский" опыт.
И введём термина Б50 - бухгалтер пятидесяти лет. Вообразите себе обычную трудягу, которой поставили приложение МАХ. Она им пользуется каждый день, не разбирается ни в коде, ни в костылях, ни в банальных вещах по типу "перенесите иконку на панель задач". Под этот термин попадают и узкопрофильные специалисты - в трафаретной печати или деколи они просто асы. Но когда дело доходит до компухтеров - они предпочитают позвать сисадмина или любого молодого человека, по возрасту своему умеющего разбираться с технологиями.
Привет, Хабр!
На связи Олег Уланов (aka brain), багхантер и ведущий подкаста «Начинаем в багбаунти». Кстати, по итогам 2025 года стал топ-1 площадки Standoff Bug Bounty.
Этот материал мы подготовили вместе с Дмитрием Прохоровым, пентестером из PT SWARM (в мире багхантинга Дима известен как ratel_xx).
В статье речь пойдёт о поиске уязвимостей через загрузку файлов. Вы узнаете, как устроен механизм multipart/form-data, какие защитные механизмы ставят разработчики и как их обходить. Я покажу на практике, что можно сделать с расширениями файлов, Content-Type, magic bytes, а заодно затрону эксплойты типа race condition, zip-слайп и нестандартные векторы вроде загрузки .htaccess. Статья подойдёт для начинающих багхантеров, поэтому даже если у вас мало опыта смело заглядывайте под кат!
В мире микросервисов и сложной продуктовой логики наступает момент, когда классические E2E-тесты превращаются в проблему. Количество пользовательских сценариев исчисляется сотнями, каждый новый конфиг требует десятков тестов, а регресс вместо быстрой проверки становится многочасовым процессом.
Но если сценарий становится нелинейным (появляются развилки, выбор пользователя ведёт на разные экраны) всё усложняется. С этим E2E-тесты ещё справляются: пишем несколько тестов, каждый под свой путь. Сложнее, но решаемо.
Мы столкнулись с этим при работе с платформой в Услугах Авито: пользователь заполняет форму заявки, переходя между экранами. Логика переходов между экранами зависела от категории услуги, типа экрана и выбранных опций. Сценариев стало попросту слишком много. Пришлось искать другой путь.
Меня зовут Константин Горностаев, QA в Авито, в этой статье я расскажу о подходе, который позволил нам решить эту задачу и получил название «система фейков».
Смена технологической области кажется рискованным шагом: новые термины, другая инженерная культура и ощущение, что придется начинать почти заново. Но на практике переход может оказаться гораздо более плавным.
Меня зовут Любовь Молчева, я руководитель группы unit-верификации дивизиона разработки полупроводниковых продуктов YADRO. До этого вся моя карьера была связана с программной разработкой и тестированием. Перейдя в верификацию полупроводников, я обнаружила, что многие управленческие и инженерные навыки остаются нужными, а требования новой роли во многом совпадают с уже накопленным опытом. В этой статье разберу, какие навыки из software оказываются полезны в hardware, с какими сложностями сталкиваешься в первые месяцы и как выстроить погружение в новую область без ощущения, что начинаешь карьеру с нуля.
Разбираю как выглядит нормальный QA-пайплайн в GitHub Actions: от линтинга до E2E тестов на Playwright. С рабочими конфигами, кэшированием и уведомлениями о падениях.
Мы привыкли винить LLM‑агентов в галлюцинациях, бесконечных циклах и слитых бюджетах на API. Но что, если проблема в инфраструктуре, которую мы им скармливаем? Я написал детерминированный CI‑сканер для оценки качества MCP‑серверов и прогнал через него 30 публичных пакетов. Результат оказался интересным: почти половина серверов убивает агента ещё до старта, а официальные инструменты дают ИИ гранату в руки. Под катом - хардкорный разбор костылей экосистемы, графики и Open Source инструмент, который защитит ваш продакшен.
Как тестировать систему, если половина её компонентов — это «чёрные ящики» с уникальными протоколами, а стандартные API-mocks не справляются? С точки зрения готовых решений — тупик…
Меня зовут Дмитрий, я AQA-инженер в ИнфоТеКС. Мы с командой столкнулись с этой проблемой и создали собственные API-mocks, которые не просто отвечают шаблонными сообщениями, а ведут себя как настоящие компоненты системы. В этой статье — наш путь от идеи до работающего решения, которое можно адаптировать под ваши задачи.
Привет, Habr.
Обычно найм представляют довольно просто: есть вакансия, есть кандидат, есть несколько этапов собеседования, после которых человек либо получает оффер, либо отказ. Такая картина хорошо смотрится в HR-отчётах и презентациях, но в реальности всё устроено заметно сложнее.
Если чуть дольше повариться в рынке, становится видно, что вокруг собеседований уже давно существует отдельная инфраструктура. Речь про слитые вопросы, базы по компаниям, закрытые чаты, документы и каналы, где собирают и передают друг другу реальные этапы найма. Причём это уже давно не история про редкие “утечки” или единичные случаи. Для части рынка это вполне рабочий инструмент подготовки.
Сразу уточню важный момент. Эта статья не про мораль, не про публичные разоблачения и не про попытку назначить кого-то злодеем.
Мне интереснее разобрать само явление: почему рынок слитых собеседований вообще появился, как он работает и почему стандартные процессы найма сами неплохо помогают ему жить.
Потому что проблема тут не только в кандидатах, которые хотят пройти собес по короткому пути. Проблема ещё и в том, что многие компании годами проводят одни и те же интервью почти в одном и том же виде, а значит рано или поздно этот процесс начинает жить своей отдельной жизнью.
