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

Представлен обновлённый проект Awesome Black Hat Tools, где собраны все инструменты, которые когда-либо были представлены на ИБ-конференциях Black Hat. Инструменты аккуратно структурированы по странам, где проходила конференция, по годам и категориям Red Teaming, Blue Teaming, OSINT & Recon, Exploit Development, Malware Analysis, DFIR & Forensics, Threat Intelligence, ICS/IoT/SCADA и Application Security (AppSec).

Также все презентации с выступлений Black Hat, начиная с 2023 года, собраны на отдельной странице GitHub.

Как не потерять важные проверки в долгих тестах: soft-assert на практике

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

Решение — использовать soft-assert, которые не прерывают выполнение. В команде мы используем Pytest плагин pytest-check, которая позволяет писать soft-assert через контекстный менеджер with check. Это дает возможность:

• продолжить тест даже при частичных ошибках,

• собрать диагностику по множеству компонентов (например, контроллеры, кэши, пулы),

• минимизировать потери времени при дорогостоящих прогонах.

Пример soft-assert с pytest-check:

from pytest_check import check


def object_stack():
    pool_stack = ExitStack()
    yield pool_stack
    for host in hosts:
        with check:
             result = None
             try:
                PoolsService.get_pools_info(host)
             except HostUnavailableException as err:
                result = err
             assert not issubclass(type(result), HostUnavailableException), f'Failed to get pool: {result}'

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

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

О том, как устроен процесс проверки надежности СХД TATLIN.UNIFIED, рассказала Наталья Грязнова, ведущий инженер по разработке ПО в YADRO. В тексте она делится подходами, которые позволяют комплексно проверять работу систем в разных условиях — от сверхнагрузок до нестабильной среды.

Как подход Docs-as-a-code применили в создании документации для TestY TMS

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

Для ведения документации выбрали подход Docs-as-a-code. Документация хранится вместе с кодом приложения. Для написания и сборки использовали более-менее классическое сочетание: rST-формат в связке со Sphinx. 

Инженеры уверены, что такой вариант предоставляет большую гибкость, чем стандартный MD. К тому же,  rST в связке со Sphinx — стандарт документации для open source-проектов.

Разработчики поддерживают документацию в актуальном состоянии, поэтому рассчитывают, что в дальнейшем любое изменение текущей функциональности, как и разработка новой, будет сопровождаться обновлением документации. Это будет одним из Definition of Done для реализации фич.

Помимо документации в релизе 2.1 появилась темная тема и другие обновления интерфейса. Читайте о них в статье →

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

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

🛑 Главная угроза — утечка данных

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

📌 Реальные инциденты

• Samsung, 2023 — сотрудники случайно слили внутренний код и конфиденциальные данные через ChatGPT, используя его для дебага. Позже компания запретила использование ИИ-сервисов.
  🔗 Сотрудники Samsung раскрывали конфиденциальные данные, общаясь с ChatGPT

• Американский банк JPMorgan ещё в 2023 году ограничил доступ сотрудников к ChatGPT, чтобы не допустить утечки данных.
  🔗 Bank of America, Citigroup, Deutsche Bank, Goldman Sachs Group, Wells Fargo и JPMorgan Chase запретили в работе ChatGPT

• В России — в 2024 году Ростелеком опубликовал отчёт, где указал, что более 30% утечек в ИБ инцидентах связаны с несанкционированным использованием облачных AI-сервисов.
  🔗 «Ростелеком»: утечка данных была в инфраструктуре подрядчика, пользователям рекомендуется сбросить пароли и включить 2FA

🔍 Что делать в банке

• Использовать внутренние или локальные решения ИИ, работающие в изолированной среде.

• Обучать команды тестирования и разработки по теме: "какие данные можно и нельзя передавать ИИ".

• Применять анонимизацию данных при генерации тестов.

• Развивать политику «zero trust» при работе с внешними API и сервисами.

💡 Дополнительные материалы

• 🔗 Статья «ИИ и безопасность» — Хабр

• 🔗 «Риски ИИ и кибербезопасности» от Malwarebytes
  Обзор угроз, связанных с использованием ИИ в кибербезопасности, включая атаки и методы защиты.

