На главную

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

2026-02-24T20:00:00Z

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

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

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

Простые рецепты аутентификации в Playwright: кулинарная книга тестировщика

2026-02-23T20:00:00Z

Автор: Cуатика Визань (Swathika Visagn)
Оригинал статьи
Перевод: Ольга Алифанова

Что общего у кулинарии и автоматизации тестирования?

Что общего у кулинарии и автоматизации тестирования, спросите вы? Можно провести красивые параллели между программированием и готовкой: автоматизаторы тестирования как шеф-повара, скрипты автоматизации как рецепты, фреймворки автоматизации как кастрюли и сковородки, а кулинарная книга — как эта статья! Эта статья посвящена всем тестировщикам, которые ищут новые рецепты аутентификации с использованием Playwright.

Статья предназначена для автоматизаторов тестирования, которые уже знакомы с Playwright или используют его в своей работе. Для демонстрации я буду использовать учебный магазин Book Cart, на который я наткнулась в статье Сары Дири на сайте Ministry of Testing.

Для этой «поваренной книги» я отобрала четыре рецепта аутентификации, варьирующиеся от базового до среднего уровня сложности. Эти рецепты используют сочетание методов аутентификации через UI и API, с объяснением реальных сценариев применения для каждого из них.

Пострелизная валидация данных как новый вид тестирования?

2026-02-17T20:00:00Z

Оригинальная публикация
Автор: Сергей Терентьев

Пролог

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

О статье и общая проблематика

В этой статье я расскажу о виде тестирования, который мне ранее не встречался в стандартных QA источниках, при этом нечто очень похожее используется в направлении Data Engineering. Этот вид тестирования показал свою эффективность в тех случаях, когда у вашего проекта есть следующие особенности:

это легаси проект с непрозрачной, плохо задокументированной и достаточно сложной логикой (назовем ее “серой логикой”). При этом члены команды, обладающие контекстом легаси не могут 100% гарантировать (или у вас есть сосмнения), что их воспоминания о фактическом поведении “серой логики” верны
на проекте присутствует БД, данные которой являются точкой применения вышеуказанной “серой логики”
сам проект уже в production
при этом ограничения, установленные на уровне БД не могут покрыть все необходимые ограничения, которые требует бизнес логика (само собой при наличии достаточно сложного функционала)

Согласитесь, не так, чтобы эти условия были какой-то редкостью).

Silo и технический долг

2026-02-16T20:00:00Z

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

Недавно я посмотрела сериал AppleTV Silo. Шоу рассказывает о жизни 10 000 человек, обитающих в подземном бункере. Они знают, что их предки жили там сотни лет, но не знают, зачем, и почему выходить наружу опасно.

Бункер работает от генератора, который обслуживает команда Механиков. В третьем эпизоде показано, что генератор не работает правильно уже 30 лет и быстро приближается к критическому состоянию. Конечно, это сразу напомнило мне о техническом долге в программном обеспечении! В этой статье я рассмотрю восемь шагов, которые команда должна предпринять для работы с техническим долгом, с примерами из Silo и из проекта, над которым я работала несколько лет назад.

Как я научила ИИ быть моим напарником по тестированию

2026-02-15T20:00:00Z

Автор: Екатерина Гаврилова

Меня зовут Катя и я ведущий инженер по тестированию в MD Audit.

Хочу поделиться как я внедрила ИИ в процессы тестирования, чтобы не тратить время на рутинные задачи и больше заниматься любимым делом (кидать мемы в рабочие чаты).

AI не заменит тестировщика. Но тестировщик, умеющий работать с AI, заменит десятерых.

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

Разбираемся с таймаутами в WebdriverIO

2026-02-10T20:00:00Z

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Таймауты — одна из ключевых частей end-to-end тестирования UI. При тестировании пользовательских интерфейсов мы часто сталкиваемся с различными формами случайности (или кажущейся случайности) в том, как элементы появляются и взаимодействуют.

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

Топ-3 отечественных TMS: где вести тесты, когда привычные инструменты больше недоступны

2026-02-09T20:00:00Z

Автор: Яковлев Станислав — Team Lead команды тестирования сервиса Юла, телеграмм канал t.me/qa_chillout

