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

Хабр, привет! На связи Михаил Косцов, руководитель практики вычислительной инфраструктуры и систем резервного копирования К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 и в этой статье делимся опытом: подходами, выбором сценариев, шагами для первой успешной реализации, а также ключевыми итогами наших первых учений. Статья будет интересна всем, кто задумывается о повышении зрелости процессов безопасности в своей организации. 

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

Меня зовут Юнес, я Senior SDET в Т-Банке и провожу аудиты уже три года. За это время изучил десятки проектов и помог командам в оптимизации процессов. На одном из последних проектов удалось снизить соотношение дефектов прод/тест за месяц с 0,49 в августе до 0 в ноябре. В статье расскажу, как мы с коллегами выполняем аудит, о наиболее частых ошибках аудиторов и о том, как начать выполнять аудиты в компании.

Часть 2 из 3. [Первая часть - постановка проблемы]

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

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

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

Наш продукт позволяет клиенту подать заявку на нецелевой кредит под залог недвижимости.