• 🔗 «Как ИИ меняет мир кибербезопасности – защита или угроза?»
  Анализ плюсов и минусов использования ИИ в кибербезопасности, включая перспективы развития.

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

📌 Подписывайтесь на мой Telegram-канал про тестирование, AI и IT в целом! — там делюсь мыслями, новостями и практическими примерами из жизни!

Приглашаем на QA Meetup 28 мая! Спикеры от Garage Eight, МТС, Островок.

Если ты тестировщик, QA-инженер или просто неравнодушен к качеству продуктов — приходи в гости в петербургский офис международной продуктовой IT-компании Garage Eight 28 мая в 19:00.

В программе три выступления от крутых спикеров:
> Алина Матлахова, QA Guild Lead, Островок – Zero Bug Policy: работа с багами и их превентированием.
> Лена Федорова, QA, Garage Eight – Мир, дружба, тестирование: как QA и Dev могут работать вместе на высшем уровне.
> Андрей Ганин, Chief Quality Officer, МТС – Что убивает качество?

А ещё будет:
— QA-викторина с призами;
— Пицца, напитки и живое общение;
— Экскурсия по нашему красивому офису (если ты у нас ещё не был — самое время заглянуть!);
— Немного развлечений — плойка, кикер, кайфовая атмосфера.

Где: Санкт-Петербург, офис Garage Eight (Новгородская улица, 17)

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

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

И подписывайся на нас в telegram, чтобы не пропускать будущие митапы!

Тяжела и неказиста жизнь простого программиста статических анализаторов кода

Команда PVS-Studio, содействуя разработке методики испытаний статических анализаторов под руководством ФСТЭК, составляла некоторые синтетические тесты. Писать синтетические тесты сложнее, чем кажется, и с их достоверностью всегда масса нюансов. Я никогда не любил синтетические тесты и продолжаю их не любить. Но что делать, они тоже нужны, когда речь заходит о необходимости подтвердить, что в анализаторах реализован определённый набор технологий.

Даже зная и понимая нюансы составления синтетических тестов, мы всё равно наступили на собственные грабли! Переиграли сами себя :)

Есть составленные нами тесты, в которых в функцию srand или её аналог передаётся константное значение. Это приводит к тому, что функция rand каждый раз будет генерировать одинаковую последовательность псевдослучайных чисел. Такой код, согласно ГОСТ Р 71207-2024, п. 6.3.г, может являться ошибкой некорректного использования системных процедур и интерфейсов, связанных с обеспечением информационной безопасности (шифрования, разграничения доступа и пр.).

Когда тесты подготавливались в Compiler Explorer, всё работало: PVS-Studio выдавал предупреждение V1057. А сейчас, когда код мило и скромно лежит в файлах, не работает. На Compiler Explorer работает, а вне — нет. Магия. Уже собрались баг в анализаторе искать.

Ах нет, всё просто. Файлы с тестами называются test_err_*.cpp. И в детекторе срабатывает исключение N4: "Находимся в файле, содержащем в названии слова check/test/bench". Тьфу. Причём получается, что анализатор прав: это действительно тест, а не настоящий баг :) Вот оно, несовпадение реальности и синтетических проверок в действии. Выкрутимся как-нибудь, но решил описать, так как случай интересный.

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

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

Был рад поведать немного интересного из жизни разработчиков статических анализаторов кода. А если хочется послушать что-то ещё, приглашаю на подкаст "Статический анализ по серьёзному" с моим участием 27 мая в 19:00 по Москве.

Тестирование документации: залог успешной разработки

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

Почему важно проверять документацию заранее?

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

Проверка требований до начала разработки помогает находить проблемы раньше, чем они превратятся в баги. Чем раньше найдёшь ошибку, тем меньше потом придётся исправлять. Это называется "Shift-Left Testing", что по сути означает — тестировать раньше, чтобы потом не было больно.

Вот какие проблемы можно найти на этом этапе:

• Противоречия в требованиях: например, в одном месте написано "сохранить данные", а в другом — "удалить данные". Так какой из них правильный?

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

• Отсутствие важных условий: что-то важное просто забыли описать, и программа не знает, что с этим делать.

