Тестирование

Как мы научили AI разбирать упавшие автотесты и заводить баги в Трекере

barancev@gmail.com (Administrator) — Tue, 04 Aug 2026 20:00:00 +0000

Автор: Олег Малышев, телеграмм-канал автора про QA,QA Auto, AI, Вайбкодинг лидер стека тестирования в компании «ТехВилл»

Всем привет, меня зовут Олег. В прошлой статье я рассказывал, как генерить автотесты из Swagger и тест-кейсов при помощи OpenAPI Generator + Cursor AI / Claude Code и как с этого всего автоматически снимать покрытие через Swagger Coverage.

В этой статье я хочу рассказать, как мы разбираем упавшие автотесты при помощи интеграции ТестОпс с Яндекс Трекером, MCP TestOps, MCP Яндекс Трекера и Cursor AI / Claude Code.

Но начнем не с AI. Сначала расскажу про сам процесс: зачем нам дефекты в TestOps, как мы руками разбираем запуск автотестов, почему без matcher-правил это быстро превращается в рутину и что именно мы потом автоматизировали.

Типы границ для классов эквивалентности

barancev@gmail.com (Administrator) — Tue, 14 Jul 2026 20:00:00 +0000

Автор: Ольга Назина (Киселёва), автор курса Школа для начинающих тестировщиков

Про типы границ я впервые услышала на тренинге Алексея Баранцева. Зачем они нужны? Да просто чтобы не забыть всё проверить. Написал чек-лист, потом проверяешь себя:

— Все учел? Вот эти классы эквивалентности, какие границы логические? А какие технологические? ...

Так можно вспомнить о проверке, про которую забыл или просто не подумал! Полезная штука.

Алексей дал нам тогда про такую типизацию границ:

Физическая — которую физически нельзя преодолеть.
Логическая — ограничение, накладываемое логикой, не программой.
Технологическая — ограничение, накладываемое используемой технологией.
Произвольная — ограничение, наложенное аналитиком или заказчиком.

5 промтов, которые сэкономили мне часы рутинной работы тестировщика

barancev@gmail.com (Administrator) — Wed, 08 Jul 2026 20:00:00 +0000

Автор: Екатерина Гаврилова (QA Tech Lead в MD Audit)

Сегодня бы не будем говорить о банальностях типа чек-листов и тест кейсах. Эта база, я о ней уже писала коротко и даже длинно. Речь пойдет именно о тех интересных вариациях использования нейросети, которые я не видела или не нашла.

Заранее находим, что тестировать: модель ревью требований

barancev@gmail.com (Administrator) — Mon, 06 Jul 2026 20:00:00 +0000

Автор: Ханиша Арора (Hanisha Arora)
Оригинал статьи
Перевод: Ольга Алифанова

Тестирование программного обеспечения — это не только поиск багов, но и их предотвращение. Случалось ли вам смотреть на требование и думать: «вроде всё нормально»? А затем, спустя несколько недель, наблюдать, как код по этому требованию превращается в баг-репорт, часы доработок или недовольство стейкхолдера? Это знакомо не только вам.

Именно поэтому была создана модель ревью требований (Requirements Review Model, RRM): чтобы дать тестировщикам и командам простой и единый подход к ревью. Это помогает повышать качество ещё до того, как написана хоть одна строка кода.

Модель была создана для сертификата Software Testing Essentials от Ministry of Testing (MoT), чтобы обучать тестировщиков-новичков ревью требований. В MoT решили, что будет полезно поделиться моделью со всеми, за пределами сертификата, и поддержать тестировщиков и их команды. Это соответствует их цели — развивать индустрию любыми позитивными способами. Поэтому и написана эта статья!

Как мы написали UI-тесты для ИИ-агента внутри JetBrains IDE

barancev@gmail.com (Administrator) — Tue, 30 Jun 2026 20:00:00 +0000

Оригинальная публикация
Автор: Nikolay Nedoseykin

