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

Работать в одной команде много лет или менять их несколько раз в год

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

Постоянная смена команд вызывает чувство одиночества и отсутствия долгосрочных связей с коллегами

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

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

Когда работаешь в одной команде, можно решать более интересные задачи, чем когда всё время меняешь её

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

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

Работа в одной команде даёт больше чувства значимости в успехе продукта

Меняет команды: Конечно, потому что ты регулярно вносишь свою лепту. Но тут ещё важно, чтобы команда рассказывала о своих результатах и успехах, вакуума быть не должно, когда человек думает «У меня есть одна зона ответственности, а на другие даже не смотрю». Чтобы чувствовать свою значимость, тебе нужно хотя бы видеть продуктовые метрики фич.

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

Работа в одной команде может привести к выгоранию из-за однообразия

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

Я спасаюсь тем, что у меня много непроектных активностей, например, мероприятия и обучение.

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

Меняет команды: Главное не применять этот свежий взгляд резко и ультимативно, обрубая всё, что было до этого. Потому что всё новое — это стресс, и каким бы не был продукт, поначалу обновления будут тяжело и долго внедряться. 

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

Приходите послушать и посмотреть выпуск подкаста с Капой и Катей ➡️ YouTube, Rutube, VK, Яндекс Музыка.

ИИ против рутины: как изменится тестирование? Круглый стол на «Стачке»

2–3 октября в Санкт-Петербурге пройдёт XIV международная IT-конференция «Стачка», и мы рады сообщить, что Маргарита Трофимова, директор департамента тестирования и обеспечения качества ITFB Group, выступит модератором круглого стола «Применение ИИ в тестировании».

Маргарита — эксперт с более чем 17-летним опытом в области качества ИТ-систем, вице-председатель Russian Software Testing Qualification Board, спикер ведущих отраслевых конференций и идейный вдохновитель образовательного практикума «Академия тестирования».

На круглом столе вместе с представителями ДОМ.РФ, Альфа-Банка, Авито и других лидеров рынка участники обсудят, как искусственный интеллект трансформирует процессы тестирования, команды и бизнес-результаты.

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

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

📍 Санкт-Петербург
📅 2–3 октября
🔗 Конференция «Стачка»

👉 Принять участие

Привет!

Рады поделиться с сообществом отличной новостью: теперь Explyt доступен для скачивания с JetBrains marketplace.

Установить Explyt 4.2 с AI агентом для написания кода, тестирования и дебаггинга можно в один клик из вашей IDE (IntelliJ IDEA 2024.1+, PyCharm 2024.1+, GoLand 2024.1+).

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

Всем отличной пятницы 🖖

Специалист по ремонту компьютерного оборудования, моддер и видеоблогер VIK-on представил тестер оперативной памяти DDR5 для ноутбуков. Модуль выполнен в виде платы размером с плашку ОЗУ SO-DIMM и оснащён дисплеем для отображения ключевых параметров слота ОЗУ. Устройство способно отслеживать напряжение памяти и активность шины SPD, что позволяет понять — видит ли система установленные модули ОЗУ. Тестер оснащён специальной кнопкой, которая позволяет вывести на экран 5 последних POST-кодов (в настоящий момент эта функция доступна только на ноутбуках Asus на базе плат Quanta).

Нейросети в QA. Подборка важнейших кейсов применения.

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

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

Кейсы по использованию нейросетей в QA

1. Генерация тест-кейсов на основе требований

2. Подготовка позитивных и негативных тестовых данных

3. Адаптация и улучшение баг-репортов

4. Перевод сценариев в формат Gherkin (Given-When-Then)

5. Генерация идей для негативного тестирования

6. Автоматический анализ логов ошибок

7. Помощь в написании автотестов и шаблонов

8. Конвертация технической информации в пользовательские инструкции

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

10. Генерация финальных отчётов по тестированию

11. Помощь в написании автотестов: генерация кода, шаблонов и отдельных функций для фреймворков автоматизации

12. Подготовка баг-таблиц и чек-листов

13. Создание слайдов по итогам тестирования

14. Автоматическая сверка ожидаемого и фактического поведения

15. Генерация SQL-запросов на основе текстового запроса

16. Перевод технических отчётов для бизнес-аудитории

17. Проверка качества текста / интерфейса (UX-копирайтинг)

18. Генерация данных для нагрузочного тестирования

19. Сравнение версий документации / требований

20. Сбор фидбэка из отзывов пользователей (тематический анализ)

21. Создание чат-ассистента по документации и API

22. Анализ требований на предмет неясностей, противоречий и неполноты

23. Прогнозирование областей с высокой вероятностью дефектов

24. Оптимизация тестовых наборов (выявление избыточных тестов)

25. Генерация идей для тестов безопасности

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

Сегодня, 9 сентября, в мире ИТ вспоминают первый компьютерный баг