• Ошибки в сценариях использования: не описаны крайние случаи, например, что делать, если пользователь ввёл неправильные данные.

Как можно тестировать требования?

Есть несколько способов проверить, что в документации нет ошибок:

• Формальная проверка: использование строгих правил, чтобы убедиться, что всё написано правильно.

• Чтение и обсуждение: собираемся, читаем вместе, обсуждаем и находим проблемы.

• Моделирование: создаём простые схемы, чтобы понять, как всё должно работать.

• Анализ текста с помощью ИИ: современные программы могут сами искать ошибки в тексте требований.

Что будет дальше?

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

Полезные материалы по теме:

• Тестирование требований — Teamlead Roadmap: Простое объяснение, зачем проверять требования перед началом разработки.

• Критерии качества требований с примерами — Habr: Примеры, как сделать документацию понятной и понятной для всех.

• Тестовая документация: что учитывать при постановке эффективного процесса тестирования — Habr: Как правильно описывать требования, чтобы не возникало путаницы.

• Роль формализации требований в тестировании программного обеспечения — КиберЛенинка: Почему важно прописывать требования максимально чётко.

• Тестирование требований — Особенности — Quality Lab: Как работают с требованиями на практике и какие ошибки бывают.

P.S.: а вот ссылка на мой блог в Telegram: https://t.me/it_vadimqa

Как начать практиковаться в тестировании без опыта

Если вы только что окончили курсы по тестированию, знаете теорию, но не имеете реальных кейсов — это нормально. Почти каждый начинающий QA-специалист сталкивается с вопросом: «Где набраться практики, если нет опыта?».

После тренировок в песочницах следующий шаг — попробовать себя в реальном проекте. Участие в open source — отличный способ получить настоящий опыт, поработать с командой и добавить первые кейсы в портфолио. Начать тестировать WordPress можно по простому и понятному алгоритму. Шаги для старта:

1. Установите WordPress локально.
   Самый простой способ — приложение LocalWP. Также подойдут Docker или XAMPP.

2. Разберитесь, как устроена работа.
   Загляните на make.wordpress.org — там есть разделы для разработчиков, дизайнеров, переводчиков и тестировщиков. Обратите внимание на Test Handbook — там подробно объясняется, как тестировать, искать баги и писать отчеты.

3. Найдите первую задачу.
   В баг-трекере Trac ищите задачи с меткой good-first-bug — они идеально подходят для старта. Прочитайте описание, повторите шаги и проверьте, воспроизводится ли баг.

4. Включайтесь в сообщество.
   Присоединяйтесь к чату #core-test в Slack (ссылка на подключение — в make.wordpress.org/test). Там обсуждают приоритетные задачи и проводят регулярные митинги. Новичкам всегда рады!

   

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

Как тестируют функцию Circuit Switched Fallback, которая помогает общаться с родственниками

Представим, что вы звоните семье со смартфона в 4G-сети. В вашей сети нет (или временно недоступна) поддержка голосового звонка через сеть 4G. Не имеет значения, в какой сети находится второе устройство.

Что происходит в сети оператора при таком звонке:

• Телефон отправляет на базовую станцию (eNB) вызов.

• Базовая станция связывается с ядром сети (MME) и запрашивает процедуру CSFB для исходящего звонка, дожидается от ядра сети подтверждения о возможности такого перехода.

• После этого отправляет телефону информацию о новом подключении к 2G-сети, которое он должен установить.

• После этого базовая станция завершает обслуживание абонента в 4G-сети, обслуживание переходит к станции 2G.

• Голосовой вызов осуществляется через 2G-сеть.

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

Симулятор позволяет автоматизировать этот этап тестирования и увеличить скорость тестов и повторяемость результатов. CSFB — это базовая функциональность, поэтому проверка проходит регулярно.

Для успешной проверки CSFB задачу декомпозируют, разделяют на уровни. О двух других ступенях «пирамиды» — тестировании в GSM-сети и системном тестировании — рассказала инженер YADRO Анастасия Беднова в своей статье.

Оплачиваемая стажировка Cloud.ru Camp — успей подать заявку до 12 мая 📢