До ухода с российского рынка таких систем, как TestRail, Qase, Zephyr, острой потребности в переходе на отечественные решения не было.

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

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

Однако курс на импортозамещение стал стимулом для роста. За последние несколько лет появились десятки российских TMS — от простых облачных сервисов до крупных корпоративных платформ с интеграциями и удобной системой отчётности.

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

2026-02-03T20:00:00Z

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

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

Gradle для QA-инженера

2026-02-02T20:00:00Z

Автор: Волтов Николай

Введение

Если вы автоматизируете на Java или Kotlin, вы не могли не слышать о Gradle. Одни его хвалят за скорость и гибкость, другие ругают за сложность конфигурации. Что же это за инструмент и почему всё больше проектов переходят на него с Maven? В этой статье мы разберем Gradle, чтобы вы могли уверенно использовать его в своих проектах для автоматизации тестирования, а так же спокойно ответить на вопросы на собеседовании.

Автоматизация слайдеров и авторизации, фреймы тестирования, Deep Links и кэширование, OWASP-уязвимости, тест-решения от Т-Банка: самые интересные новости тестирования за декабрь-январь

2026-02-02T07:48:27Z

Опубликован выпуск рассылки за декабрь-январь.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Знай свой предел

2026-01-27T20:00:00Z

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

Большинство тестировщиков программного обеспечения знает, как проводить граничных значений: например, зная, что текстовое поле должно принимать не более 20 символов, тестировщик проверит ввод 19 символов, 20 символов и 21 символа, а возможно, даже 100 символов. Но я часто сталкивалась с ситуациями, когда тестировщик не проводил тестирование границ, если в критериях приёмки не было явно указано ограничение. Это опасно!

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

Промпт для QA: представь, что ты НЕ тестировщик

2026-01-26T20:00:00Z

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

Меня зовут Екатерина Кияшева, и я занимаюсь оптимизацией тестирования. Хорошее тестирование начинается с продуманного тест-дизайна. QA важно выстроить проверки так, чтобы тесты действительно были полезными. В этой статье расскажу, как промпт-инжиниринг помогает улучшать качество тест-дизайна, и поделюсь неожиданным открытием об ИИ, вдохновившем на заголовок. Тем, кто хочет сразу к промпту, жать сюда.

Удаление кода как подход к обучению

2026-01-25T20:00:00Z

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

Обычно, когда я изучаю что-то новое, например язык программирования или новый инструмент автоматизации, мне нравится проходить полный курс. Курсы структурированы для логичного, постепенного обучения. Но иногда, когда я хочу выучить что-то быстро, я использую то, что называю «Методом удаления кода». Не знаю, делает ли так кто-то ещё, но мне хотелось бы думать, что название придумано мной!

Метод удаления кода предполагает работу с проектом, написанным кем-то другим, с целью его понимания путём постепенного удаления строк кода, пока не останется только базовая функциональность. Вот как это работает:

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

2026-01-21T20:00:00Z

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

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

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

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

Что такое тест-покрытие?

2026-01-19T20:00:00Z

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

Мы живём во времена, когда измерить можно что угодно. Веб-сайты отслеживают посещения пользователей со всего мира; видео на YouTube фиксируют просмотры и лайки; мобильные приложения собирают статистику сбоев. Поэтому логично, что менеджеры по разработке программного обеспечения стремятся замерить качество процессов.

К сожалению, у нас не всегда есть чёткий язык для описания измеряемого. Возможно, вы слышали, как менеджер говорил о достижении «100% тест-покрытия». Но что именно он имеет в виду под этим утверждением? Вот несколько вариантов, что это может означать, и один вариант, чего это значить ни в коем случае не может.

От Jest к Vitest на backend тестах: как мы мигрировали тестовый фреймворк для ускорения CI и повышения стабильности

2026-01-18T20:00:00Z

Привет! Я Максим Кузьмин, старший инженер по автоматизации в команде Т-Путешествий. Строю и развиваю процессы автоматизации и разрабатываю инструменты тестирования.

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

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

Создание и улучшение Page Object шаг за шагом

2026-01-13T20:00:00Z

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

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

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

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