В 1947 инженеры Гарвардского Mark II под руководством Грейс Хоппер разбирались с поломкой реле. В какой-то момент они нашли причину — внутри застряла настоящая моль. Её аккуратно извлекли, приклеили в журнал отладки и подписали: «Первый реальный случай бага».

До этого слово “bug” использовали в инженерной среде, но именно этот случай сделал его легендой ИТ.

Забавно, что сама моль сохранилась — её до сих пор можно увидеть в Смитсоновском институте.

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

Вспомнить хотя бы Heartbleed — уязвимость в OpenSSL, обнаруженную в 2014-м. Одна ошибка в библиотеке, которая отвечает за шифрование, открыла доступ к памяти миллионов серверов по всему миру. Пароли, ключи, данные — всё оказалось под угрозой. В СМИ её называли «самым громким багом десятилетия».

Через несколько лет весь мир обсуждал уже Log4j. Казалось бы, скромная библиотека для логирования на Java, использующаяся в тысячах приложений. В декабре 2021 обнаружили, что через неё можно удалённо выполнить произвольный код. За считаные часы уязвимость стала глобальной катастрофой: под угрозой оказались банки, облачные сервисы и даже игровые платформы вроде Minecraft.

В обоих случаях баг оказался не меньше, чем та самая моль в реле. Только если в 1947-м инженер мог достать насекомое пинцетом и продолжить работу, то сегодня одна ошибка в коде способна обрушить бизнес-систему мирового масштаба.

И это, пожалуй, самое важное напоминание: в ИТ нет «мелких багов». Любая ошибка может стать той самой «молью», остановившей работу огромной машины.

А какой баг стал самым запоминающимся для вас?

Как строить эффективное тестирование ИИ-моделей в бигтехе?

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

За несколько лет прошел путь от линейного тестировщика до руководителя команды из 8 человек, и в этой статье рассказываю о своем опыте. О том, как:

• начал как единственный тестировщик ML-моделей в Альфа-Банке, совмещая функциональное и нагрузочное тестирование, что оказалось очень сложно из-за ограниченных ресурсов и растущего потока задач,

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

• столкнулся с выбором между кросс-функциональной командой и специализацией, 

• продумал подход к делегированию задач,

• начал автоматизацию тестирования на основе Postman-коллекций, Pytest и Allure, интегрированную в CI/CD через Jenkins и Airflow, что ускорило и упростило тесты…

Эта статья будет полезна:

• тем, кто только начинает выстраивать процессы тестирования моделей;
• начинающим тимлидам QA-команд до 10 человек;
• тем, кто просто хочет познакомиться с примером организации QA-процесса с нуля.

Читайте: Я управляю тестированием ИИ-моделей 4 года. Что я понял за это время?

25 бесплатных урока недели

2 сентября, вторник:

• 20:00 — Первый сайт за 60 минут: без ChatGPT и конструкторов

• 20:00 — CI/CD best practices

• 20:00 — Тестирование Spring приложений. Интеграционные тесты с контекстом. Тестирование слоя репозиториев и сервисов

• 20:00 — Место ClickHouse в System Design

• 20:00 — Архитектура MySQL-кластера в высоконагруженных системах

• 20:00 — Тестовые фреймворки: JUnit, TestNG и не только

3 сентября, среда:

• 19:00 — Как разбудить пассивных сотрудников и внедрить коллективную ответственность по стандартам PMP

• 19:00 — Основные управленческие отчёты разделов конфигурации 1С:ERP

• 20:00 — Интерфейсы в Golang изнутри

• 20:00 — PostgreSQL. Углубленный анализ производительности

4 сентября, четверг:

• 19:00 — Моделирование архитектуры в ArchiMate на основе Event Storming

• 19:00 — Продакт в эпоху AI: как не потерять работу и усилить себя

• 20:00 — Hello, Go! С нуля до первого кода за 1,5 часа

• 20:00 — Введение в технический анализ: построение торговой стратегии

• 20:00 — MLFlow - контроль над ML-экспериментами

• 20:00 — Работа с I/O в Си. Изучаем подсистему ввод-вывода

• 20:00 — Цифровое рабочее место. Стандартизация внутренних процессов

• 20:00 — Мониторинг PostgreSQL в Zabbix

• 20:00 — KPI для Delivery Manager: как измерить то, чего не видно

• 20:00 — Подключаем 1C:EDT к процессам непрерывной интеграции. Создаем первый пайплайн

• 20:00 — Java Generics в автоматизации тестирования: практическое применение в UI и API тестах

8 сентября, понедельник:

• 18:00 — Методы ансамблирования в ML, которые должен знать любой Data Scientist

• 20:00 — DWH, Data Lake и Data Lakehouse: архитектурные различия и практическое применение

• 20:00 — Архитектура сборщиков мусора: как найти компромисс между скоростью, памятью и паузами