Как проверить, что ИИ-агент в IDE работает, если на одинаковые запросы LLM отвечает по-разному? Ответы модели недетерминированы, а интерфейс и бизнес-логика вполне детерминированы, и их нужно тестировать отдельно.

Мы делаем ИИ-агента, встраиваемого в JetBrains IDE. В статье расскажу, как мы выстроили UI-автоматизацию плагина так, чтобы тесты ловили регрессии в интерфейсе, бизнес-логике и при этом не «моргали» из-за нестабильности LLM.

Статья пригодится, если вы QA-инженер или разработчик и вам интересны:
Выстраивание UI-автоматизации на примере IDE-плагина
Тестирование приложений с ИИ-функциями
Разделение ответственности между детерминированной и недетерминированной частями системы

Психология тестировщика: почему критическое мышление — это суперсила

barancev@gmail.com (Administrator) — Tue, 23 Jun 2026 20:00:00 +0000

Оригинальная публикация

Меня зовут Галина Коньшина, я работаю QA-инженером в Ozon Tech. Если вы думаете, что тестировщики только ищут баги, то вы заблуждаетесь. Мы не просто охотники за дефектами (хотя баги ловить умеем), мы те, кто ежедневно выходит на поле боя против самого изощрённого противника — нашего собственного мозга.

Вы обращали внимание на то, как легко не заметить очевидное? Например, когда вы ищете очки, а они у вас на голове. Теперь представьте, что тестировщик делает это на уровне сложных систем и интерфейсов, где каждая «потерянная пара очков» может обернуться тысячами разъярённых пользователей.

Сегодня хочу рассказать, почему критическое мышление — это суперсила любого тестировщика, ссылаясь на теории классиков, таких как Майерс Г. и Кейнер К. Мы разберём, как когнитивные искажения могут мешать находить баги, что помогает развивать аналитический подход и как нестандартное мышление спасает проекты (и иногда ночной сон).

Как начать тестировать внутренние покупки (In-App Purchases) на Android

barancev@gmail.com (Administrator) — Sun, 14 Jun 2026 20:00:00 +0000

Автор: Павлович Евгений

Эта статья основана на моем опыте и, надеюсь, поможет быстрее стартовать коллегам в ручном тестировании внутренних покупок в Android-приложениях. Это не исчерпывающее руководство, просто хочется дать стартовые инструкции, чтобы можно было увереннее начать.

IAP - важный элемент монетизации мобильных приложений. К примеру, частый сценарий, предложение подписки через paywall. Корректная работа этого механизма критична как для бизнеса, так и для пользовательского опыта.

Как мы выстроили процесс нагрузочного тестирования в KISLOROD

barancev@gmail.com (Administrator) — Tue, 24 Feb 2026 20:00:00 +0000

Меня зовут Эдуард, я руковожу отделом DevOps в компании KISLOROD. В этой статье расскажу про подход к нагрузочному тестированию, который сформировался у нас. Мы постоянно дорабатываем процессы, поэтому буду рад конструктивным комментариям и обмену опытом.

Зачем вообще нужно нагрузочное тестирование

Нагрузочное тестирование — это способ проверить, как система ведет себя при росте числа пользователей и соответствует ли ее поведение ожиданиям. По сути, это имитация реальной активности: пользователи заходят на сайт, просматривают страницы, добавляют товары в корзину, оформляют заказы.

Какую информацию можно включать в базу знаний тестировщиков, чтобы это было полезно

barancev@gmail.com (Administrator) — Wed, 21 Jan 2026 20:00:00 +0000

Оригинальная публикация

За 8+ лет работы в тестировании я сталкивалась с разными подходами ведения базы знаний для тестировщиков на проектах. Где-то на проектах статей в базе знаний было так много, что глаза разбегались от количества информации, которую нужно было изучить на входе в проект. Но чаще попадались проекты, где базу знаний вели редкими набросками или не вели совсем. И это вызывало чувство безысходности в первые месяцы работы на проекте, так как информацию приходилось собирать буквально по крупинкам и не один месяц.

