Тестирование IT-систем *

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

Причина такого поведения оказалась в самом фундаменте: автотесты опирались на статичные, «зашитые» данные, созданные еще при первом покрытии кода. Они были разработаны более трех лет назад и для скорости были объявлены в виде констант непосредственно перед кодом теста.

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

Большинство утечек секретов происходят именно так. Не из-за взломов, а из-за инструментов, которые делают небезопасное поведение слишком удобным.

В этой статье разбираем, как API-ключи «утекают» при работе с HTTP-клиентами, почему Postman и IDE создают ложное чувство безопасности и какие системные ошибки приводят к реальным инцидентам с многомиллионными последствиями.

Как писать «скучные» API-автотесты на Go: выносим всю инфраструктуру в Axiom, оставляя в тестах только бизнес-сценарии, и запускаем всё в CI/CD с Allure.

Хабр, привет! На связи Михаил Косцов, руководитель практики вычислительной инфраструктуры и систем резервного копирования К2Тех. За последние годы у российских ИT-специалистов выработался «синдром недоверчивого покупателя». Когда презентуют очередную «полностью отечественную» разработку, машинально ищешь подвох: знакомый корпус под новым шильдиком, наспех перелицованный Open Source или иероглиф где-нибудь на плате. Устройство выглядит солидно, жужжит по-корпоративному, но все равно хочется заглянуть под капот. И мы заглянули. 

В нашу лабораторию приехала система хранения данных YADRO TATLIN.UNIFIED Gen2. Мой коллега ранее делился в Хабра-статьях итогами тестирования решений от вендора YADRO: СХД начального уровня TATLIN.FLEX.ONE и системы TATLIN.BACKUP для хранения резервных копий.

Итак, мы не стали церемониться: дергали диски на горячую, рубили питание / сеть / контроллеры и все, до чего могли дотянуться, протестировали модный NVMe over TCP в сравнении с классическим Fibre Channel. А потом обнаружили, что реальные цифры производительности разошлись с даташитом — причем в неожиданную сторону. Сейчас все расскажу.

Всем привет! Меня зовут Найля, я инженер по обеспечению качества в Т-Банке. В поисках полезного материала часто слушаю доклады с личными кейсами и разборами инструментов. Это помогает увидеть проблемы глазами других и почерпнуть что-то полезное для себя и своего проекта. На весенней конференции Heisenbug выступал мой коллега Александр Бодня — тоже инженер по качеству. Его доклад показался мне интересным, и я захотела им поделиться. 

Сегодня в ИТ-сообществе все чаще говорят про T-shaped-специалистов — людей, обладающих глубокими знаниями в своей области и широким кругозором в смежных. Обычно этот подход обсуждается в контексте QA и Dev. А сейчас предлагаю посмотреть в другую сторону и обсудить интеграцию с SRE. 

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

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

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

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

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

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

В какой момент фоновая нагрузка перестаёт быть фоном?

Начнут ли расти очереди сообщений?

Появится ли деградация отклика спустя несколько часов работы?

Всё останется предсказуемым, когда пользовательские сессии и поток доставки писем пойдут параллельно?

Привет, Хабр! Меня зовут Владимир Сергеев, я руководитель практики UC и ПО для совместной работы в К2Тех. Мы решили не гадать на кофейной гуще, а проверить это в измеряемых условиях, на сценарии, с которым почтовая система живёт каждый рабочий день, и протестировали наш почтовый сервер CommuniGate Pro под длительной смешанной нагрузкой, близкой к реальной эксплуатации.

Нейросети обещали магию: закидываешь код, получаешь оценку. На практике магия плохо масштабируется — разные результаты при каждом запуске, невозможность объяснить оценку, растущие счета за API. Тогда я сделал шаг назад и спросил: а что именно я пытаюсь автоматизировать? Оказалось, всё можно сделать детерминированно. Один скрипт, нулевые зависимости, одинаковый результат при каждом запуске. Завершающая часть серии про методологию EVA — от философии до готового инструмента.

В статье разбираю, как уменьшить размер видео на Windows с помощью open-source инструмента FFmpeg.
Показываю установку, настройку переменной PATH и простую команду для эффективного сжатия с минимальной потерей качества.
Это поможет освободить место на диске и упростить хранение и передачу видеофайлов.

Нестабильные (flaky) тесты создают постоянные трудности для тестировщиков. Такие тесты не отражают состояния тестируемой системы и подрывают доверие к тестовому набору.

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

Заодно мы познакомимся с Allure 3. Многие из вас наверняка пользуются Allure 2 — в третьей версии (помимо прочих изменений) работа с нестабильными тестами стала гораздо удобнее, в особенности настройка истории тестов.

«Сколько платят в QA» — вопрос не про цифры, а про роль. Анализ зарплат QA-вакансий за 2025 год по данным 2500 объявлений показывает, почему manual и junior остаются в нижнем сегменте рынка, а automation и fullstack-специалисты получают существенно больше.

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

В статье я показываю альтернативу LLM в роли решателя внутри продукта: детерминированное ядро, работающее на конечном алфавите состояний с таблично заданной бинарной операцией — lookup/transition table.
Вместо вероятностных ответов — воспроизводимые вычисления с замыканием (фикс-точка или цикл), учётом симметрий (автоморфизмов) для факторизации перебора и со строгим контуром проверки: спецификации, валидаторы, регрессия и публичный отчёт в стабильном JSON-формате.
Систему можно запустить локально одной командой — или прогнать прямо в ChatGPT, если включён режим выполнения кода: вы получите PASS/FAIL и полный комплект артефактов прогона.

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

Почему метрики перестают работать? История измерения эффективности от Адама Смита до наших дней. Закон Гудхарта, тейлоризм, Деминг и уроки четырёх промышленных революций.

Привет, Хабр! Тема входа в IT популярна уже много лет подряд. Меня зовут Анжелика, и я работаю ведущим инженером в тестировании уже 3 года, хочу поделиться своими наблюдениями и дать парочку советов для того, чтобы этот вход был эффективнее. В статье мы рассмотрим рынок труда в 2025 году, построим прогнозы на 2026 год, разберем необходимые навыки для поиска работы, а также узнаем, как выделяться на рынке труда для получения заветного оффера.

Делимся практическим кейсом рефракторинга автотестов учетной системы: от линейных скриптов к архитектурному подходу, который ускорил написание тестов в три раза.

Технический долг в автотестах — это катастрофа, которая нарастает незаметно. Сначала «простые и быстрые» линейные скрипты кажутся хорошим решением, но с ростом продукта они превращаются в «спагетти-код», где любое изменение в интерфейсе вызывает часовую рутину правок. Мы прошли этот путь в проекте по разработке учетной системы и нашли выход через внедрение архитектурного паттерна Page Object Model (POM).

Состояние «до» с линейными автотестами

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

Работает ли это? А что, если… ? Как настоящие QA, мы всегда задаемся этими вопросами. Неудивительно, что вся наша команда взбудоражилась, увидев рилс про «фейковую бесконечность» прокрутки в будильнике на iPhone. Неужели правда? Конечно, тут же проверили на тестовых айфонах. Оказалось, часы и минуты в iOS-будильнике действительно не цикличны. Это список, который можно быстро долистать до конца.

Нам стало интересно, баг ли это, откуда он в iOS и есть ли такое в Android. Чтобы разобраться и найти ответы, нам даже пришлось «на коленке» написать автотест на C#. Но обо всем по порядку.

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

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

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

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