• 20:00 — SQL объединяет: как подружить таблицы между собой

• 20:00 — Основы FastAPI

Новая глава в твоей QA-карьере может начаться через три, два, один… 

Как насчет того, чтобы сменить привычную тестовую среду на что-то новое? Например, на тестовый стенд с BBU, RRU, симулятором ядра сети и т. д. И сделать это еще до осенних холодов. 

Инженеры YADRO из дивизиона Телеком ищут коллег, которые присоединятся к тестировщикам-автоматизаторам. Нужны QА-инженеры с опытом работы в автоматизации тестирования от 2 лет и уверенным знанием Python. Приветствуется опыт работы с Linux и понимание сетей, базирующихся на TCP/IP. 

Поучаствовать в спринт-офере до 7 сентября → 

_____________________________________________________________

А чтобы узнать больше про тестирование в телекоме, изучите эти статьи: 

→ Какими инструментами пользуются в телекоме

→ Пример тестирования определенной функции в телекоме

→ Нестыдные вопросы про телеком

Продолжаем набор специалистов в ИТ-команду SSP SOFT

Привет Хабр! Уже конец лета и не пора ли серьезнее подумать о новой работе — а мы продолжаем нанимать. Предлагаем реальные задачи, прокачку скиллов и бенефиты «в рынке». Никакой бюрократии и скуки — мы нацелены на то, чтобы вы получали удовлетворение от работы.

✔️ Гарантируем интересные задачи
✔️ Для каждого нового сотрудника есть наставник
✔️ Центр компетенций помогает прокачивать навыки
✔️ С нами ты можешь работать из любой точки мира
✔️ Для экстравертов у нас есть офисы в Москве и Томске
✔️ Оптимальный Work Life Balance
✔️ ДМС со стоматологией, обучение от компании и бонусная программа.

📢 На этой неделе мы ищем (см. ссылки на описание вакансий у каждой позиции):