В этой статье я хочу поделиться списком возможных тем для статей, которые могут быть полезными для наполнения базы знаний тестировщиков на проекте. И лучше всего такие документы начинать собирать как можно раньше, так как вся информация имеет свойство быстро забываться/теряться и потом ее собрать бывает нелегко.

Такую документацию можно использовать не только для отдела тестирования, а также расшаривать и для других людей в компании по надобности, например, команде поддержки. Также отдельные статьи могут быть полезны и для разработчиков, тех.писателей, аналитиков и др. участников команд.

Как мы научились эффективно работать с техническим долгом

barancev@gmail.com (Administrator) — Tue, 14 Oct 2025 20:00:00 +0000

Оригинальная публикация

Меня зовут Эдвард. В сфере обеспечения качества я с 2012 года. Последние 7 лет работаю в Т-Банке, начинал со старшего специалиста по тестированию бэкэнда и работал в Т-Инвестициях. А сейчас занимаю позицию QA Head управления разработки социальных платформ.

Расскажу о том, как мы формировали подход по работе с техническим долгом, зачатки которого в нашей компании стали появляться еще в 2022. Также, покажу примеры визуализации метрик по техническому долгу в разрезе причин его возникновения и оставлю рекомендации по устранению каждой из причин формирования технического долга.

QA за пределами тестирования: надежность через учебные сбои

barancev@gmail.com (Administrator) — Wed, 17 Sep 2025 20:00:00 +0000

Оригинальная публикация

Привет! Я Леша Севальников, старший QA-инженер в команде, которая занимается разработкой бэкенд-сервисов для хранения, предоставления и актуализации данных о юридических лицах.

Почти пять лет работаю в Т-Банке, где с нуля организовал тестирование в своей команде. За это время я успел пройти путь от ручного до автоматизированного тестирования, встроить и автоматизировать нагрузочное тестирование и многое другое.

В какой-то момент все эти активности стали работать как единый механизм в текущих процессах, и мы задумались над следующим шагом для развития зрелости команды — повышение надежности. Расскажу о практике, которая поможет повысить надежность систем и команд.

Изучай и властвуй: как с помощью одного UX-исследователя, этнографии и тестов мы разработали систему управления складами

barancev@gmail.com (Administrator) — Sun, 10 Aug 2025 20:00:00 +0000

Оригинальная публикация

Меня зовут Саша – я ведущий исследователь пользовательского опыта в операционных продуктах ecom.tech, @ecom_tech_channel). На наших технологиях работают Самокат и Мегамаркет. В этой статье расскажу, как я оказалась на огромных складах и как мои исследования помогли разработать собственную систему управления складами. Внутри вас ждёт этнография, много тестирования и живые фото. Поехали!

Как писать баг-репорты, которые помогут всей команде

barancev@gmail.com (Administrator) — Tue, 27 May 2025 20:00:00 +0000

Автор: Михаил, специалист по тестированию в компании ITFB Group

Работа тестировщика состоит из множества различных задач, но самые важные — это обнаружение и описание багов. Однако сам процесс выявления ошибки — лишь половина дела. Настоящая ценность для команды разработки заключается в грамотном документировании найденного бага, а именно — в создании баг-репорта.

Написание баг-репорта может показаться простой задачей, однако чтобы он действительно был полезным и помогал разработчикам быстро разобраться в проблеме, важно учесть множество нюансов. Хорошо составленный баг-репорт не только описывает саму ошибку, но и содержит всю необходимую информацию для её воспроизведения, анализа и последующего исправления. Этот навык требует определённых знаний, внимания к деталям и опыта.

Локализация дефектов как прохождение лабиринта

barancev@gmail.com (Administrator) — Wed, 08 Jan 2025 20:00:00 +0000

Автор: Ekaterina Noga, оригинальная публикация

Одной из основных частей работы QA является локализация дефектов.

Техники тест дизайна помогают нам выбрать сценарии тестирования делая его эффективнее. Но что такое локализация дефекта и что может с этим помочь?

