На главную

Я устал от ИИ

2025-10-13T20:00:00Z

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

Если вы провели последние несколько лет в бункере, вы, вероятно, заметили этот колоссальный всплеск применения искусственного интеллекта (ИИ) практически ко всем текущим задачам — в тестировании программного обеспечения, в разработке и вообще в жизни.

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

Сегодня почти любая техническая новинка с намёком на «ИИ» мгновенно объявляется «прорывом», чтобы на следующей неделе уступить место следующему «ключевому» и «революционному» «решению».

От Basic Auth до OIDC: тестирование аутентификации и авторизации для QA-инженеров

2025-10-12T20:00:00Z

Автор: Екатерина Ступкина

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

Я, Екатерина, QA Lead в «Лиге Ставок», покажу, как с помощью инструментов тестирования проводить базовые проверки: тестировать валидность токенов, отслеживать их обновление и проверять корректность прав доступа.

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

Четыре фрейма тестирования, часть 5: Намерение, Дисциплина, Тестируемость, Реализация

2025-10-07T20:00:00Z

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

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

Как внедрить TBD?

2025-10-06T20:00:00Z

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

Привет! На связи разработчик Максим и инженер по качеству Евгения из Т-Банка. Как-то мы задумались о переходе на TBD (Trunk Based Development), чтобы избежать develop-ветки со всеми вытекающими.

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

В этой статье мы поделимся опытом перехода на TBD: планом внедрения и вопросами, с которыми мы столкнулись.

Cтатья пригодится инженерам уровня middle и ниже и тимлидам. Для senior-инженеров статья не будет откровением, но надеемся, что станет местом для обсуждения нюансов внедрения или возможностью посмотреть на процесс с точки зрения QA.

Погнали!

Автоматизация слайдеров: 3 легких способа

2025-10-05T20:00:00Z

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

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

В этой статье мы рассмотрим три эффективных метода автоматизации слайдеров: перетаскивание (drag-and-drop), взаимодействие с помощью клавиатуры и прямой ввод значения. Каждый из этих подходов обладает своими плюсами и минусами, и мы подробно разберём, как их реализовать, а также в каких случаях каждый метод будет наиболее полезен.

Кэшируй меня, если сможешь: работа с кэшем в автоматизированном тестировании

2025-09-30T20:00:00Z

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

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

Неизвестные пробелы в тестовом покрытии

2025-09-29T20:00:00Z

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

Привет! Я Наталья, QA в команде инкассации. Моя система умеет планировать маршруты для инкассаторов T-Банка. Поделюсь докладом моего коллеги — архитектора Boxy SDK Дмитрия Кузнецова, — который услышала на конференции Heisenbug.

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

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

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

Автоматизация учета и оборота тестовых устройств, тестирование контрактов, компонентов, UX, миграций, охота на баги, ИИ: самые интересные новости тестирования за третий квартал-2025

2025-09-29T04:45:27Z

Опубликован выпуск рассылки за 3 квартал 2025 года.

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

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

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

Четыре фрейма тестирования, часть 4: чего хочет бизнес от тестирования

2025-09-23T20:00:00Z

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

В прошлый раз мы рассмотрели, чего бизнес хочет от разработки. А чего бизнес хочет от той части разработки, которую мы называем тестированием?

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

Как ChatGPT помогает при обучении

2025-09-22T20:00:00Z

Автор: Ольга Назина (Киселёва)

Как мы учимся новому:

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

Но ведь теперь есть ChatGPT (и его аналоги) — искуственный интеллект (ИИ), очень много знающий. Ему можно задать любой вопрос и получить развернутый ответ. Как он изменит обучение? Заменит ли он тренера на курсах? Или будет ему помогать?

См также:
Базовая подборка аналогов ChatGPT (текстовых ИИ) — чаты, с которыми можно пообщаться

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

Тест-долг: он существует и ежедневно мешает нам жить во всех окружениях

2025-09-21T20:00:00Z

Автор: Рависурия Ишвара (Ravisuriya Eswara)
Оригинал статьи
Перевод: Ольга Алифанова

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

А вместе с техническим долгом неизбежно появляется и тестовый долг. Определение и понимание объема и значимости тестового долга — часть моей работы.

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

2025-09-17T20:00:00Z

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

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

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

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

Начнем с начала: автоматизируйте запуск ваших тестов

2025-09-15T20:00:00Z

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

«Ну, на моей машине все работает».

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

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

Сидинг тестовых данных: как готовить окружение перед нагрузочным тестированием

2025-09-14T20:00:00Z

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

Введение

Когда мы начинаем погружаться в нагрузочное тестирование, первая мысль обычно такая: «Сейчас я напишу сценарий, запущу кучу виртуальных пользователей — и вот она, настоящая нагрузка!». Но очень быстро приходит понимание: без подготовленных данных результаты будут далеки от реальности.

Здесь на сцену выходит сидинг (от англ. seeding). Это понятие часто вызывает вопросы у начинающих инженеров по тестированию производительности: «Что это за зверь такой и зачем он нужен?». На самом деле, сидинг — один из тех невидимых, но критически важных этапов подготовки, от которого напрямую зависит качество и честность ваших нагрузочных тестов.

В этой статье мы разберёмся:

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