Присоединяйся к Cloud.ru Camp — оплачиваемой стажерской программе, которая поможет студентам и начинающим специалистам прокачать скиллы и с головой погрузиться в IT-сферу. 

Ты можешь выбрать направления:

• Продуктовая разработка: DevOps или Golang.

• Кибербезопасность: мониторинг событий и автоматизация или сертификация программных продуктов.

• Команда внедрения: QA.

• Технические продажи: технический менеджер клиентов.

Что тебя ждет:

• оплачиваемая стажировка,

• работа в реальных проектах,

• поддержка наставников и экспертов,

• регулярная обратная связь.

А у лучших стажеров будет возможность попасть в штат Cloud․ru.

Прием заявок открыт до 16 мая включительно, а для прошедших все этапы отбора стажировка начнется 16 июня. Пройти стажировку можно очно в офисе Cloud.ru в Москве, а также удаленно из любой точки РФ. График гибкий — от 20 часов в неделю.

📬 Подать заявку на Cloud.ru Camp

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

Как тестировать фронтенд?

Для меня уже нет вопроса - нужны ли тесты на фронтенде? Личный опыт подсказал, что нужны, как и согласованный цельный подход к архитектуре. Тому есть несколько причин:

• Без unit-тестов и автоматических e2e-тестов ручное тестирование занимает много времени. К тому же человек, скорее всего, при регрессионном тестировании что-то пропустит, и баги попадут в production. Особенно это актуально для больших проектов с большой кодовой базой.

• Без автоматических тестов страшно рефакторить код. А если нет выстроенной архитектуры с соблюдением low coupling/high cohesion, то этот страх вполне оправдан. А без регулярного пересмотра кода приложение рано или поздно превратится в большой комок грязи.

• У unit-тестов есть интересный побочный эффект. Если пользоваться подходом TDD и писать тесты сразу вместе с кодом (и даже перед написанием кода), то качество модулей и архитектуры в целом повышается. Это происходит, потому что с позиции написания теста мы думаем не только о том, как нам побыстрее завершить работу над модулем, но и о том, как этот модуль будет выглядеть снаружи, удобно ли будет его использовать внутри других модулей, так как тест в этом случае служит ещё и образцом вызывающего модуля.

• Тесты - это дополнительная документация к коду. Причём такую документацию не получится держать в неактуальном состоянии, иначе упавшие тесты не пропустят код в production при наличии настроенного шлюза проверки качества в CI/CD пайплайне.

Это всё прекрасно и, как показывает практика, работает, как ожидается, но остаются вопросы.

• Как тестировать уровень представления приложения? Например, в случае с каким-нибудь фреймворком с использованием React это будут React-компоненты, виджеты, представляющие отдельные элементы пользовательского интерфейса. Тестировать там, по сути, нужно функцию. Передали ряд аргументов (пропсов или состояний) - получили одно представление. Передали другие аргументы - другое. Зависимость результата от набора аргументов - однозначная. Чтобы это проверить, можно использовать тесты со скриншотами. Я предпочитаю snapshot-тесты, они дают больше контроля, но работают довольно медленно и могут быть хрупкими, если недостаточно грамотно отделять слой представления от логики.

• А что со временем написания кода вместе с тестами? Будем ли мы вовремя успевать сдавать новые модули и радовать наших пользователей и руководство? Я думаю, что это не совсем правильные вопросы. Спрашивать надо о том, сколько будут стоить ошибки, попавшие на production из-за отсутствия тестов? Если ваше приложение - landing page с минимумом логики, то вряд ли цена ошибки будет высока. В небольшой кодовой базе её будет легко локализовать и исправить. А если вы работаете с финансами и у вас миллионы пользователей? В этом случае цена ошибки на production будет намного выше.

• Как донести необходимость тестов до команды и правильно включить автоматизацию тестирования в процесс разработки? Это на самом деле серьёзный вопрос. Не все разработчики понимают, зачем вообще тесты на фронтенде и обоснование их необходимости может вылиться в не слишком продуктивный холивар. А если продавливать такое решение сверху, то без понимания и принятия командой этого решения будут попытки обойти систему и снижение мотивации. Мне когда-то в подобной ситуации помогла практика парного программирования и выстраивание инженерной культуры в команде (совместное чтение технической литературы, архитектурные встречи с использованием white board).

