На главную

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

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

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

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

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

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

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

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

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

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

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

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

barancev@gmail.com (Administrator) — Wed, 31 Dec 2025 07:31:16 +0000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестируем производительность фронтенда через вкладку 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-часть дают графики метрик наблюдаемых баз данных. Нагрузочное тестирование бэкенда в нашей команде — тема отдельной статьи, но об этом постараюсь рассказать в другой раз, а сейчас протестируем производительность фронтенда.

Четыре фрейма тестирования, часть 7: критическая дистанция

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

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

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

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

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

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

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

Возможные проблемы

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

Есть ли что-то в вашем «Я», кроме искусственного интеллекта?

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

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Как мы в Т-Банке ручное тестирование роботизировали

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

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

Привет! Мы команда из отдела разработки ПО для банкоматов Т-Банка: Александр, Владислав, Иван и Денис.

Расскажем о необычном, но интересном опыте автоматизации и роботизации тестирования банкоматного ПО в Т-Банке, для которого мы использовали коллаборативного робота.

Ручное тестирование нового ПО АТМ (automated teller machine или по-нашему: банкомат)трудозатратно, требует много времени и ресурсов. Зачастую действия повторяются и QA выполняет одни и те же тест-кейсы. Нашей целью было высвободить ресурс QA, уйдя от рутинного ручного тестирования к более творческим задачам путем роботизации ручного тестирования.

Качество = Здоровье

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

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

Я всегда интересовалась здоровьем и фитнесом, потому что хочу жить долго и полноценно. Но с возрастом я поняла, что методы, которые раньше помогали мне оставаться в форме, перестали работать: я постепенно набрала 30 фунтов (~13,5 кг) и поняла, что нужно что-то менять. Изменения были внедрены, и я вернулась к своему прежнему весу.

В последнее время я много говорила о качестве программного обеспечения и о том, почему командам сложно внедрять хорошие практики. И сегодня меня осенило: между поддержанием здоровья по мере взросления и поддержанием «здоровья» программного обеспечения много параллелей. Давайте рассмотрим распространённые оправдания, которые мешают оставаться «в форме».

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

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

Привет! Меня зовут Михаил Кургузов, я из отдела локализации и переводов SM Lab. В этом цикле постов я расскажу о локализации и ее интеграции в процесс тестирования ПО.

Пост #1 (вы находитесь здесь) — общая вводная про локализация и интернационализацию, важные примеры, лингвистические ошибки и функциональные баги, особенности разных языков.
Пост #2 — особенности тестирования локализации, кто чем занимается, как проходит процесс.
Пост #3 — чеклист, лучшие практики, дополнительные материалы и много полезных примеров.

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

Оверинжиниринг ваших тестов

barancev@gmail.com (Administrator) — Mon, 24 Nov 2025 20:00:00 +0000

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

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

Управление временем контейнера с помощью docker-compose и faketime

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

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

Зачем нам управлять временем?

В начале немного о себе, мое основное занятие — обеспечение качества на вверенных проектах, я Senior QA в компании Umbrella IT. Периодически при тестировании микросервисов приходится сталкиваться с необходимостью изменения времени для проверки работы того или иного функционала. Это может быть функционал, который срабатывает по «тику» cron, или связанный с применением системного времени как одного из условий обработки/хранения/передачи данных тестируемым микросервисом.

Если микросервис разворачивается в Docker, то время контейнера берется из системного времени хост машины и без дополнительных инструментов максимум, что мы можем поменять — это часовой пояс контейнера, но не само системное время. Проблема в том, что часто для целей тестирования просто изменения часового пояса, ровно как и изменения времени в пределах 24х часов, оказывается недостаточно. Что делать если нам нужно протестировать работу микросервиса в граничных значениях даты‑времени, например начало и конец месяца/года, или использовать замечательные даты, такие как 29 февраля, последние даты месяцев со сменой количества дней, и так далее?

Тестирование безопасности API – Неограниченное потребление ресурсов

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

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

В этой серии статей я обращусь к уязвимостям из списка топ-10 OWASP, посвященного безопасности API. В каждой статье я покажу вам, как экспериментировать с API, тестируя уязвимость, и обсужу свои выводы.

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

Способы стабилизации автотестов на backend: опыт сервиса Звук

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

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

Меня зовут Надежда Буртелова, я ведущая тестировщица в музыкальном сервисе Звук. В тестировании с 2014 года, с 2022 года работаю в Звуке: тестирую backend и менторю коллег. Последние два года активно пишу автотесты.

Закончила МФТИ: факультет аэрофизики и космических исследований.

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

Автоматизация 2FA: TOTP-аутентификация с расшифровкой QR-кода

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

Автор: Green Report
Оригинал статьи
Перевод: Ольга Алифанова

Двухфакторная аутентификация (2FA) жизненно необходима для защиты пользовательских аккаунтов. Одноразовые пароли, основанные на времени (TOTP) – популярный метод 2FA, добавляющий к обычному паролю дополнительный уровень безопасности. Однако ручное тестирование 2FA может быть утомительным для QA-команд, особенно когда приходится сканировать QR-коды и вводить OTP в строго ограниченные временные интервалы.

В этой статье мы рассмотрим, как полностью автоматизировать тестирование 2FA с использованием TOTP, Python, Playwright и декодирования QR-кодов. К концу статьи у вас будет отлаженный подход для эффективной автоматизации двухфакторной аутентификации в ваших тестах.

Deep Links глазами тестировщика: как они работают

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

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

Всем привет!
Хочу поделиться своим опытом понимания такой сущности, как deep links. Во-первых, чтобы аккумулировать знания, полученные на проекте, а во-вторых — чтобы обменяться ими для более эффективного решения задач и развития общей технической культуры. Надеюсь, материал окажется полезным.

Если коллеги заметят какие-то неточности или важные дополнения — буду благодарен за комментарии.

Руководство по аутентификации в Playwright

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

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

Аутентификация – как правило, первое препятствие при настройке автоматизации тестирования. В зависимости от сложности используемого метода аутентификации эта задача может оказаться весьма трудоёмкой. Давайте начнём с простого примера последовательности входа в систему.

Что должен знать и уметь Разработчик Автоматического Тестирования, чтобы называться Инженером

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

Автор: Daniel Haimov

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

В области автоматического тестирования я работаю уже 15 лет. За это время я работал как в крупных компаниях, так и в небольших стартапах. Использовал различные языки программирования и технологии. Был частью разных команд — от специализированных групп разработчиков автоматического тестирования до смешанных команд, где вместе работали и разработчики, и тестировщики. За время карьеры занимал различные позиции и дорос до Senior Automation Engineer.

Четыре фрейма тестирования, часть 6: разработка и тестирование фрактальны

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

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

В предыдущей статье этой серии подробно описывалось тестирование через призму Намерения, Дисциплины, Тестируемости и Реализации:

Как мы систематизировали работу с техдолгом в своей QA-команде

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

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

Меня зовут Илья, работаю инженером по обеспечению качества в Т-Банке. Пишу автотесты на Kotlin, занимаюсь ручным тестированием и стараюсь улучшать процессы в команде.

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

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

Тестирование безопасности API – Отсутствие защиты от автоматизированных угроз

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

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