Всем привет! Меня зовут Вадим, и я QA-инженер в IT-компании Intelsy. В динамичных проектах тест‑кейсы часто превращаются в «мёртвый груз»: они быстро теряют актуальность из‑за изменений в функционале, интерфейсе или бизнес‑логике. Результат — устаревшая документация, на поддержку которой тратится больше времени, чем на реальное тестирование. Разберём принципы и техники, позволяющие создавать долговечные тестовые артефакты.
Как тестируют железо на заводе, а как — в радиочастотном центре? Что общего у тестовых стендов двух крупных компаний? Что лучше: работать из дома или ездить в офис? Быть или не быть hardware-тестировщиком в новом году? На эти и другие экзистенциальные вопросы ответили инженеры YADRO, ИнфоТеКС и Яндекса. А мы собрали под катом записи докладов и дискуссии «QA в 2025: что сработало, а что — нет».
Привет всем! Меня зовут Аркадий Воронов, старший специалист по качеству. В команде у меня гибридная роль: ручной тестировщик и TestOps. О второй ветке моего развития расскажу подробнее.
В статье будут затронуты темы:
— контекст ИБ: что и зачем мы тестируем;
— основные боли и ограничения,
— инсталляционное и конфигурационное тестирование,
— матрица совместимости,
— инструменты, которые укрощают «зоопарк стендов»,
— путь развития TestOps.
Начало года — отличное время, чтобы заложить план развития скиллов и пересмотреть подход к обучению. В тестировании появляются новые инструменты, меняются процессы, растут требования к качеству. Именно поэтому важно иметь под рукой проверенные ресурсы, к которым можно возвращаться в любой момент.
Вместе со специалистами Selectel мы собрали полезные материалы для тестировщиков. В список вошли ресурсы, которые помогают развивать практические навыки, системное мышление и уверенно расти в профессии — от начального уровня до Middle.
В подборке собрано то, что действительно помогает в работе и может служить ориентиром для самостоятельного обучения. Подробности под катом!
Сразу вкратце отвечу на вопрос заголовка: выбрал Suno, поскольку ему уступают Udio, Tad и Yolly.
В этой статье поделюсь опытом написания музыкального альбома с помощью ИИ. Подспудно упомяну как можно больше интересных с моей точки зрения технических подробностей о процессе создания песен с 4-мя разными ИИ.
Вдохновившись мемом "Вася Тестировщик", я решил реализовать этот шутливый замысел мемодела: воплотить картинку в звук.
И сделал, бонусом узнав много интересного про ИИ-генераторы. Этим и поделюсь!
Всем привет! Меня зовут Марина, я QA в компании Банки.ру и сейчас занимаюсь продуктами личного кабинета, но успела поработать и в других командах.
В IT все по-разному представляют работу тестировщика:
– Кто-то видит человека, который по 8 часов кликает на кнопки (я, честно говоря, так же представляла разработку, что уж скрывать…).
– Кто-то – душного охотника на баги, который только и делает, что пытается что-нибудь сломать.
– Кто-то вообще считает, что это просто начальная ступень в IT, чтобы потом пойти в разработку.
И в каждом из этих представлений есть крупица правды – но только одна сотая. На самом деле тестирование – это куда более сложный и интересный мир. Это постоянный анализ, предугадывание проблем, переключение между разными типами задач и умение задавать возможно глупые, но нужные вопросы.
И в этой статье я расскажу об этом подробнее и покажу, что творится в голове QA, о чем мы думаем, когда видим задачу, и на чем фокусируемся.
Что делать, если сложная высоконагруженная система уже полностью покрыта базовыми тестами, используется фаззинг без модификаций, но выявить удалось не все критические уязвимости? Поможет внедрение генетического алгоритма.
Меня зовут Арина Волошина, я AppSec-инженер в YADRO и занимаюсь тестированием безопасности телеком-продуктов: базовой станции, контроллера базовых станций и системой управления элементами сети. Мы внедрили много разных видов тестирования в эти продукты, но этого оказалось недостаточно. В своих научных исследованиях я занималась генетическими алгоритмами, поэтому решила применить академические знания на практике и реализовать генетику в фаззинге. Что из этого вышло — читайте под катом.
Тестировщикам часто приходится работать в условиях, когда бэкенд ещё не готов, API нестабильно или внешние сервисы недоступны. В таких ситуациях тестирование либо откладывается, либо превращается в угадывание «на словах».
В этой статье я показываю, как тестировщик может самостоятельно поднять управляемый mock API без написания серверного кода и сделать его доступным из интернета.
Мы разберём связку Mockoon + ngrok:
— как создавать mock endpoints;
— как эмулировать 200 / 404 / 500 и другие ответы;
— как тестировать фронт и интеграции без реального бэкенда.
Статья ориентирована на QA-инженеров и подойдёт даже тем, кто никогда не писал backend.
Анализ 2500 QA-вакансий за год показывает, почему junior и manual-позиции почти не формируют спрос и на кого рынок QA реально ориентирован в 2026 году.
Сейчас на позициях любых грейдов, включая лидовские, у QA всё чаще работодатели требуют навыки разработки. Иногда это нужно, потому что позиция full-stack. Иногда это просто требование, чтобы отобрать технически подкованных ребят.
Я — Женя, QA-лид. У меня 6 лет опыта в профессии, в том числе 3 года я нанимаю и обучаю команду. Решил составить свой список того, что нужно делать QA, чтобы подготовиться к этапу технического собеседования с лайв-кодингом.
Это было интересное приключение.
Сразу оговорюсь: FlexMock не нужен всем подряд. Он вырос из моих собственных задач — когда нужно откуда-то получать разнообразные данные для собеседований, когда фронтенд уже в работе, а бэкенд ещё не готов, или когда нужно быстро собрать демо/прототип и не тратить вечер на мок-сервер.
Это мой первый публичный проект в формате “сделал сам и показываю миру”, без команды и заказа. Ниже расскажу, почему мне захотелось написать такой сервис, как он устроен на уровне идеи и в каких сценариях реально экономит время.
Буду благодарен за конструктивную критику — особенно за идеи, которые помогут сделать инструмент полезнее.
Автоматизированное тестирование API часто начинается с простых решений в виде коллекций Postman или скриптов на коленке. Такой подход работает на старте, но быстро исчерпывает себя.
Создание собственного проектного фреймворка является осознанным переходом от хаотичной, фрагментарной автоматизации к устойчивой, гибкой предсказуемой и масштабируемой системе тестирования. Такой фреймворк дает полный контроль над архитектурой, обеспечивает строгую валидацию контрактов API, безопасную работу с базой данных, генерацию осмысленных тестовых данных и простую интеграцию в инфраструктуру разработки.
Статья поделена на три части.
В первой части дается обоснование преимуществ создания полноценного проектного фреймворка по сравнению с использованием готовых универсальных инструментов по типу Postman. Вы узнаете, какие принципы легли в основу архитектуры фреймворка и какой был подобран технологический стек для их реализации на практике.
Статья техническая и адресована инженерам-программистам в тестировании (SDET) и инженерам по автоматизации тестирования, которые перешли от написания обособленных тестов к осознанному проектированию тестового фреймворка или только начинают этот переход.
Flaky-тесты — это вполне измеряемая форма недетерминизма, вокруг которой в исследованиях накопился свой язык. В разных статьях одни и те же слова могут означать чуть разное: где-то считают переходы pass↔fail, где-то смотрят на энтропию истории прогонов, где-то обсуждают карантин и компромисс FR против LFD. В этой статье — короткий словарь самых ходовых терминов, чтобы говорить о нестабильности тестов точным языком.
Юнит-тесты дают чувство контроля — ровно до первого странного падения «только у одного клиента», под нагрузкой, на другой версии ядра, с неожиданными сетевыми ретраями и капризами аллокатора. В Quasar, распределённой системе хранения данных в реальном времени, эту реальность приняли как исходную: предугадать всё невозможно, поэтому уверенность строится не на одном виде тестов и не на «серебряных пулях», а на процессе, который ловит ошибки как можно раньше и системно закрывает зоны риска.
В крупных проектах управлять качеством вручную — весьма нетривиальная задача: объем требований и фичей, уточнений и доработок, баков и фиксов растет нелинейно, а риски — экспоненциально. В таких условиях необходимо структурировать процесс обеспечения качества (QA), чтобы предотвратить эффект «снежного кома», который может «завалить» тестировщиков — сначала фрустрацией от рутины, а потом недовольством заказчика.
Когда я работала техническим писателем в международной команде, bug reports частенько попадались мне на глаза. И довольно быстро стало понятно: 90% багов написаны одними и теми же конструкциями, просто в разном порядке. Ниже - концентрат того, что часто используется в bug reports на английском. Сохраняйте.
Меня зовут Артём Дружляков, я техлид QA в направлении кредитования. Сегодня я хочу рассказать о проекте, который мы реализовали в направлении тестирования микросервисов в Альфа-Банке, — о разделении автотестов по микросервисам.
Раньше все автотесты жили в одном огромном репозитории — больше 550 микросервисов в одном месте. Из-за этого сборки шли долго, проект был нестабилен, любое изменение в общем файле могло сломать часть тестов или запуски всех, а новичкам было сложно разобраться в громоздкой архитектуре.
Чтобы решить эти проблемы, команда перешла на микросервисный формат. Теперь автотесты на каждый микросервис хранятся в отдельном репозитории, который создаётся автоматически с помощью шаблонизатора и уже содержит все необходимые файлы. Можно использовать генерацию по спецификации OpenAPI, а общие решения вынесены в отдельные библиотеки, покрытые юнит-тестами и подключаемые при необходимости.
Axiom — это недостающий тестовый runtime для Go, который добавляет фикстуры, шаги, хуки, retry, плагины, метаданные и структурированное выполнение поверх стандартного testing, оставаясь полностью совместимым с ним. Минимум магии, максимум инфраструктуры.
За последние годы я получил 9 сертификатов ISTQB.
И если бы в начале пути я знал, сколько денег можно сэкономить, я бы точно принимал другие решения.
Почти все экзамены я сдавал через GASQ из Беларуси — выходило 140–150 евро за экзамен, что уже было дешевле, чем стандартные европейские цены. Но, как оказалось позже, это далеко не минимум.
И вот что интересно: если бы я заранее знал, какие способы экономии реально существуют, я бы точно пересмотрел стратегию сдачи экзаменов и сэкономил бы несколько сотен евро.
В этой статье я собрал все рабочие способы сэкономить на ISTQB, от полностью легальных до пограничных (с честным описанием рисков).
Привет! Меня зовут Артем Русов. Я тестировщик, который любит разрабатывать разные полезные вещи для других тестировщиков.
Каждый год я создаю бесплатный адвент-календарь для QA, содержащий в себе полезные ссылки, материалы, тренажеры, интерактивные игры, связанные с тестированием, от разных авторов.
Решил, что хочу поделиться им с вами. Каждый день в этот пост буду добавлять новую ссылку из него.
Все материалы в подборке бесплатные, без подвоха и помогают в формировании определенных навыков, смежных с работой тестировщика.