Performance monitor и не только: продолжаем тестировать производительность в Chrome DevTools

2026-01-12T20:00:00Z

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

Продолжаем разбирать малоизвестные, но крайне полезные фичи Chrome DevTools. Меня зовут Святослав Ященко, я тимлид QA‑команды Platform V Kintsugi — это графическая консоль для сопровождения PostgreSQL и Postgres‑like СУБД. Ранее я писал о том, как тестировать производительность через вкладку Performance. Материала набралось так много, что мне пришлось разбить его на две статьи. Сегодня мы поговорим об утилите Performance monitor, инструменте Chrome Task Manager и о том, как вывести FPS сайта на экран.

Улучшение тестов RestAssured.Net при помощи мутаций и Stryker.NET

2026-01-11T20:00:00Z

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

Когда я разрабатываю и выпускаю новые функции или исправления ошибок для RestAssured.Net, я сильно полагаюсь на приёмочные тесты, которые постепенно писал. Помимо того, что они служат живой документацией для библиотеки, я запускаю эти тесты как локально, так и при каждом пуше на GitHub для разных версий .NET, чтобы убедиться, что ничего по случайности не сломал.

Но насколько на самом деле надёжны эти тесты? Могу ли я верить, что они будут проходить успешно и падать именно тогда, когда нужно? Покрыл ли я все важные моменты?

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

Когда я говорю о тестировании тестов, я демонстрирую это с применением мутационного тестирования (недавнюю лекцию можно посмотреть здесь), но до сих пор я в основном использовал PITest для Java. Поскольку RestAssured.Net — библиотека на C#, я не могу использовать PITest, но слышал много хорошего о Stryker.NET – это был идеальный шанс наконец испробовать его в деле.

С новым 2026 годом!

2025-12-31T07:31:16Z

Дорогие читатели, тестировщики и тестировщицы, сеньоры и джуниоры, ручники и автоматизаторы, а также менеджеры и разработчики -- мы поздравляем всех с наступающим Новым Годом и Рождеством! Пусть в Новом Году исполнятся все ваши профессиональные и личные мечты! Пусть ваши релизы будут стабильными, пользователи и заказчики - довольными! Желаем вам всегда находить баги как можно раньше, и не пропускать на прод ни одного.

С новым 2026 годом!

Как запускать 100k+ браузеров в день и спать спокойно

2025-12-23T20:00:00Z

Привет! Я Павел Лобач из команды инфраструктуры тестирования Т-Банка. Расскажу, как у нас организована инфраструктура для запуска E2E браузерных тестов, как она развивалась и как в итоге вылилась в открытый проект Selebrow.

Будет много технических подробностей и ни слова про ИИ!

E2E-тесты и как их запускают

E2E-тесты (end-to-end, или сквозные, тесты) занимают вершину пирамиды тестирования. E2E — наиболее комплексные и ресурсоемкие тесты, которые проверяют всю систему от начала до конца, включая взаимодействие всех компонентов и пользовательский интерфейс.

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

Контрактное тестирование: что (не) тестировать – часть 1

2025-12-21T20:00:00Z

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

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

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

ПОТРАЧЕНО–3. Как тестировать локализацию переводов, чтобы потом не было стыдно

2025-12-16T20:00:00Z

Автор: Михаил Кургузов

Итак, две части про локализацию и её тестирование позади (раз, два), пришло время для третьей.

Как и обещал, сегодня про подробности интеграции в процесс тестирования, чеклист и другие полезности.

С чего стоит начинать интеграцию тестирования в разработку? Правильно, как и любое другое важное дело — с планирования. Причём чем раньше вы всё это дело запланируете, тем будет лучше.

Квадрант тест-автоматизации: новый взгляд на ваши тесты

2025-12-15T20:00:00Z

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

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

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

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

Обратите внимание, что всякий раз, когда я использую слово «тест» в оставшейся части этой статьи, я имею в виду автоматизированный тест / проверку, которая подтверждает или опровергает ожидания относительно поведения нашего продукта. Не думаю, что эта модель так же хорошо применима к исследовательскому тестированию (но буду рад, если меня опровергнут).

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

2025-12-14T20:00:00Z

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

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

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