1️⃣ Ритейл-аналитика (http://vk.cc/cOMUS1)
2️⃣ Аналитика DWH (http://vk.cc/cOMUTJ)
3️⃣ Аналитика 1С (http://vk.cc/cOMUVn)
4️⃣ Тестировщика 1C (http://vk.cc/cOMUXx)
5️⃣ QA Auto Java (http://vk.cc/cOMUYQ)

👉 Не обязательно откликаться через hh — присылайте резюме напрямую нашему HR в Telegram: @sspsoft или на почту: job@ssp-soft.com.
Не забудьте сопроводительное письмо с фразой «Нашел вас на Хабр», чтобы резюме рассмотрели по-возможности быстрее.

Ждем вас в команду SSP SOFT!

Как проходит онбординг и рост новичков в HW QA

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

В первую неделю — оформление, знакомство с командой, лабораторией, стендами и процессами, закрепление ментора. За 14 дней — полное погружение в работу с BMC. В первый месяц поощряется командное взаимодействие. 

На 2–4 неделе — изучение Linux, устройства продуктов, компонентов, прошивок и инструментов, работа по чек-листам: запуск тестов, анализ результатов. Ко второму месяцу — доступ к целевой платформе, документации и задачам среднего приоритета. 

После адаптации определяется вектор роста и формируется индивидуальный план развития с обозначением компетенций и точек роста.

Сейчас команда ищет HW QA-инженера в департамент разработки аппаратных средств. Задачи — тестирование инженерных образцов, валидация компонентов, настройка стендов, автоматизация, работа с BIOS, BMC и прошивками.

Обновляем список актуальных вакансий в SSP SOFT

Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.

Рабочие места в офисах в Москве (отличная локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.

📢 Кого мы сейчас приглашаем (это описание вакансий в hh, а ниже прямые контакты с нашим HR для быстрого отклика):

1️⃣ Разработчика и аналитика 1C
2️⃣ Разработчика Angular
3️⃣ Middle Java Developer
4️⃣ Системного аналитика
5️⃣ Бизнес-аналитика

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

🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.

👉 В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.

Пишите с резюме нашему HR в Telegram: @sspsoft
Или присылайте резюме на почту: job@ssp-soft.com.

Всегда актуальные вакансии на https://hh.ru/employer/5648224:

📍 Мы открыты к диалогу и ценим честные и профессиональные резюме (без накруток опыта).

Почему мы подключаем QA с первого дня проекта

И как это экономит ресурсы, улучшает продукт и снижает количество переделок

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

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

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

Роль QA в нашей команде: не только тестирование

Наши QA участвуют в проекте с первых дней.

• Структурируют поступившее от заказчика ТЗ

• Выделяют функциональные блоки

• Формируют уточняющие вопросы

• Работают над схемами и диаграммами логики

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

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

QA плотно взаимодействуют с селлерами и лидами разработки и помогают им формализовать требования. Это снижает нагрузку на менеджеров и ускоряет проработку проекта.

Как это работает на практике

Заказчик приходит с ТЗ. Оно может быть подробным, а может состоять из тезисов, что хотелось бы реализовать в продукте.

1. QA разбивают информацию на структурные блоки — экраны, роли, сценарии, ограничения, точки перехода.

2. Составляют вопросы, которые передаются в команду, ответственную за коммуникацию с заказчиком.

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

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

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

Когда это спасло проект

Один из проектов, с которым мы работали, сопровождался очень подробным бизнес-ТЗ — документ содержал более 70 страниц описания сервиса. Всё выглядело детально и проработанно.

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

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

Внутренние процессы: как это устроено

Мы работаем по agile: QA входят в спринты наравне с разработкой. Внутри спринта QA выполняют не только тестирование, но и работу, близкую к системной аналитике:
анализ, структурирование, детализация, согласование требований, построение логики.

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

Зачем это заказчику

Когда QA работают с самого начала, заказчик получает

• Прозрачную архитектуру с понятной логикой

• Согласованные требования, переведённые в схемы

• Минимум доработок в процессе разработки

• Экономию времени — на исправление неочевидных ошибок

• Повышенное доверие команды к требованиям — все понимают, что делают и зачем

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

Что общего между Индией и Standoff Bug Bounty?

Standoff Hacks пройдет в Индии, и ты можешь полететь туда вместе с нами!

→ Во-первых, на нашей платформе активно багхантят ребята из Индии.
→ Во-вторых, наш следующий ивент Standoff Hacks пройдет 13 сентября в Ахмадабаде.
→ А в-третьих — у тебя есть шанс попасть на него за наш счет!

🔎 Для этого тебе нужно... Багхантить (surprise)! И набрать с момента публикации этого поста до 18 августа как можно больше баллов по этим публичным программам:

🔹 Timeweb

🔹 Rambler&Co

🔹 Инфосистемы Джет

🔹 Купер

🔹 Т-Банк

🔹 Wildberries

🔹 VK

🔹 Ozon

🔹 Мегамаркет

🔹 Craftum

Баллы по программам суммируются. Трех самых активных багхантеров мы возьмем с собой в Индию 🇮🇳

А дальше на Standoff Hacks тебя будут ждать:

• Эксклюзивный доступ к новому скоупу с огромными выплатами.

• Новые знакомства, крутая атмосфера и яркие впечатления.

• И бонусом — участие в конференции BSides Ahmedabad.

शुभकामनाएं। 🙏

P.S.: багхантеры, которые сдадут хорошие отчеты в Wildberries, получат приглашение в приватную программу от маркетплейса с эксклюзивным скоупом.

Тестируем микросервисное приложение с кучей интеграций — четыре совета из практики  

На одном из финтех-проектов наша команда тестирования столкнулась с серьезными вызовами: нестабильные партнерские API, отсутствие тестовых сред у партнеров, лимиты на запросы и риски всё сломать одним обновлением.

В этом посте — примеры, как команда с этим справилась и как можно поступить в похожих ситуациях. Эта подборка может сэкономить кому-то часы (а то и дни) работы.

🛠️ Внешние сервисы без тестовых контуров

Решение: собственный мок-сервис на основе WireMock.

Как он работает:

• тестировщик задает нужный ответ и отправляет его через HTTP-запрос в БД;

• нужные вызовы подменяются в конфигурации;

• при тестировании запрос уходит не во внешний API, а в мок, который отдает нужный ответ.

Моки у нас кастомные, конфигурируются через Swagger, и не завязаны напрямую на CI/CD — это упрощает запуск и дает гибкость.

Плюс: так мы не зависим от внешних API, которые то работают, то нет.

💸 Платные вызовы и лимиты на тестовые запросы

Решение: изолированные стенды и замещение моками везде, где возможно.

Если API-партнер дает 150 вызовов в месяц, а вам нужно 500 на автотесты — моки опять же спасают. Мы блокируем обращения к реальным API на командных стендах и заменяем их заглушками. Проверку живых интеграций оставляем только на пред-проде.

Плюсы:

• не сжигаем бюджет;

• эмулируем ошибки и нестандартные ответы;

• ускоряем тесты без зависимости от внешней стороны.

🔄 Нестабильность интеграционных тестов

Решение: изоляция и моки как защитный слой.

Микросервисная архитектура — это боль, когда один упавший сервис ломает релиз. Поэтому мы:

• эмулируем нестабильные вызовы моками;

• изолируем свою часть и фокусируемся на ее стабильности;

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

🤝 Десятки команд, завязанных на общий процесс

Решение: интеграционные проверки и ревью на совместимость.

Когда много команд делают один продукт, любое изменение может зацепить чужой модуль. Мы выстроили систему так, чтобы ошибки ловились до мерджа, а не после инцидента. Что помогло:

• общие тестовые фреймворки и единый подход к интеграционным тестам;

• сценарии, которые включают зависимости от других команд;

• проверка обратной совместимости: если что-то ломает чужой функционал — фича не проходит MR.

Подробнее о каждом из подходов читайте в статье QA-инженера AGIMA Святослава Волохова.

В SSP SOFT открыты новые вакансии в ИТ-команды: ищем мидлов, сеньоров и лидов

Мы в SSP SOFT — команда, которая занимается заказной разработкой и активно ведет проекты по модели ИТ-аутсорсинга. Наши специалисты помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.

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

Актуальные вакансии на https://hh.ru/employer/5648224, а прямая ссылка на контакт с нашим HR отделом ниже:

Аналитика и системный анализ
• Аналитик DWH
• Аналитик 1С (Регламентированный учет)
• Бизнес-аналитик (Промтех)
• Системный аналитик (ИБ)

Разработка
• Lead Python Developer
• Android-разработчик (Senior)
• Fullstack-разработчик (C#, React)
• Разработчик 1С (ЗУП)
• Разработчик Angular
• Разработчик MS SQL
• Data Engineer

Тестирование и поддержка
• Automation QA Engineer
• Automation QA Engineer (Python)
• Automation QA Engineer (Java)
• ITSM-инженер

Как мы подходим к найму:

В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.

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

🧭 Как устроен процесс найма и адаптации:

1️⃣ Собеседование с HR и руководителем направления,
2️⃣ Техническое интервью с нашими экспертами,
3️⃣ Индивидуальный план онбординга — с учетом ваших сильных сторон,
4️⃣ Испытательный срок — с поддержкой наставника,
5️⃣ Подключение к серьезным задачам — когда вы полностью готовы.

Пишите нашему HR в Telegram: @sspsoft
Или присылайте резюме на почту: job@ssp-soft.com.

📍 Мы открыты к диалогу и ценим честные и профессиональные резюме (без накруток опыта) с вами как потенциальными коллегами.

Как устроено тестирование телеком-продуктов

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

• Модульные (unit) и компонентные (component) тесты реализуют сами разработчики. Они позволяют проверить корректность работы отдельных модулей и компонентов на ранней стадии.

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

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

• Нагрузочное тестирование и тестирование стабильности позволяют оценить работу системы под высокой нагрузкой в течение длительного времени. Это важно для подтверждения отказоустойчивости и стабильной производительности.

Выделим полевое тестирование. Оно позволяет в реальных радиоусловиях с реальными абонентскими терминалами протестировать описанные выше процедуры. Для такого тестирования используется специальный автомобиль, в котором установлено оборудование для проведения drive-тестов.

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

В статье Ивана Политова и Антон Васина, инженеров из департамента разработки и проектирования опорной 5G-сети в YADRO, читайте подробнее, как в компании тестируют телеком-продукты.

10 задач, в которых AI действительно помогает QA-инженеру

Этот пост – саммари пилота нейросетей на реальном проекте. На тесте было несколько моделей: DeepSeek, Qwen, Gemma. 

Вот универсальный список задач по тестированию, с которым все они справляются хорошо:

– анализ логов и stack trace;
– поиск причин неочевидных ошибок в пайплайне;
– генерация SQL-запросов и объяснение незнакомых конструкций (например, JSONB);
– экранирование кавычек в больших XML-фрагментах;
– автоматическая генерация тест-кейсов из BPMN- или XML-схем;
– генерация случайных данных для теста;
– сравнение параметров (включая UTF-8 кодировку) при ошибках интеграции;
– проверка SQL-запросов, XSD (XML) и JSON-схем на соответствие структуре;
– подсказки по фиксам в случае ошибок, связанных с отсутствием логов;
– преобразование описаний ТЗ в чек-листы (но только если текст написан понятно и ТЗ описано подробно, подойдет не для всех и нужно внимательно ревьюить результаты);
– написание сниппетов для postman.

Вывод ожидаем: ИИ все еще не заменяет тестировщика, но ускоряет работу. Главное – не забывать проверять то, что получилось.

💬 А какие кейсы сработали у вас?

Проект Zero Day Initiative (ZDI) сообщил о проведении соревнований Pwn2Own Ireland 2025, которые состоятся в середине октября 2025 года в Ирландии. Участникам предложено продемонстрировать эксплоиты для ранее неизвестных уязвимостей (0-day) в смартфонах, мессенджерах, беспроводных точках доступа, устройствах для умного дома, принтерах, сетевых хранилищах, системах видеонаблюдения и устройствах виртуальной /дополненной реальности. Атака должна быть проведена на самые свежие программы и операционные системы со всеми доступными обновлениями и в конфигурации по умолчанию.

Мероприятие примечательно готовностью выплатить миллион долларов за выявление в мессенджере WhatsApp ошибки, позволяющей удалённо выполнить код без действия пользователя (0-click). За удалённо эксплуатируемую уязвимость в WhatsApp, требующую действий пользователя (1-click), премия составляет 500 тысяч долларов, за уязвимость, приводящую к захвату учётной записи - $150 тысяч, а за получение удалённого доступа к данным пользователя, микрофону или камере - $130 тысяч.

В категории "мобильные телефоны" за удалённую эксплуатацию уязвимости в смартфонах Google Pixel 9 и Apple iPhone 16 назначена премия 300 тысяч долларов. При этом введена новая категория - взлом устройства при подключении по USB c размером премии $75 тысяч. За удалённый взлом 3D-шлема Meta Quest 3/3S и умных очков Meta Ray-Ban назначено вознаграждение в $150 тысяч. Максимальный размер премии за взлом устройств умного дома и сетевых хранилищ составляет $50 тысяч, систем видеонаблюдения - $30 тысяч, а принтеров - $20 тысяч.

Привет! Ищу комьюнити тестировщиков. Готовлюсь к конференции и нужна ваша помощь) Исследую вопросы формального vs исследовательского тестирования. Не могли ли бы вы пройти короткий анонимный опрос на 5 минут. Помогите собрать стату и исполнить мечту :)

Про опрос: 13 вопросов на да/нет/наверно. Он опосредован и анонимен, даже я не вижу, кто его заполнял

https://docs.google.com/forms/d/e/1FAIpQLScD2teZDXmHdw5J0oGjDezalEZIC9uA1fSm6smoXREi2RVvKg/viewform?usp=sharing&ouid=100952938727951577109

От вибростендов до полевых испытаний: тесты Hardware QA в реальных условиях

Как понять, выдержит ли стойка или сервер поездку через всю страну в контейнере или грузовике? Чтобы проверить, готово ли оборудование к реальной транспортировке, команда HW QA использует целый комплекс инструментов и методов:

• Вибростолы воспроизводят типичные транспортные нагрузки — от тряски в грузовике до промышленных вибраций. Оборудование фиксируется на платформе, и на него подаются колебания заданной частоты, амплитуды и направления. Вибротесты стоек показывают, как сервера реагируют на тряску: анализ ускорения и спектр вибраций (частоты до 10–40 Гц).

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

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

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

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

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

Так появилось исследование тестировщиков 👇

Ещё можно углубиться в лендинг: https://qa-survey-2025.2gis.ru. Посмотреть разные цифры: собирали данные скрупулезно по профильным каналам, 1000 QA-инженеров начали опрос, 570 стойко ответили на все 45 вопросов!

К слову, и про статистику сбора данных: 37% тестировщиков проходили опрос на Android, 29% на iPhone, 23% на Windows, 9% на MacOS и даже 2% c Linux.

Заглядывайте и пишите, за что взгляд зацепился, обсудим!

Ozon Tech открыл сразу несколько вакансий для QA mobile

Если хотите тестировать продукт, которым пользуются миллионы, — этот пост для вас. 

У нас несколько сильных команд, и вы можете выбрать ту, где ваш опыт даст максимум результата:

1. Приложение Курьер и Работа

Будете тестировать сразу два приложения:

• Ozon Курьер Express помогает курьерам и водителям принимать экспресс-заказы и зарабатывать.

• Ozon Job — приложение для соискателей, где можно найти склад, записаться на смену, посмотреть выплаты и тарифы.

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

2. Приложение Ozon

То самое, которым пользуетесь вы, ваши друзья и соседи. Через него проходит >90% заказов. Вы будете тестировать UI, логику, аналитику и пуши, следить за стабильностью релизов и качеством пользовательских сценариев. У нас отлаженная инфраструктура: автоматизация, фермы с эмуляторами, симуляторами и реальными девайсами.

3. Мобильная платформа

Фундамент всех приложений Ozon: библиотеки авторизации, аналитики, performance-метрики.  Вы будете проверять их стабильность, писать автотесты и автоматизировать процессы. Команды Ozon используют эти библиотеки каждый день — и от их качества зависит работа всей мобильной разработки.

Что общего во всех командах:

— Кроссплатформенная автоматизация на Python и Appium. 

— Сложные, нетривиальные задачи — как в ручном тестировании, так и в автоматизации. 

— Фичи, которые вы тестируете, видят миллионы пользователей — включая ваших друзей и родных. 

Выбирайте продукт и откликайтесь на сайте. 

🔗 Другие вакансии в Ozon Tech

Использование случайностей в функциональном тестировании

Для кого эта статья?

• Инженеры по автоматизации и разработчики тестов — вам точно будет интересно.

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

А кого, возможно, не заинтересует

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

Откуда вообще эта идея?

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

На первый взгляд — всё логично. Но на практике:

• увеличивается время прогона (особенно для UI-тестов);

• растёт вероятность нестабильности (flaky-тесты);

• тесты зачастую дублируют поведение друг друга.

Наглядный пример

Допустим, у нас есть UI-тест, проверяющий переходы по меню на сайте. Стартовая страница содержит меню для перехода на страницы A, B, C, D.

Сценарий теста:

1. Открываем стартовую страницу.

2. Выбираем пункт в меню.

3. Проверяем, что оказались на нужной странице.

Что делает большинство:

• Пишут четыре теста: переход на A, на B, на C и на D.

• Или параметризуют тест: гоняют один и тот же сценарий с разными входными.

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

Проблема

Если тест проверяет функциональность, то логично оставить один вариант— переход на страницу A. Экономите ресурсы, всё стабильно и функциональность проверяется. Но однажды приходит тимлид с вопросом:

Почему тесты не поймали баг с переходом на страницу D?

В этом случае экономия не оправдалась

Что делать?

Тест — это тоже код. Он может быть не стабильным. И чем чаще он запускается, тем быстрее мы понимаем, стабилен он или нет.

А теперь возвращаемся к примеру с меню:

Что, если каждый раз случайным образом выбирать один из пунктов (A, B, C, D)?

• Экономим ресурсы: запускается один тест вместо четырёх.

• С течением времени мы случайным образом "покроем" все пункты.

• Чем чаще прогоняются тесты, тем быстрее мы обнаружим баг (например, если страница C не открывается).

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

Это не ноу-хау

Такой подход давно известен — он называется property-based testing.

Как пример - фреймворк Hypothesis, который позволяет генерировать данные автоматически и находить пограничные случаи, о которых вы даже не думали.

Что важно помнить

• Использование случайности не должно усложнять тест. Логика должна быть понятна и читаема.

• Если тест упал, он должен сообщить, что именно пошло не так, даже если данные были сгенерированы случайно.

• Рандомизация — всего лишь один из способов сделать тесты более эффективными, но это не универсальное решение

• Иногда стоит логировать/фиксировать сгенерированные данные, особенно при падении теста — чтобы потом воспроизвести баг

Итог

Рандомизация в тестировании — мощный инструмент:

• помогает экономить ресурсы;

• расширяет покрытие;

• стимулирует стабильность и надёжность тестов.

Но применять её стоит с умом: понимать, зачем, где, и в каком объёме.

А как у вас это устроено? Используете ли вы property-based подход в тестах? Или всё ещё параметризуете всё подряд? Буду рад услышать ваши мнения, кейсы и даже критику.

One Day Offer для разработчиков, аналитиков, тестировщиков 1С от Ozon Tech

Сразу 9 команд в поиске специалистов, которые уже проектировали и внедряли 1С-решения в крупных IT-компаниях. Получить оффер в Ozon Tech можно всего в 3 шага.
1С в Ozon — не просто ещё одна платформа. Это система учёта ведущего e-com России с охватом в 10 стран. В ней всё — от тарифов для селлеров из Еревана до графика работы ПВЗ в Караганде. 

Кто нам нужен? 
Опытные специалисты с глубокой экспертизой — разработчики, тестировщики, аналитики.
Вакансии открыты в 9 команд, и во всех — нешаблонные задачи на пределе возможностей 1С.
Подать заявку до 15 июля. 

Как всё пройдёт?
Онлайн и по расписанию. Даты интервью можно изменить по договорённости.
17.07 — знакомство с командами в формате презентации и Q&A — до 30 минут.
18.07 — техническое интервью, основанное на реальных задачах — 60-90 минут.
19.07 — финальное интервью с тимлидом — до 60 минут.

Почему стоит участвовать?
Во-первых, потому что мы — Ozon Tech, наши проекты вдохновляющие и перспективные, а условия — на высшем уровне бигтеха.

Во-вторых, в таком формате вы получаете максимум результата при минимальных затратах, как временных, так и эмоциональных: мы сократили 1 этап интервью и с оффером вернемся в день проведения финального интервью. 

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

Присылайте его сюда, как закончите: https://s.ozon.ru/WfnJy67

Два «крита» в Windows: как эксперты Positive Technologies спасли мир миллионы устройств

Лето 2025 года началось с неприятного сюрприза для пользователей Windows — Microsoft экстренно выпустила патчи для двух опасных уязвимостей, найденных исследователями из Positive Technologies. Обе баги могли привести к серьезным последствиям: от краха системы до полного захвата контроля над компьютером. 

VHD-файл как билет в админ-клуб 

💥 Недостаток безопасности CVE-2025-49689 получил оценку 7,8 балла по шкале CVSS 3.1. 

Сергей Тарасов, руководитель группы анализа уязвимостей в экспертном центре безопасности Positive Technologies (PT Expert Security Center, PT ESC) Positive Technologies обнаружил, что злоумышленник может получить полный контроль над вашим компьютером, если вы откроете специально подготовленный виртуальный диск (VHD). 

📌 Как это работает? Вам присылают «безобидный» VHD-файл (например, якобы архив с документами). Вы его открываете — и вуаля, злоумышленник уже админ в вашей системе.

📌 Где прячется угроза? В драйвере файловой системы NTFS. Затронуты Windows 10, 11 и серверные версии.

Статистика страха: Таких уязвимых устройств в сети — 1,5+ миллиона, больше всего в США и Китае. 

У Сергея есть подробная статья на эту тему в блоге команды PT SWARM.

📌 Что делать? 

• Срочно обновиться. 

• Не открывать VHD-файлы от неизвестных отправителей. 

Один клик — и система падает

💥 Уязвимость CVE-2025-49686 получила 7,8 балла по шкале CVSS 3.1 и затронула 17 операционных систем

Марат Гаянов (эксперт из PT ESC) нашел другую проблему: если запустить вредоносную программу, можно положить всю систему. 

📌 Суть бага: Ошибка в сетевом драйвере приводит к краху Windows. 

📌 Чем опасно? Представьте: сотрудник открывает «документ», и вся корпоративная сеть ложится. 

 ⚠️ Особо опасен для компаний — атака не требует прав админа. 

📌 Что делать? 

• Опять же — обновить Windows. 

• Использовать средства защиты для управления уязвимостями и EDR-решения для обнаружения атак. 

Positive Technologies vs Microsoft: из истории борьбы с багами 

Это не первый случай, когда российские эксперты помогают Microsoft закрывать дыры: 

• 2019 — обнаружили две критические уязвимости, дающие доступ к данным (CVE-2019-0726 и CVE-2019-0697). 

• 2024 — нашли баг, позволяющий стать админом (CVE-2024-43629).  

Вывод

Если вы еще не обновили Windows — сделайте это прямо сейчас. А если ваш IT-отдел говорит «и так сойдет», покажите им эту статью. 😉 

P.S. Интересно, сколько еще таких багов плавает в Windows?..

Бесплатные курсы Route 256 от Ozon Tech для QA-инженеров

Route 256 — это 2 месяца онлайн-вебинаров и воркшопов от команды экспертов Ozon Tech. Программа состоит преимущественно из практики на базе реальных задач бигтеха, что помогает студентам получить уверенный опыт в автотестировании на Python.

Этим летом Route 256 открывает набор в направлении QA Automation на Python для middle- и junior-специалистов. Занятия проходят вечером, поэтому курсы удобно сочетать и с учёбой, и с работой.

3 августа состоится отборочный контест для поступления на курс. Он будет включать алгоритмические задачи и тест. Ученики middle-направления по окончании курса могут получить оффер в команду, а junior-участники — приглашение на оплачиваемую стажировку.

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

• Регистрация для уровня middle

• Регистрация для уровня junior

Присоединяйтесь к публичной программе Bug Bounty Альфа-Банка на платформе BI.ZONE

Теперь у багхантеров есть возможность протестировать сервисы Альфа-Банка на предмет уязвимостей и получить вознаграждение. Размер вознаграждения зависит от критичности найденной уязвимости.

Максимальная сумма вознаграждения составляет 400 тысяч рублей.

Альфа-Банк выплачивает вознаграждение за выявление разных уязвимостей, таких как:

• удалённое выполнение кода (Remote Code Execution, RCE),

• проблемы контроля доступа (Broken Access Control, IDOR, Broken Session Management), 

• ошибки аутентификации и авторизации (Missing Authorization, Improper Authorization), 

• захват учётной записи (Account Takeover), 

• раскрытие конфиденциальной информации (Sensitive Data Exposure) и многих других.

Для исследования доступны веб- и мобильные приложения сервисов Альфа-Онлайн, Альфа-Инвестиции, Альфа-Бизнес и другие ресурсы.

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

Ресурс Counterpoint Research раскрыл, как Apple тестирует свои гаджеты в различных условиях, включая климатические тесты, водные тесты, краш‑тесты и вибрационные тесты.

Климатические тесты проводятся, чтобы устройства выдерживали разные погодные условия. В лаборатории Apple их подвергают воздействию соли в течение 100 часов, яркого света, а также пыли из пустыни Аризоны, чтобы проверить, как песок влияет на динамики или порты зарядки. Для AirPods даже создают искусственный пот и ушную серу, чтобы смоделировать реальные условия.

Водные испытания Apple проводит для проверки защиту от воды и пыли по стандартам IP. Например, iPhone 16 Pro имеет рейтинг IP68 — это высший уровень защиты, который означает полную устойчивость к пыли и способность работать после погружения в воду на глубину до 6 метров в течение часа.Тесты начинаются с простого сымитированного «дождя», затем устройства обливают водой под давлением и погружают в воду в специальных резервуарах. Apple также тестирует устройства на устойчивость к другим жидкостям, например, газировке, сокам, солнцезащитному крему и духам.

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

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

Представлен обновлённый проект 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).

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