А какие практики для тестирования применяете вы?

Проверяй, пока не поздно: функциональная верификация в жизненном цикле СнК

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

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

Время, необходимое для прохождения жизненного цикла СнК, зависит от команды и применяемых технологий. В индустрии считается, что эффективная работа означает выпуск нового тейп-аута (tape-out) раз в полгода. Это говорит о том, что процессы налажены и команда работает с высокой скоростью.

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

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

Тестировщики, общий сбор!

Мы часто видим исследования про разработчиков, продактов, аналитиков… А про QA? Почти ничего. Пора это исправить.   

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

• что нас радует и раздражает,

• какие инструменты и практики мы выбираем,

• как меняется наша роль и работа.   

Присоединяйтесь! Это важно и интересно 🔥

Пройти опрос → https://qa-25.testograf.ru

В анкете 45 вопросов, потребуется 15–20 минут времени. А среди всех участников разыграем оригинальный подарок. Доходи до конца и всё поймёшь:)

Тест на тестировщика: что в коробке?

Ответ: Это Shield box — экранированная коробка, внутри которой размещаются сотовые телефоны. Ее используют тестировщики телеком-оборудования. Коробка обеспечивает изоляцию сигнала и предотвращает возможность подключения сторонних абонентов к «тестовой» сети.

Если вы знакомы с этим оборудованием или хотите с ним познакомиться, вас могут заинтересовать несколько вакансий в команде Телекома в YADRO. 

→ Некоторые из них требуют образования по специальностям Радиотехнологии или Телекоммуникации и опыта работы с системами GSM/LTE. 

Test Engineer (LTE/GSM Radio Subsystem)

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

Field Test Engineer (LTE/GSM) 

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

→ А вот несколько вакансий, где глубокое знание телеком-технологий не является решающим фактором при отборе кандидатов. 

Test Engineer (Performance Test)

Команда занимается тестированием собственного железа и ПО. Направление создает конкурентную линейки RAN-продуктов для мобильных сетей последних поколений — базовые станции LTE/GSM и удаленные системы управления ими. Опыт работы с телекоммуникационными системами GSM/LTE будет преимуществом. 

QA Automation Engineer 

Команда ищет инженеров по автоматизированному тестированию в несколько команд в направление разработки решений для телекоммуникаций. Необходимый опыт в автоматизации с использованием Jenkins GitLab — от двух лет. Здесь ждут кандидатов с уверенным знанием Python, Linux и пониманием сетей, базирующихся на TCP/IP.

Test Engineer Manual 

Вам больше по душе ручное тестирование? Есть вакансия и для вас. Здесь ждут кандидатов с уверенным знанием теории тестирования (опыт — от трех лет), Linuх и пониманием сетей, базирующихся на TCP/IP.

О направлении 

Команда Телеком с нуля создает телекоммуникационные решения для беспроводных мобильных сетей и сопутствующих услуг. Инженеры разрабатывают первые в России базовые станции стандартов GSM/LTE, реализуя полный стек телекоммуникационных протоколов для базовых станций и элементов ядра сети, а также системы управления и мониторинга. Здесь вы будете в хорошей компании: продукт создают профессионалы с многолетним опытом, многие из них работали в ведущих мировых телекоммуникационных корпорациях.

А как тестируют функции базовой станции, читайте по ссылке → 

Друзья, ночи доброй.

Если позволите, вкратце о себе. Зовут меня Саней. Имею опыт в тестирование более 3-х лет. В послужном списке тестирования были desktop-приложения для операторов БПЛА, системы защиты информации, система кредитования физических лиц и многое другое.

В настоящий момент работаю в компании QA-специалистом и одновременно являюсь ментором для людей, решивших стать тестировщиками.

Имеется богатый опыт теории и практики в тестировании, а также есть желание поделиться с ним.

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

Всем огромное спасибо!

ИИ-агенты в Альфа-Банке: нейросети создают автотесты без участия человека

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

✨ Что умеют наши агенты?