Четыре фрейма тестирования, часть 3

2025-09-08T20:00:00Z

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

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

Как улучшить прогоны автотестов при помощи карантина

2025-09-07T20:00:00Z

Привет, меня зовут Андрей и я автоматизатор (остальные в кругу хлопают в знак сочувствия) в hh.ru. В статье расскажу, как мы ввели карантин автотестов, повысив стабильность релизов и скорость доставки.

Перезагрузка охоты на баги: пять способов усилить ваше тестирование

2025-09-03T20:00:00Z

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

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

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

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

Вот несколько таких техник, которые, по моему опыту, приносят хорошие результаты.

Как выбрать профиль нагрузки: 5 ключевых правил

2025-09-01T20:00:00Z

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

Вступление

В нагрузочном тестировании есть один коварный момент, который встречается даже у опытных команд: берут «красивый» сценарий (например, тысячу виртуальных пользователей), запускают его, получают кучу графиков — и считают задачу выполненной. Звучит солидно, но толку от этого примерно как от стрельбы из лука с закрытыми глазами: попасть можно, но это больше про удачу, чем про инженерный подход.

Правильный профиль нагрузки — это не просто цифра в настройках. Это ответ сразу на три вопроса:

Что мы нагружаем (какие сервисы или сценарии),
Как мы нагружаем (параметры, последовательность, интенсивность),
Почему именно так (данные, прогнозы или требования).

Цель этой статьи — дать практические рекомендации, которые помогут правильно выбрать профиль нагрузки и сделать тестирование осмысленным и полезным, а не просто «запуском ради отчётности».

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

Все пропало: 10 синих экранов смерти

2025-08-31T20:00:00Z

Автор: Эди Стоукс, Рабай’а Браун (Ady Stokes, Rabi'a Brown)
Оригинал статьи
Перевод: Ольга Алифанова

Синие экраны — это только начало

Пока большая часть мира восстанавливалась от «чёрного лебедя» — масштабного сбоя, связанного с CrowdStrike и Azure, — команда Ministry of Testing решила поделиться несколькими лёгкими и забавными историями о том, как любимые устройства (и маломощные рабочие ноутбуки) умирали или просто притворялись мёртвыми.

Примечание: некоторые из вас, возможно, никогда не видели печально известный "синий экран смерти" Windows, который мы здесь будем иногда называть BSoD (Blue Screen of Death). Читайте дальше, чтобы узнать подробности.

История о свершениях одного QA: о Quality Gates и оптимизации релизных процессов в ОК

2025-08-26T20:00:00Z

Задача любого тестировщика — проверять продукт на соответствие установленным требованиям и своевременно отлавливать любые баги и ошибки. В идеальных условиях или небольших проектах эта схема работает безотказно. Но в ситуациях, когда над продуктом работает несколько команд разработки, в релизы попадает по 30–70 задач, а обновления выкатываются каждую неделю, фокуса тестировщиков может просто не хватить. В таких условиях не обойтись без Quality Gates.

Меня зовут Юлия Садовникова. Я старший специалист по тестированию в команде Core Android компании ОК. В этой статье я расскажу о Quality Gates в ОК и о том, как QA может не просто тестировать, а реально влиять на проект и процессы.

Не вредит ли качеству вашего ПО тестирование через страх?

2025-08-25T20:00:00Z

Автор: Хосе Каррера (Jose Carrera)
Оригинал статьи
Перевод: Ольга Алифанова

Что такое тестирование, управляемое через страх?

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

Такое поведение может быть вызвано разными причинами: давлением со стороны бизнеса, нехваткой знаний в предметной области, жёсткими сроками и т.д. Ещё один важный аспект — это восприятие качества внутри команды и бизнеса:

Разделяется ли ответственность за качество между всеми участниками команды?
Где находятся контрольные точки качества (quality gates)?

Если процесс построен так, что QA-инженеры становятся единственными "хранителями качества", без полноценного участия других специалистов, это приводит к тому, что тестирование превращается в деятельность, движимую страхом — страхом быть обвинёнными в том, что баг не был обнаружен до выхода в продуктив.

Как в Postman использовать данные из файла

2025-08-19T20:00:00Z

Автор: Ольга Назина (Киселёва)

В Postman есть возможность загружать данные из файла — указал в запросе «возьми имя из файла», сделал файл на 100 имен, и вуаля! Запускаешь 1 запрос, а он выполняется 100 раз с разными данными.

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

А вот что с этим файликом делать дальше? Как сказать постману, что мы хотим подставить эти данные в запрос или в автотест? Где какой синтаксис использовать? Об этом и поговорим в статье на примере системы Users.

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

Когда данные переезжают: практические советы по тестированию миграции данных

2025-08-18T20:00:00Z

Автор: Константин Сахчинский (Konstantin Sakhchinskiy)
Оригинал статьи
Перевод: Ольга Алифанова

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

Нефункциональные проверки мобильных приложений

2025-08-17T20:00:00Z

Меня зовут Алексей, я работаю тестировщиком в компании «Совкомбанк Технологии». Хочу поговорить о нефункциональном тестировании мобильных приложений на платформах Android и iOS.

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

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

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

2025-08-12T20:00:00Z

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

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