Начнем с начала.

Локализация это поиск ответа на вопрос «в какой момент и где что‑то пошло не так?». Без правильной локализации дефект может передаваться как между фронтендом и бэкендом, так и между командами разработки. При этом теряется время на исправление и, возможно, контекст.

Процесс локализации дефекта можно сравнить с прохождением лабиринта, а запросы и логи приложения с клубком нитей. Но намного удобнее было бы бродить по лабиринту имея в руках, не только клубок нитей, но и карту лабиринта, хотя бы примерную. Роль такой карты может сыграть архитектура приложения.

Логи, мониторинг и предупреждения

barancev@gmail.com (Administrator) — Thu, 24 Oct 2019 20:00:00 +0000

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

На этой неделе я расскажу о трех вещах, которые нечасто ассоциируются с тестированием: это логирование, мониторинг и предупреждения. Возможно, вы пользуетесь логами, тестируя, однако мониторинг и предупреждения – проблемная область в IT и DevOps. Но ведь приложение без багов не стоит ничего, если ваши пользователи не могут до него добраться, потому что сервер упал! Поэтому очень важно разбираться в логировании, мониторинге и предупреждениях, чтобы мы, как тестировщики, могли участвовать в обеспечении качества наших приложений.

Программная инженерия и управление жизненным циклом

barancev@gmail.com (Administrator) — Sat, 11 Oct 2008 07:11:12 +0000

Главы из книги Сергея Орлика и Юрия Булуя «Введение в программную инженерию и управление жизненным циклом» (базируется на SWEBOK).

От автора: о чем эта книга

В течение десяти лет работы в Borland мне постоянно приходится обсуждать с менеджерами, аналитиками, архитекторами и разработчиками вопросы применимости тех или иных продуктов, технологий, проектных решений. Последнее время, все чаще темой дискуссий становится процесс разработки программного обеспечения, как таковой, вопросы организации проектных команд, адаптации стандартов и подходов в управлении жизненным циклом ПО к сложившейся культуре разработки, и наоборот, трансформации существующей культуры и ценностей в новое качество. Приходится вспоминать и кое-что из опыта «прошлой жизни», когда я сам выступал в роли корпоративного разработчика и лидера проектной команды. Приходиться применять и уже более «свежий» опыт разработки рекомендаций по процессу разработки и внедрению технологий управления и поддержки жизненного цикла разработки приложений. И самому приходиться постоянно совершенствоваться, в том числе помогая другим.

Для кого эта книга

Для всех, кто связан с индустрией информационных технологий. Только не подумайте, что речь идет только о разработчиках и менеджерах проектов в области программного обеспечения. Конечно, нет. Ведь если в вашей деятельности программные системы играют серьезную роль в качестве повседневного и необходимого инструмента обеспечения вашей профессиональной деятельности, вы, наверняка, сталкиваетесь с вопросами взаимодействия с ИТ-специалистами. Вам, как пользователям и заказчикам просто необходимо иногда вникать в проблематику разработки программного обеспечения, если, конечно, вы хотите получить результат. Вы, кто создает (в общем смысле этого понятия, ни в коем случае не ограничиваясь только вопросами кодирования), поддерживает и развивает программное обеспечение, наверняка, найдете нечто новое в этой книге. Вы школьник или студент — вы учитесь. Не останавливайтесь. Эта книга и для вас. Хотя бы потому что это еще одна точка зрения. А две головы, иногда, лучше, чем одна. Так что, книга, как это принято иногда говорить — «для широкого круга читателей», для кого использование компьютера в повседневной работе не является абстракций, но полнофункциональным инструментом.

Как мы превратили Swagger из документации в двигатель API-автотестов

barancev@gmail.com (Administrator) — Tue, 21 Jul 2026 20:00:00 +0000

Мы продолжаем разговор о том, как применять ИИ в тестировании. В этой статье расскажу, как мы пишем API-автотесты с помощью OpenAPI Generator, Cursor/Claude Code и автоматически считаем покрытие по Swagger через swagger-coverage.

