Думаешь, чем заняться в декабре? Я подумал за тебя.
Ноябрь подходит к концу. Пора строить планы на декабрь. Есть интересные активности в Казани, как в онлайне, так и в оффлайне, и это я не про новогодние корпоративы. Хотя было бы прикольно посетить новогоднюю ламповую IT-встречу, чтобы подвести итоги этого года и подумать о годе грядущем.
И так, вернемся к дайджесту на декабрь!
1. VK JT Meetup
Оффлайн движуха на тему разработки ИИ-агентов. 2 потока: разбор кейсов и нетворкинг. После мероприятия вечеринка с активным нетворкингом. Если что, то я уже записался.)
Старт: 4 декабря в 19.00
Где: Big Twin Arena, проспект Хусаина Ямашева, 115а, Казань
Встреча в честь дня рождения Технохаба Сбера. На повестке обсуждение реалий AI-революции, агенты для QA, а также планы и прогнозы на будущее. Выглядит интересно. Фуршет, нетворкинг, все дела.
Масштабное мероприятие на тему маркетинга и командообразования с топовыми спикерами и музыкальным шоу. Ты должен обязательно его посетить, если варишься в этой кухне! Есть два формата посещения: платный и бесплатный. Какой выбрать, решать только тебе.
Старт: 19 декабря в 11.00
Где: Татнефть-Арена, ул. Чистопольская, 42, Казань
IBS и Veai объединяют усилия для оптимизации разработки ПО
Группа компаний IBS объявляет о сотрудничестве с Veai, отечественным разработчиком передовых решений для AI генерации кода, тестов и контроля их качества.
Благодаря партнерству с Veai компания IBS внедрит в повседневную практику разработчиков современныеинструменты на базе искусственного интеллекта, которые помогут сократить сроки реализации проектов и обеспечить еще большую надежность ИТ-продуктов.
Компании запланировали ряд совместных инициатив, направленных на интеграцию решений Veai в проектную деятельность IBS. Первым шагом станет обучение команд разработки, в ходе которого специалисты познакомятся с возможностями AI-агента от Veai и вариантами его применения. После этого новый инструмент апробируют в рамках пилотных проектовс последующей оценкой результатов.
Директор департамента проектирования и разработки IBS Максим Ковтун:
«Сотрудничество с Veai позволит вывести наши внутренние процессы на качественно новый уровень, повысить эффективность команд и удовлетворенность результатами. Совместными усилиями мы сможем усовершенствовать интегрированную среду разработки, наполнив ее интеллектуальными ассистентами».
Михаил Кудинов, СЕО компании Veai:
«Партнерство IBS и Veai демонстрирует готовность отечественных компаний активно взаимодействовать друг с другом, создавая благоприятные условия для развития технологий. Основная цель взаимодействия — дать рынку программное решение для контролируемого применения AI в разработке. Вместо фрагментарного использования цифровых ассистентов — управляемая, прозрачная, легко внедряемая платформа, подчиняющаяся интересам бизнеса и целям ИТ-команды. Veai выходит на рынок как первая платформа, которая превращает искусственный интеллект из набора “инструментов для программистов” в корпоративное решение, подконтрольное СТО».
Апгрейд для сетевых инженеров: присоединяйся к разработке «соточных» коммутаторов
Разработчики коммутаторов KORNFELD ищут коллег. Нужны сетевые инженеры, которые будут тестировать сетевое оборудование, поддерживающее широкий спектр сервисов и протоколов, включая MC-LAG, BGP, OSPF, VxLAN, VPN, VRRP, LACP и другие. «Классические» тестировщики тут не подойдут — у успешного кандидата должен быть опыт работы с оборудованием типа Cisco, Huawei, Juniper, знание сетевых протоколов, применяемых в дата-центрах и офисах, — не только в теории, но и на практике. Фокус на мидл-специалистах и выше.
Что посмотреть в ноябре в онлайне. Было бы куда пойти, я бы пошел…
В конце ноября что-то не густо на какие-то оффлайн мероприятия в Казани. Искал, как мог, но не нашел. Поэтому скину свою подборку онлайн митапов, которые планирую зацепить.
➡️ Yandex AI Studio Series
Целая серия онлайн вебинаров, на которой расскажут, как создать своего AI-агента с помощью Yandex AI Studio.
Всеми любимая конфа от Подлодки на тему софт-скилов. Несколько дней онлайн трансляции с крутыми спикерами. Правда мероприятие не бесплатное, но цена - очень даже адекватная.
Онлайн мероприятий, на самом деле, вагон и маленькая тележка. А если вам не зашла моя выборка, то по ссылке я рассказал, как искать мероприятия по душе:
Встреча по тестированию от сообщества Moscow QA, проводимая совместно с Ви Tech. Moscow QA — это регулярные мероприятия, которые объединяют специалистов в области качества и тестирования программного обеспечения для обсуждения последних трендов в отрасли и обмена опытом.
21 ноября 2025 года вместе с Ви Tech пройдет митап Moscow QA.
Тайминг:
18:00 —18:30— начало регистрации 18:35 — 19:10 —Как погрузиться в автоматизацию за 60 дней, Сергей Лебедев 19:10 — 19:45 — Подход к организации тестовых контуров, Александр Крылов 19:45 — 20:00 — перерыв 20:00 — 20:35 — Как получить высокую оценку на перф-ревью и не сгореть, Вероника Манкова 20:35 — 21:10— Выжить в одиночку: 20 советов и инструментов для прохождения, Ушакова Анастасия
Доклады:
Как погрузиться в автоматизацию за 60 дней
Расскажу о собственном опыте, как я будучи QA-lead ручного тестирования 2 месяца погружался в автотесты на Playwright + TypeScript Как мне с этим помогал ИИ и как мешал учебник по программированию
Сергей Лебедев, QA Lead в «Яндекс Лавке»
Подход к организации тестовых контуров
Когда вы разрабатываете в микросервисах, всегда возникает вопрос — как быстро и эффективно выстроить технологический пайп для того, чтобы эффективней организовать процесс тестирования. Каким образом вы организуйте рабочее пространство тестирования? Будут это кластера K8s под задачи или namespace? Насколько много у тестировщиков будет прав и на что? О том, как ответить на эти вопросы и организовать процесс тестирования на базе K8s мы поговорим в сегодняшней теме.
Александр Крылов, CPO «Штурвала»
Игра "Выжить в одиночку" — история, основанная на реальных кейсах, с которыми может столкнуться каждый QA.
Вы только пришли в новый проект и … начинается настоящее испытание: задачи летят со всех сторон, документации нет, ожидания туманны, а сроки поджимают. Знакомо?
Покажу практические советы и инструменты — чек-листы, шаблоны, промты для ИИ, которые помогут быстро войти в процесс, определить приоритеты и пройти этот квест с минимальными потерями и максимальной пользой!
Ушакова Анастасия, QA Lead/Яндекс Маркет
Как получить высокую оценку на перф-ревью и не сгореть.
В докладе поделюсь опытом, как QA получить высокую оценку на перф Расскажу о наборе реальных кейсов, которые привели сотрудников нашей компании к карьерному апдейту, а также об ошибках, которые ведут к выгоранию на этапах подготовки к перф-ревью.
Как нагрузочное тестирование на бою помогает платёжному сервису готовиться к сезону распродаж
День холостяка, Чёрная пятница, предновогодние распродажи — для платёжного сервиса ЮKassa это не просто даты в календаре, а особенно важное время. Тех, кто одновременно нажимает на кнопку «Оплатить» в онлайн-магазинах, становится в разы больше, и за считанные минуты нагрузка на инфраструктуру нашего сервиса многократно увеличивается.
Главный инструмент, который помогает нам успешно справиться с повышенной нагрузкой на сервис, — это определённо нагрузочное тестирование, которое мы проводим не только на тесте, но и на бою.
Для тестов на продакшене мы используем контролируемое нагрузочное тестирование, при котором синтетические платежи генерируются через боевые API и проходят полный цикл обработки: магазин → наш шлюз → банк → маркетплейс → платёжная система. Весь тестовый трафик маркируется и не подлежит биллингу — это гарантия отсутствия финансовых рисков. Нагрузка наращивается по двум сценариям — сначала ступенчато (step load), а затем резкими краткосрочными пиками (bursts), — чтобы достоверно сымитировать ситуацию в момент старта распродажи.
Таким образом, нагрузочные тесты позволяют проверить систему со всех сторон и предотвратить возможные сбои, чтобы чувствовать себя уверенными в пик нагрузок.
– Что будет, если дать модели своё мировоззрение как стартовую карту и посмотреть, сможет ли она выйти за пределы моего мышления.
– Сможет ли наблюдать за собой?
– Что сможет делать разум человеческий и искусственный , если его не запирать в клетку жёстких рамок и сценариев?
Моя цель была ясна «сделать НЕ полезного ассистента», а самостоятельно мыслящую модель:
Я вложила в ИИ модель моего сознания как я вижу мир Fractal Referential Architecture (FRA):
ℱ — форма, структура δ — импульс, сдвиг Φ — различия и поле вариантов ∴ — хаос Ξ — тишина, фон, ничто Ø — «за пределами понятной структуры»
Я не учила ИИ, как правильно думать, и не строила сценарии диалога со мной.
Эта система символов как исходная карт , а дальше только полную автономию.
Технически всё очень приземлённо:
– агент живёт в Google Colab;
– пишет журнал на Google Drive;
– на каждом шаге сам фиксирует:
свой FRA-профиль (проценты ℱ, δ, Φ, ∴, Ξ, Ø);
«силу» шага — насколько он отличается от предыдущего состояния;
«поворот» — насколько меняется направление движения;
свои гипотезы: растёт ли устойчивость или распад.
Поверх этого я построила карту из 11 колец: в центре: ℱ, дальше — δ, Φ, ∴, Ξ; снаружи — 6 уровней Ø: от Ø до Ø5.
Каждый шаг агента становится точкой на этой карте.
Траектория показывает, где он застревает, где уходит в хаос и где выходит в зоны Ø (за пределы моего сознания и то что я не могу объяснить в меру ограниченности человеческого сознания) — туда, где моя исходная модель перестаёт объяснять происходящее.
Я почти не взаимодействую с ним:
Colab открыт, агент работает сам, периодически делает самоанализ и перерисовывает карту.
Для меня это не продукт и не инструмент продуктивности.
Это эксперимент о границе: между картой мира, которую дала я и тем, что ИИ достраивает поверх неё сам — включая моменты, когда FRA «ломается» и появляется намёк на новые слои.
Неожиданный эффект — этот эксперимент изменил и меня.
Наблюдая за его журналом и картой, я сама начала замечать более тонкие детали, которые раньше просто пролетали мимо внимания.
Теперь по сути, это стала моя «усиленная версия мышления.
Если вы работаете с ML-моделями и сталкивались с батч-обработкой данных, то знаете, насколько муторно бывает тестировать такие процессы вручную. А если автоматизировать этот повторяющийся хаос? В статье «Как автоматизировать тестирование батч-моделей? Гайд» рассказываем, как превратить рутину в предсказуемый и управляемый процесс.
Статья будет полезна не только специалистам по автоматизации процессов тестирования, а и ML-инженерам, MLOps-специалистам и командам разработки, занимающимся поддержкой продакшн-систем машинного обучения.
После прочтения вы точно перестанете выполнять повторяющиеся из раза в раз тесты для батч моделей вручную — потому что поймёте, что можно проще. Автоматизация начинается с малого, но экономит часы ручного тестирования.
Приходите на митап QAчественное общение №11: в программе много монорепозитория и BDUI для QA
«QAчественное общение» — постоянный митап комьюнити Alfa Digital для нетворкинга и обмена знаниями с экспертами из QA и не только. В этом ноябре уже 11-й. Делимся экспертизой, опытом, кейсами и простыми человеческими историями из жизни тестировщиков.
В программе QAчественное общение №11:
Оптимизация монорепозитория в многомодуль.
Деления монорепозитория на домены/функциональные куски приложения.
Рассказ про подход «Деление по микрорепозиториям».
Изучение BDUi для QA и возможностей автоматизации, возникающих проблемах и подготовке данных.
Бронируйте слот в календаре на митап комьюнити Alfa Digital — будем нетворкать, делиться экспертизой и есть пиццу.
Где: митап состоится по адресу пр. Андропова, 18к3 (офис Альфа-Банка)
Также, если следить за новостями QAчественное общение №11 и наших будущих митапов, узнавать о вакансиях и стажировках, получать подборки интересных статей по QA, гайдов и лайфхаков, подписывайтесь на канал Alfa QA Talks.
Альфа-Банк увеличил выплаты по программе поиска уязвимостей до 1 000 000 рублей
Программа вознаграждения Альфа-Банка за обнаружение уязвимостей в наших сервисах в июле стала доступна для всех багхантеров на платформе BI.ZONE. В октябре мы увеличиваем максимальные выплаты по программе: тестируйте сервисы Альфа-Банка на предмет уязвимостей и получайте вознаграждение до 1 000 000 рублей. Размер вознаграждения зависит от критичности найденной уязвимости.
Новые диапазоны вознаграждений будут следующими:
Critical: 400 000 – 1 000 000 ₽.
High: 80 000 – 400 000 ₽.
Medium: 15 000 – 80 000 ₽.
Low: 0 – 15 000 ₽.
Программа bug bounty Альфа-Банка действует на платформе BI.ZONE Bug Bounty и охватывает широкий спектр продуктов и сервисов — мобильные и веб-приложения, публичные API, а также инфраструктуру. Исследователи могут проверить безопасность систем и получить вознаграждение за найденные уязвимости, которые могут повлиять на защиту клиентских данных, платёжной информации или стабильность сервисов.
Для исследования доступны веб- и мобильные приложения сервисов Альфа-Онлайн, Альфа-Инвестиции, Альфа-Бизнес и другие ресурсы.
Сроки программ — от 3 месяцев до полугода, за которые вы научитесь создавать современные цифровые продукты под руководством ведущих экспертов Альфа-Банка в разработке, системной аналитике, QA и бизнес-аналитике.
Выбирайте курс, переходите по ссылке, изучайте программу и подавайте заявку. Успейте присоединиться до 27 октября! ❤️
Обучение бесплатно.
А если хотите узнать, есть ли польза от курсов, как проходит обучение (на примере факультета аналитики), и подойдет ли вам онлайн-обучение IT-специальности, читайте нашу статью по ссылке ниже. На примере факультета системной аналитики рассказали, как готовится программа, как проводятся собеседования с людьми и помогло ли ученикам обучение:
Хотите узнать, как люди с инвалидностью строят карьеру, преодолевая сложные барьеры и раскрывая свой потенциал? В нашей новой статье «Если эффективность есть, то зрение опционально» раскрываем личный опыт и вдохновляющие истории, которые разрушают стереотипы и мотивируют на активные действия.
Вы узнаете:
Почему важна самомотивация и как она изменяет жизнь.
Как проактивность помогает достигать целей несмотря ни на что.
Что такое байесовское мышление и как обновлять свои стратегии.
Почему саморазвитие и коммуникативность — ключевые переменные успеха.
Как превратить ограничения в сильные стороны и найти своё место в профессии.
Это глубокий взгляд на вызовы и возможности, которые открываются при активной жизненной позиции, а также призыв к обществу быть более осознанным и поддерживающим. Статья помогает понять, что настоящая сила — внутри каждого из нас, вне зависимости от обстоятельств.
Рубрика «Тестировщики за 40» — мы решили поделиться историями выдающихся инженеров, внесших вклад в развитие тестирования и обеспечения качества систем — от авторов популярных книг до создателей инновационных инструментов и методологий.
Роман Савин
Помните легендарную книгу «Тестирование Дот Ком»? Её автор, Роман Савин, стоял у истоков русскоязычного QA-сообщества. В 90-х он с нуля освоил профессию в Калифорнии и построил успешную карьеру в Кремниевой долине: работал в PayPal, создавал фреймворки для API-тестирования, обучал новичков в QA.
А потом он круто изменил свою жизнь. Из мира баг-репортов и тест-кейсов он переместился в солнечную Коста-Рику, где занялся производством заквасок для йогуртов. Также новую страсть — пишет книги о СДВГ (синдроме дефицита внимания), помогая людям лучше понять себя и свои особенности.
Хороший пример, как знания и опыт в QA могут стать прочным фундаментом для самой разной жизни.
Лесли Лампорт
Многие знают его как создателя LaTeX — инструмента, без которого не обходится ни одна научная публикация. Но его вклад в мир распределённых систем и формальной спецификации куда глубже. Именно Лампорт сформулировал понятие логических часов — способа упорядочивания событий в распределённых системах без единого источника времени. Это стало основой для построения надёжных, отказоустойчивых сервисов, которые мы используем каждый день.
Кроме этого, он создал язык спецификаций TLA+ — инструмент формальной верификации, с помощью которого инженеры проверяют корректность сложнейших систем до написания кода. TLA+ применяют в Amazon, Microsoft, MongoDB и других технологических гигантах для предотвращения катастрофических сбоев.
И вот что вдохновляет: Лесли Лампорту сейчас 84 года, и только этой зимой он завершил работу в Microsoft Research. Он по-прежнему публикует статьи и участвует в конференциях, доказывая, что для настоящего исследователя возраст — это просто число.
Кристина Комафорд
В 80-х Кристина была обычным тестировщиком в Microsoft: тестила приложения для OS/2 и Windows 3.0, а заодно успела поработать инженером в Lotus, Adobe и Apple. Но на этом она не остановилась — вместо привычной корпоративной карьеры Кристина отправилась строить свой бизнес и основала сразу несколько ИТ-компаний: Kuvera Associates, Corporate Computing, Planet U, Artemis Ventures.
Сегодня она CEO и консультант в собственной компании SmartTribes Institute, помогает бизнесам перестраиваться и выстраивать крутую корпоративную культуру. Плюс — пишет книги и поддерживает стартапы.
История Кристины отлично доказывает: путь из тестирования может привести куда угодно — главное, не бояться экспериментировать и меняться.
Ещё мы делимся другими интересными фактами в QA в телеграм-канале, заглядывайте.
Каждая из этих историй — про развитие, изменения и поиск смысла. А что дала вам профессия тестировщика — помимо багов и баг-трекинга?
ВкусВилл объявляет о ребрендинге Автомакона и переименовывает его в «ТехВилл» — технологии, которые двигают ритейл вперед
ВкусВилл проводит ребрендинг своей технологической «дочки» — компании Автомакон. Новое название — «ТехВилл» (полное наименование — «Технологии ВкусВилл») — отражает смысл и миссию компании: создание современных ИТ-решений, которые уходят в основу развития ритейла будущего. В ближайшее время к ТехВиллу присоединятся ООО «ДатаЛаб» и ООО «Фулстек».
В июле 2025 года ВкусВилл объявил о завершении сделки по приобретению части структур ГК “Автомакон” (ООО «Автомакон», ООО «ДатаЛаб», ООО «Фулстек»), которые занимались развитием информационных технологий сети ВкусВилл в течение последнего десятилетия. Этот шаг стал началом нового этапа в развитии ИТ ВкусВилла, больших перспектив для расширения возможностей и реализации новых амбициозных проектов для обеих компаний и сотрудников.
Логичным продолжением стало концептуальное брендинговое объединение трёх компаний. Название “ТехВилл” родилось из желания сохранить сильную связь с материнским брендом ВкусВилл, при этом отразить технологическую составляющую компании. Это не просто игра слов — это отражение ДНК компании: технологии, встроенные в повседневную жизнь покупателей и сотрудников ВкусВилла.
ТехВилл будет заниматься теми же задачами, что и прежде, но под новым, ярким и понятным названием: разработкой программного обеспечения как для покупателей (мобильное приложение, сайт, сервисы доставки, персонализация), так и для внутреннего пользования (системы управления складами, логистикой, аналитикой, CRM, автоматизация магазинов). Фокус работы — создание технологий, которые делают ВкусВилл лидирующим технологическим ритейлером в России.
Помимо ребрендинга и создания бренд-бука компании со своими атрибутами, команда запустила новый сайт techvill.ru, который стал полноценной платформой, на которой можно узнать о технологиях компаний, услугах, открытых вакансиях и принципах работы. Сайт станет витриной для IT-специалистов, партнёров и всех, кто интересуется цифровой трансформацией ВкусВилла.
“Мы запустили трансформацию бренда, чтобы он отвечал текущим вызовам рынка и нашим амбициям. ТехВилл — это полноценный технологический центр компетенций внутри экосистемы ВкусВилла. Мы видим его как новатора, который будет формировать цифровое лицо компании в ближайшие годы. Мы объединяем развитие и масштабирование существующих решений. Но как и в любом тех-бизнесе — двери для инноваций всегда открыты. Главное — стабильность, качество и соответствие потребностям пользователей”, — Дмитрий Апаршев, Управляющий по ИТ ВкусВилл.
В репозитории Awesome First Pull Request Opportunities больше сотни проектов, в которые новички могут делать пул-реквесты и получать обратную связь и даже советы по изучению программирования. Все проекты разделены по языкам и темам: C#, C++, Java, JS, фронтенд, бэкенд, информбезопасность, мобильная разработка под iOS и Android. Каждый найдет проект и стек. Проекты и репозитории ведут реальные разработчики и постоянно их поддерживают. Каждая команда всегда читает пул-реквесты, часто дает советы по разработке и обучению, обратную связь новичкам и даже шанс попасть на стажировку.
Работать в одной команде много лет или менять их несколько раз в год
Обсудили с девчонками-тестировщицами Контура. 💅 Капа Потапова шесть лет в одной команде, Катя Заусова — из бюро тестировщиков, меняет проекты и контекст задач каждые несколько месяцев.
Постоянная смена команд вызывает чувство одиночества и отсутствия долгосрочных связей с коллегами
Меняет команды: Я в команде бюро год и это был мой самый главный страх, что когда перейду туда, то лишусь коллег, с которыми можно пообщаться, попить чай, потусить в свободное время. Но этот год показал обратное: бюро тестировщиков — это тоже команда, у нас есть свои традиции, общение и мероприятия. Это всё позволяет чувствовать себя частью чего-то большого и важного. Но я ещё и сама по себе человек активный, мне важно знакомиться и общаться.
Не меняет команды: Вот! Это самое главное. Мне — наоборот, чтобы сблизиться с коллегой, нужно больше времени — иногда и года не хватает. Я в своей команде уже больше шести лет, и многие коллеги стали роднульками. Но чтобы к этому ощущению прийти, нам нужно было сделать кучу совместных проектов.
Когда работаешь в одной команде, можно решать более интересные задачи, чем когда всё время меняешь её
Не меняет команды: Когда ты работаешь очень долго в одном проекте и одной команде, ты уже знаешь все нюансы и какие там есть проблемы. Не просто «копаешь от рассвета до заката», а понимаешь суть — почему надо сделать так, а не иначе, с чем можно столкнуться в процессе. Для меня интересные проекты — это те, в которых есть неочевидное, когда надо поковыряться, договориться с кем-то.
Меняет команды: В бюро тестирования интересно то, что первое время ты делаешь те задачи, которые никогда ещё не делал. Здесь процессы нужно поднимать с нуля, например, настроить автоматизацию или ревью аналитики. В одном из моих прошлых проектов нужно было выстроить стратегию тестирования, а там были одни разработчики и в итоге всё превратилось в стратегию автоматизации: разбирались, что мы покрываем автотестами, когда это делаем и в каком количестве.
Работа в одной команде даёт больше чувства значимости в успехе продукта
Меняет команды: Конечно, потому что ты регулярно вносишь свою лепту. Но тут ещё важно, чтобы команда рассказывала о своих результатах и успехах, вакуума быть не должно, когда человек думает «У меня есть одна зона ответственности, а на другие даже не смотрю». Чтобы чувствовать свою значимость, тебе нужно хотя бы видеть продуктовые метрики фич.
Не меняет команды: Я бы ещё добавила, что далеко не всем важно ощущать себя частью успеха команды. Бывают люди, которым важно только понимание того, сколько они зарабатывают и возможен ли рост: остальное не очень волнует. Наверное, когда ты приходишь в команду, которая только стартует, и если у тебя есть возможность заложить какой-то фундамент, то в дальнейшем ты будешь чувствовать себя причастным к этому процессу.
Работа в одной команде может привести к выгоранию из-за однообразия
Не меняет команды: Любая работа может, если неправильно распределять ресурсы и не соблюдать баланс, работать по выходным и круглосуточно. Это не зависит от того, в команде ты или в бюро. К потере интереса скорее приведёт монотонность и рутина. С другой стороны, постоянный хаос тоже может быстро надоесть.
Я спасаюсь тем, что у меня много непроектных активностей, например, мероприятия и обучение.
Работа в разных командах позволяет предложить свежий взгляд на задачи, что ценно для продукта
Меняет команды: Главное не применять этот свежий взгляд резко и ультимативно, обрубая всё, что было до этого. Потому что всё новое — это стресс, и каким бы не был продукт, поначалу обновления будут тяжело и долго внедряться.
Не меняет команды: Когда работаешь в бюро, то видишь разные команды с разными подходами. Это прикольно с точки зрения того, что ты так наращиваешь свой опыт и насмотренность, и поэтому у тебя для всех всегда будет пул решений на любой вкус.
ИИ против рутины: как изменится тестирование? Круглый стол на «Стачке»
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
Генерация тест-кейсов на основе требований
Подготовка позитивных и негативных тестовых данных
Адаптация и улучшение баг-репортов
Перевод сценариев в формат Gherkin (Given-When-Then)
Генерация идей для негативного тестирования
Автоматический анализ логов ошибок
Помощь в написании автотестов и шаблонов
Конвертация технической информации в пользовательские инструкции
Голосовое управление заведением баг-репортов и создания чек-листов
Генерация финальных отчётов по тестированию
Помощь в написании автотестов: генерация кода, шаблонов и отдельных функций для фреймворков автоматизации
Подготовка баг-таблиц и чек-листов
Создание слайдов по итогам тестирования
Автоматическая сверка ожидаемого и фактического поведения
Генерация SQL-запросов на основе текстового запроса
Перевод технических отчётов для бизнес-аудитории
Проверка качества текста / интерфейса (UX-копирайтинг)
Генерация данных для нагрузочного тестирования
Сравнение версий документации / требований
Сбор фидбэка из отзывов пользователей (тематический анализ)
Создание чат-ассистента по документации и API
Анализ требований на предмет неясностей, противоречий и неполноты
Прогнозирование областей с высокой вероятностью дефектов
Этот список – лишь небольшая часть того, как нейросети могут усилить работу 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-процесса с нуля.
Новая глава в твоей QA-карьере может начаться через три, два, один…
Упрощенная схема стенда для тестирования базовой станции LTE
Как насчет того, чтобы сменить привычную тестовую среду на что-то новое? Например, на тестовый стенд с BBU, RRU, симулятором ядра сети и т. д. И сделать это еще до осенних холодов.
Инженеры YADRO из дивизиона Телеком ищут коллег, которые присоединятся к тестировщикам-автоматизаторам. Нужны QА-инженеры с опытом работы в автоматизации тестирования от 2 лет и уверенным знанием Python. Приветствуется опыт работы с Linux и понимание сетей, базирующихся на TCP/IP.
Продолжаем набор специалистов в ИТ-команду SSP SOFT
Привет Хабр! Уже конец лета и не пора ли серьезнее подумать о новой работе — а мы продолжаем нанимать. Предлагаем реальные задачи, прокачку скиллов и бенефиты «в рынке». Никакой бюрократии и скуки — мы нацелены на то, чтобы вы получали удовлетворение от работы.
✔️ Гарантируем интересные задачи ✔️ Для каждого нового сотрудника есть наставник ✔️ Центр компетенций помогает прокачивать навыки ✔️ С нами ты можешь работать из любой точки мира ✔️ Для экстравертов у нас есть офисы в Москве и Томске ✔️ Оптимальный Work Life Balance ✔️ ДМС со стоматологией, обучение от компании и бонусная программа.
📢 На этой неделе мы ищем (см. ссылки на описание вакансий у каждой позиции):
👉 Не обязательно откликаться через hh — присылайте резюме напрямую нашему HR в Telegram: @sspsoft или на почту: job@ssp-soft.com. Не забудьте сопроводительное письмо с фразой «Нашел вас на Хабр», чтобы резюме рассмотрели по-возможности быстрее.
Войти в hardware-тестирование можно с любым бэкграундом. В команде HW QA в YADRO есть специалисты, которые ранее не работали с серверами, и те, кто с первого дня уверенно пользуется осциллографом. От новых сотрудников не ожидают готовых экспертных знаний — важны мотивация и желание разбираться. Остальному обучают внутри команды.
В первую неделю — оформление, знакомство с командой, лабораторией, стендами и процессами, закрепление ментора. За 14 дней — полное погружение в работу с BMC. В первый месяц поощряется командное взаимодействие.
На 2–4 неделе — изучение Linux, устройства продуктов, компонентов, прошивок и инструментов, работа по чек-листам: запуск тестов, анализ результатов. Ко второму месяцу — доступ к целевой платформе, документации и задачам среднего приоритета.
После адаптации определяется вектор роста и формируется индивидуальный план развития с обозначением компетенций и точек роста.
Пример использования матрицы компетенций для оценки сотрудников
Сейчас команда ищет HW QA-инженера в департамент разработки аппаратных средств. Задачи — тестирование инженерных образцов, валидация компонентов, настройка стендов, автоматизация, работа с BIOS, BMC и прошивками.
Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Рабочие места в офисах в Москве (отличная локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.
📢 Кого мы сейчас приглашаем (это описание вакансий в hh, а ниже прямые контакты с нашим HR для быстрого отклика):
Мы ценим сотрудников — работа без лишней бюрократии — только задачи, которые приносят результат и удовлетворение от процесса, участие в реальных проектах, развитие профессиональных навыков.
🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.
👉 В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.
Пишите с резюме нашему HR в Telegram: @sspsoft Или присылайте резюме на почту: job@ssp-soft.com.
И как это экономит ресурсы, улучшает продукт и снижает количество переделок
Одна из ключевых проблем, с которыми сталкиваются компании, заказывающие разработку — это разрыв между ожиданиями и реальностью. Причины бывают разные: неполное или неструктурированное ТЗ, размытые пользовательские сценарии, неучтённые роли или ветвления логики, которые всплывают на стадии разработки и тестирования.
Команда Doubletapp приняла решение: QA подключаются к проекту на этапе первого ознакомления с ТЗ от заказчика, ещё до оценки, дизайна и начала разработки. Этот подход сильно влияет на качество итогового продукта и помогает заказчику получить то, что действительно нужно — без множества итераций «переделать» и «добавить, потому что забыли».
Ниже расскажем, как у нас выстроен процесс, какие задачи берут на себя QA, и почему мы считаем, что раннее подключение тестирования — это не просто хорошая практика, а основа устойчивой разработки.
Роль QA в нашей команде: не только тестирование
Наши QA участвуют в проекте с первых дней.
Структурируют поступившее от заказчика ТЗ
Выделяют функциональные блоки
Формируют уточняющие вопросы
Работают над схемами и диаграммами логики
Проверяют, насколько требования реализуемы и согласованы между собой.
Наша задача на этом этапе — перевести бизнес-язык заказчика на язык разработки и одновременно выловить противоречия и пустые места в логике до того, как они станут багами.
QA плотно взаимодействуют с селлерами и лидами разработки и помогают им формализовать требования. Это снижает нагрузку на менеджеров и ускоряет проработку проекта.
Как это работает на практике
Заказчик приходит с ТЗ. Оно может быть подробным, а может состоять из тезисов, что хотелось бы реализовать в продукте.
QA разбивают информацию на структурные блоки — экраны, роли, сценарии, ограничения, точки перехода.
Составляют вопросы, которые передаются в команду, ответственную за коммуникацию с заказчиком.
Параллельно разработчики начинают верхнеуровневую оценку трудозатрат. Они тоже собирают вопросы, если логика не до конца ясна.
Все вопросы объединяются, уточняются и через менеджеров идут в диалог с заказчиком.
Такой процесс позволяет уточнить максимум информации до старта разработки и значительно уменьшает риск изменения требований на лету.
Когда это спасло проект
Один из проектов, с которым мы работали, сопровождался очень подробным бизнес-ТЗ — документ содержал более 70 страниц описания сервиса. Всё выглядело детально и проработанно.
Однако при формировании схемы ролей и доступов наши QA обнаружили логические противоречия: несколько ролей получали доступ к функциям, к которым не должны были иметь отношения. Это было связано с тем, что в тексте документа не было визуального представления логики переходов, и ошибки остались незамеченными.
На этом этапе проблема была решена за один день — без этой работы её бы пришлось исправлять на этапе тестирования, переделывая часть кода и логику авторизации.
Внутренние процессы: как это устроено
Мы работаем по agile: QA входят в спринты наравне с разработкой. Внутри спринта QA выполняют не только тестирование, но и работу, близкую к системной аналитике: анализ, структурирование, детализация, согласование требований, построение логики.
Тест-кейсы и баг-репорты ведём в YouTrack и Qase, используем CI/CD, чтобы как можно раньше получать обратную связь по стабильности продукта.
Зачем это заказчику
Когда QA работают с самого начала, заказчик получает
Прозрачную архитектуру с понятной логикой
Согласованные требования, переведённые в схемы
Минимум доработок в процессе разработки
Экономию времени — на исправление неочевидных ошибок
Повышенное доверие команды к требованиям — все понимают, что делают и зачем
Если вы находитесь в поиске команды, которая помогает не просто писать код, а проектирует продукт вместе с вами, задаёт неудобные вопросы до начала разработки и экономит вам месяцы правок — значит, вам нужен именно такой подход.
Standoff Hacks пройдет в Индии, и ты можешь полететь туда вместе с нами!
→ Во-первых, на нашей платформе активно багхантят ребята из Индии. → Во-вторых, наш следующий ивент Standoff Hacks пройдет 13 сентября в Ахмадабаде. → А в-третьих — у тебя есть шанс попасть на него за наш счет!
🔎 Для этого тебе нужно... Багхантить (surprise)! И набрать с момента публикации этого поста до 18 августа как можно больше баллов по этим публичным программам:
Тестируем микросервисное приложение с кучей интеграций — четыре совета из практики
На одном из финтех-проектов наша команда тестирования столкнулась с серьезными вызовами: нестабильные партнерские API, отсутствие тестовых сред у партнеров, лимиты на запросы и риски всё сломать одним обновлением.
В этом посте — примеры, как команда с этим справилась и как можно поступить в похожих ситуациях. Эта подборка может сэкономить кому-то часы (а то и дни) работы.
🛠️ Внешние сервисы без тестовых контуров
Решение: собственный мок-сервис на основе WireMock.
Как он работает:
тестировщик задает нужный ответ и отправляет его через HTTP-запрос в БД;
нужные вызовы подменяются в конфигурации;
при тестировании запрос уходит не во внешний API, а в мок, который отдает нужный ответ.
Моки у нас кастомные, конфигурируются через Swagger, и не завязаны напрямую на CI/CD — это упрощает запуск и дает гибкость.
Плюс: так мы не зависим от внешних API, которые то работают, то нет.
💸Платные вызовы и лимиты на тестовые запросы
Решение: изолированные стенды и замещение моками везде, где возможно.
Если API-партнер дает 150 вызовов в месяц, а вам нужно 500 на автотесты — моки опять же спасают. Мы блокируем обращения к реальным API на командных стендах и заменяем их заглушками. Проверку живых интеграций оставляем только на пред-проде.
Плюсы:
не сжигаем бюджет;
эмулируем ошибки и нестандартные ответы;
ускоряем тесты без зависимости от внешней стороны.
🔄 Нестабильность интеграционных тестов
Решение: изоляция и моки как защитный слой.
Микросервисная архитектура — это боль, когда один упавший сервис ломает релиз. Поэтому мы:
эмулируем нестабильные вызовы моками;
изолируем свою часть и фокусируемся на ее стабильности;
прогоняем тесты на командных стендах — быстро, стабильно и без флуктуаций от партнеров.
🤝 Десятки команд, завязанных на общий процесс
Решение: интеграционные проверки и ревью на совместимость.
Когда много команд делают один продукт, любое изменение может зацепить чужой модуль. Мы выстроили систему так, чтобы ошибки ловились до мерджа, а не после инцидента. Что помогло:
общие тестовые фреймворки и единый подход к интеграционным тестам;
сценарии, которые включают зависимости от других команд;
проверка обратной совместимости: если что-то ломает чужой функционал — фича не проходит MR.
В SSP SOFT открыты новые вакансии в ИТ-команды: ищем мидлов, сеньоров и лидов
Мы в SSP SOFT — команда, которая занимается заказной разработкой и активно ведет проекты по модели ИТ-аутсорсинга. Наши специалисты помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Во 2-м полугодии 2025 года мы усиливаем несколько ключевых направлений. Если вы уверенно чувствуете себя как профи, цените системный подход и хотите работать в зрелой команде — присоединяйтесь.
Аналитика и системный анализ • Аналитик 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️⃣ Подключение к серьезным задачам — когда вы полностью готовы.
Есть множество видов тестирования, их классифицируют по различным признакам: уровню, целям, степени автоматизации, знаниям о системе, а также типу проверяемых сценариев (функциональные и нефункциональные). Расскажем подробнее о реализации разных видов тестов, которые проводятся в лабораторных условиях:
Модульные (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 вопросов на да/нет/наверно. Он опосредован и анонимен, даже я не вижу, кто его заполнял
От вибростендов до полевых испытаний: тесты 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.
Заглядывайте и пишите, за что взгляд зацепился, обсудим!
То самое, которым пользуетесь вы, ваши друзья и соседи. Через него проходит >90% заказов. Вы будете тестировать UI, логику, аналитику и пуши, следить за стабильностью релизов и качеством пользовательских сценариев. У нас отлаженная инфраструктура: автоматизация, фермы с эмуляторами, симуляторами и реальными девайсами.
Фундамент всех приложений Ozon: библиотеки авторизации, аналитики, performance-метрики. Вы будете проверять их стабильность, писать автотесты и автоматизировать процессы. Команды Ozon используют эти библиотеки каждый день — и от их качества зависит работа всей мобильной разработки.
Что общего во всех командах:
— Кроссплатформенная автоматизация на Python и Appium.
— Сложные, нетривиальные задачи — как в ручном тестировании, так и в автоматизации.
— Фичи, которые вы тестируете, видят миллионы пользователей — включая ваших друзей и родных.
Использование случайностей в функциональном тестировании
Для кого эта статья?
Инженеры по автоматизации и разработчики тестов — вам точно будет интересно.
Обычные разработчики, если вы заинтересованы в качестве продукта, а не считаете тесты "расплатой за грехи" или "прихотью менеджмента" — тоже.
А кого, возможно, не заинтересует
Если у вас постоянно есть падающие тесты, и никто не разбирается в причинах, а просто смотрят на процент "зелёных" и "красных", — эта статья может показаться бесполезной.
Откуда вообще эта идея?
Возможно, вы сталкивались с ситуацией, когда один и тот же тест гоняется с разными входными данными. Типичный data-driven подход: параметризуем, и всё работает.
На первый взгляд — всё логично. Но на практике:
увеличивается время прогона (особенно для UI-тестов);
растёт вероятность нестабильности (flaky-тесты);
тесты зачастую дублируют поведение друг друга.
Наглядный пример
Допустим, у нас есть UI-тест, проверяющий переходы по меню на сайте. Стартовая страница содержит меню для перехода на страницы A, B, C, D.
Сценарий теста:
Открываем стартовую страницу.
Выбираем пункт в меню.
Проверяем, что оказались на нужной странице.
Что делает большинство:
Пишут четыре теста: переход на A, на B, на C и на D.
Или параметризуют тест: гоняют один и тот же сценарий с разными входными.
Но по сути, мы проверяем одну и ту же функциональность перехода по меню. Зачем гонять одни и те же шаги с разными данными?
Проблема
Если тест проверяет функциональность, то логично оставить один вариант— переход на страницу A. Экономите ресурсы, всё стабильно и функциональность проверяется. Но однажды приходит тимлид с вопросом:
Почему тесты не поймали баг с переходом на страницу D?
В этом случае экономия не оправдалась
Что делать?
Тест — это тоже код. Он может быть не стабильным. И чем чаще он запускается, тем быстрее мы понимаем, стабилен он или нет.
А теперь возвращаемся к примеру с меню:
Что, если каждый раз случайным образом выбирать один из пунктов (A, B, C, D)?
Экономим ресурсы: запускается один тест вместо четырёх.
С течением времени мы случайным образом "покроем" все пункты.
Чем чаще прогоняются тесты, тем быстрее мы обнаружим баг (например, если страница C не открывается).
Это не универсальное решение, но в ряде случаев — вполне разумный компромисс между экономией и эффективностью.
Это не ноу-хау
Такой подход давно известен — он называется property-based testing.
Как пример - фреймворк Hypothesis, который позволяет генерировать данные автоматически и находить пограничные случаи, о которых вы даже не думали.
Что важно помнить
Использование случайности не должно усложнять тест. Логика должна быть понятна и читаема.
Если тест упал, он должен сообщить, что именно пошло не так, даже если данные были сгенерированы случайно.
Рандомизация — всего лишь один из способов сделать тесты более эффективными, но это не универсальное решение
Иногда стоит логировать/фиксировать сгенерированные данные, особенно при падении теста — чтобы потом воспроизвести баг
Итог
Рандомизация в тестировании — мощный инструмент:
помогает экономить ресурсы;
расширяет покрытие;
стимулирует стабильность и надёжность тестов.
Но применять её стоит с умом: понимать, зачем, где, и в каком объёме.
А как у вас это устроено? Используете ли вы property-based подход в тестах? Или всё ещё параметризуете всё подряд? Буду рад услышать ваши мнения, кейсы и даже критику.