🧠 Анализировать контекст из Jira и Confluence, вычленяя суть задачи.
🔍 Прогнозировать риски, зависимости и даже «пограничные» сценарии.
🛠️ Генерировать DTO для REST API и превращать ручные сценарии в Java-тесты за минуты.
✅ Сверять код с бизнес-логикой и техстандартами Альфы, защищая прод от случайных ошибок.
🌐 Создавать вариативные проверки — от позитивных кейсов до сложных негативных условий.
⚡ Автоматизировать рутину — и это лишь часть их скиллов.

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

«Одна команда ИИ-агентов экономит десятки часов работы, увеличивает скорость релизов и находит на 30% больше багов», — делится Святослав Соловьев, Директор по генеративному ИИ в ИТ Альфа-Банка.

🔜 Скоро расскажем подробнее — как устроены агенты, какие технологии behind the scene и как мы измеряем их эффективность. Оставайтесь с нами!

Дашборд — лицо системы: как сделать его удобным для команд из более 100 инженеров

Переосмысление дашборда стало одной из важных задач в процессе обновления интерфейса TMS TestY.

Разработчики сохранили общий принцип навигации после входа в приложение. Пользователь попадает на борду, где ему доступен переход на овервью, тестовые сьюты и тестовые планы. Сохранили возможность фильтрации по избранному, показ архива, статистику по проектам.

В Testy 2.0 можно выбрать, на каком языке будет работать система. Раньше интерфейс TMS был полностью англоязычным, теперь пользователям доступен русский язык — как часть плана поддержки локализации.

Добавили поиск по проектам и табличное представление, в котором доступно то же самое, что и на карточках: переходы, добавление в избранное, переключатели Only Favorites и Show Archive

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

Какие еще обновления появились в TMS с открытым исходным кодом, читайте в статье.

Зачем нужны юнит-тесты

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

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

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

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

Кстати, ИИ нынче отлично умеет писать тесты. И полезно не забывать про антипаттерны тестирования ПО.

«Слово о нагрузочном тестировании: курс на успешную миграцию»

📅 13 февраля, 16:00

А как тестируете вы?
📈13 февраля на онлайн-митапе обсудим преимущества и недостатки различных методов проведения нагрузочного тестирования. На примере реального кейса миграции СУБД представим нашу собственную методику оценки производительности информационных систем!

👨‍💻 Спикеры мероприятия:

— Роман Севрук, менеджер по развитию решений СУБД

— Александр Зубков, инженер по автоматизации нагрузочного тестирования

— Алексей Сатин, архитектор инфраструктурных решений

✅ Регистрируйтесь на онлайн-митап, чтобы узнать, как выбрать подходящий способ оценки производительности, минимизировать риски возникновения проблем и оптимизировать расходы на нагрузочное тестирование. 

Почему совершать ошибки — полезно: рассказывают наставники Практикума

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

Тест, который не работал
Рассказывает Дарина Кухтина, наставница на курсе «Аналитик данных»

Я руковожу отделом аналитики в мобильном геймдеве. Мы запустили А/В-тест для игровых автоматов, чтобы проверить разные расстановки. Более успешные слоты поставили в начало. 3а две недели эксперимента не произошло никаких изменений. 

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

Выводы:

• Нужно пользоваться своим продуктом: заходить на сайт или играть в игру, над которыми идет работа.

• Ошибка может быть в любом месте.

• Чем раньше заметить ошибку, тем лучше. Это экономит время, а время — деньги.

• Никому нельзя верить, даже себе.

Самокаты начали сигналить по всему городу
Рассказывает Андрей Шевченко, наставник на курсе «Инженер по тестированию»

Команда тестировала новую фичу для кикшеринга самокатов перед продакшном. Тогда мы не нашли одну из моделей самокатов и не перезапустили сервисы после доработки. 

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

Выводы:

• Команда всегда тебя поддержит.

• Если ты где-то облажался, то облажалась вся команда.

• Окружение важно! Покройте проверками максимум.

• Перезапускайте сервисы после обновлений.

• Ошибок не допускает только тот, кто ничего не делает.

Есть ли ошибка, которая помогла вам стать лучше? Расскажите об этом в комментариях.