Раньше я уже записывал большое двухчасовое видео по Cursor, где показывал в том числе, как мы генерируем автотесты. Но с тех пор подход немного изменился: мы сильнее завязались на OpenAPI-контракт, добавили Swagger Coverage, JSON-отчёты для LLM и специальные skills для генерации недостающих тестов.

Как тестировщику участвовать в open-source проектах

barancev@gmail.com (Administrator) — Sun, 19 Jul 2026 20:00:00 +0000

Автор: Има-Абаши Эффионг (Ima-Abasi Effiong)
Оригинал статьи
Перевод: Ольга Алифанова

Почему тестировщикам важно участвовать в проектах с открытым исходным кодом (OSS)

Участие в open source помогло мне приобрести множество навыков. Я научилась эффективно и уважительно общаться, что укрепило уверенность при взаимодействии с людьми. И хотя я не пишу код, я стала уверенно пользоваться GitHub и командной строкой в терминалах — навыком, который можно освоить только на практике. Open source предоставляет такую возможность.

Начинаем работу с мутационным тестированием

barancev@gmail.com (Administrator) — Sun, 12 Jul 2026 20:00:00 +0000

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

Как участники команды разработки программного обеспечения, мы тратим много времени на создание продуктов, от которых наши конечные пользователи (надеюсь) получают удовольствие. Мы также тратим значительное время на тестирование этих продуктов, а также на создание автоматизации, поддерживающей это тестирование. И чем выше степень автоматизации в процессе сборки, развертывания и доставки, тем больше доверия мы возлагаем на результаты этих автоматизированных тестов.

Во всём этом нет ничего нового: автоматизация тестирования, пайплайны сборки и практики вроде непрерывной интеграции уже давно часть нашей работы. Так почему же тогда, несмотря на высокий уровень доверия к автоматизированным тестам, команды (или, по крайней мере, те, с которыми мне доводилось работать) обычно тратят гораздо меньше времени на получение информации о качестве этих самы-х тестов?

Почему интуиция вас подводит: 5 ловушек теории вероятностей в IT

barancev@gmail.com (Administrator) — Wed, 20 May 2026 20:00:00 +0000

Автор: Александр Заплавный

Многим кажется, что теория вероятностей — это лишь вузовские задачи про урны с шарами, далекие от написания кода или настройки серверов. Кажется, что для успешной работы в IT достаточно логики и знания алгоритмов.

Однако на практике пренебрежение законами вероятности ведет к реальным инженерным ошибкам. Мы видим ложные тренды на графиках мониторинга, недооцениваем критичность «редких» багов и тратим часы на отладку тестов, не учитывая зависимость событий.

Проблема в когнитивных искажениях: человеческий мозг плохо работает со случайностями. Эволюционно мы привыкли искать закономерности даже там, где их нет, и в сложных системах интуиция часто нас подводит.

В этой статье мы не будем решать абстрактные задачи. Вместо этого разберем 5 практических ловушек, в которые попадают разработчики и аналитики, и посмотрим, как базовая математика помогает принимать взвешенные технические решения.

Первый месяц в Bug Bounty: итоги, цифры и выученные уроки

barancev@gmail.com (Administrator) — Wed, 06 May 2026 20:00:00 +0000

Оригинальная публикация

Мой путь в ИБ начался с нуля - у меня не было опыта работы и образования в айти в целом, будь это системное администрирование или программирование. Я просто планомерно учился и сдавал сертификации. За три года у меня собрался определенный стек: OSCP, HTB CWES, CRTP, PNPT, PJPT, PJOR, CompTIA A+, Network+ и Security+.

Когда пришло время искать работу пентестером, я столкнулся с реальностью: вакансий в моем регионе почти нет, а те, что находил, не приносили даже приглашений на собеседование. Профиль без практического опыта не вызывал интереса у работодателей. Чтобы начать нарабатывать реальный стаж, я решил попробовать себя в багхантинге.

Основная цель была простой получить опыт и проверить свои знания в бою, а не в лабораторной среде. Ну и, конечно, был интерес заработать репутацию практика и получить первые выплаты.

10 способов тестировать iOS-приложения: состояния и стадии жизненного цикла

barancev@gmail.com (Administrator) — Sun, 26 Apr 2026 20:00:00 +0000

Автор: Борис Добрецов (Boris Dobretsov)
Оригинал статьи
Перевод: Ольга Алифанова

В этой статье я расскажу о жизненном цикле и состояниях приложений для iPhone и iPad. Но подождите — зачем вам вообще это знать? Сейчас объясню.

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

Декарт, Поппер и баг в продакшене, или почему самый полезный предмет в моей карьере не имел отношения к ИТ

barancev@gmail.com (Administrator) — Thu, 23 Apr 2026 20:00:00 +0000

Автор: Дюжев Михаил

"Небо над Берлином" (Der Himmel über Berlin, 1987), режиссёр Вим Вендерс

Вдохновлено Михаилом Ивановым, коллегой и товарищем, который напомнил про "Мир искусства"

В разговорах с коллегами иногда всплывает тема образования. Клинический психолог, говорю. Собеседник вежливо кивает и переходит к следующей теме. Понятно: какое отношение психология имеет к тестированию?

Прямое. Но не потому, что я умею "понимать людей" или "находить подход к разработчикам". Дело в другом предмете из учебного плана.

На третьем курсе нам читали философию науки: Декарт, Поппер, Лакатос, Кун, принцип фальсифицируемости, бритва Оккама. Три семестра о том, как человечество училось отличать знание от заблуждения. Тогда это казалось красивой, но бесполезной абстракцией. Ну зачем практикующему психологу знать, как Карл Поппер спорил с венскими позитивистами, а Имре Лакатос уточнял его идеи?

Прошло пятнадцать лет. Я давно не психолог, я руковожу тестированием. И в какой-то момент вдруг осознал: я каждый день делаю ровно то, о чём рассказывали на тех лекциях. Ищу минимальный воспроизводимый сценарий - это декартовское деление сложного на простое. Формулирую гипотезу так, чтобы её можно было опровергнуть - это Поппер. Выбираю самое простое объяснение из возможных - это Оккам.

Оказалось, философия науки - это не про философию. Это операционная система для мозга, который работает с неопределённостью. И эту статью я вынашивал не один год, чтобы наконец объяснить, почему.

Почему документация – это важно: пять причин

barancev@gmail.com (Administrator) — Tue, 03 Feb 2026 20:00:00 +0000

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

После многих лет работы в тестировании программного обеспечения можно с уверенностью сказать: почти никто не любит писать документацию. Даже люди, которым нравится писать (как мне), могут полагать, что есть дела и поинтереснее – например, создание тест-планов или автоматизации тестов. Но документация крайне важна! В этой статье я расскажу о пяти причинах этого, а также поделюсь пятью стратегиями, которые помогут вашей команде или компании иметь качественную документацию.

Тестируем производительность фронтенда через вкладку Performance в DevTools

barancev@gmail.com (Administrator) — Sun, 14 Dec 2025 20:00:00 +0000

Автор: Ященко Святослав

Продолжаем разбирать малоизвестные, но крайне полезные фичи Chrome DevTools. Меня зовут Святослав Ященко, я тимлид QA-команды Platform V Kintsugi. Это графическая консоль для сопровождения PostgreSQL и Postgres-like СУБД. Ранее я писал о том, как подменить трафик в DevTools. Сегодня покажу, как тестировать производительность web-приложения, не выходя из Chrome.

Наш продукт — высоконагруженный, как в части бэкенда, так и в части фронтенда. БольшУю нагрузку на web-часть дают графики метрик наблюдаемых баз данных. Нагрузочное тестирование бэкенда в нашей команде — тема отдельной статьи, но об этом постараюсь рассказать в другой раз, а сейчас протестируем производительность фронтенда.