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

Встреча сообщество Moscow QA #17 x Ви Tech

Встреча по тестированию от сообщества 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 получить высокую оценку на перф
Расскажу о наборе реальных кейсов, которые привели сотрудников нашей компании к карьерному апдейту, а также об ошибках, которые ведут к выгоранию на этапах подготовки к перф-ревью.

Вероника Манкова, Qa Lead в Ви.Tech

Следите за нашими анонсами в информационных каналах: telegram и telegram chat , а так же ЮТУБ

Как нагрузочное тестирование на бою помогает платёжному сервису готовиться к сезону распродаж

День холостяка, Чёрная пятница, предновогодние распродажи — для платёжного сервиса ЮKassa это не просто даты в календаре, а особенно важное время. Тех, кто одновременно нажимает на кнопку «Оплатить» в онлайн-магазинах, становится в разы больше, и за считанные минуты нагрузка на инфраструктуру нашего сервиса многократно увеличивается.

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

Для тестов на продакшене мы используем контролируемое нагрузочное тестирование, при котором синтетические платежи генерируются через боевые API и проходят полный цикл обработки: магазин → наш шлюз → банк → маркетплейс → платёжная система. Весь тестовый трафик маркируется и не подлежит биллингу — это гарантия отсутствия финансовых рисков. Нагрузка наращивается по двум сценариям — сначала ступенчато (step load), а затем резкими краткосрочными пиками (bursts), — чтобы достоверно сымитировать ситуацию в момент старта распродажи.

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

Более подробно о боевых стрельбах рассказываем в большой статье.

Всем привет!

Как автоматизировать тестирование батч-моделей?

Если вы работаете с ML-моделями и сталкивались с батч-обработкой данных, то знаете, насколько муторно бывает тестировать такие процессы вручную.
А если автоматизировать этот повторяющийся хаос? В статье «Как автоматизировать тестирование батч-моделей? Гайд» рассказываем, как превратить рутину в предсказуемый и управляемый процесс.

Статья будет полезна не только специалистам по автоматизации процессов тестирования, а и ML-инженерам, MLOps-специалистам и командам разработки, занимающимся поддержкой продакшн-систем машинного обучения.

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

Приходите на митап QAчественное общение №11: в программе много монорепозитория и BDUI для QA

«QAчественное общение» — постоянный митап комьюнити Alfa Digital для нетворкинга и обмена знаниями с экспертами из QA и не только. В этом ноябре уже 11-й. Делимся экспертизой, опытом, кейсами и простыми человеческими историями из жизни тестировщиков. 

 В программе QAчественное общение №11:

• Оптимизация монорепозитория в многомодуль.

• Деления монорепозитория на домены/функциональные куски приложения.

• Рассказ про подход «Деление по микрорепозиториям».

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

Бронируйте слот в календаре на митап комьюнити Alfa Digital — будем нетворкать, делиться экспертизой и есть пиццу. 

Где: митап состоится по адресу пр. Андропова, 18к3 (офис Альфа-Банка)

Когда: 13 ноября, 18:30.

Формат: офлайн и онлайн.

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

Также, если следить за новостями QAчественное общение №11 и наших будущих митапов, узнавать о вакансиях и стажировках, получать подборки интересных статей по QA, гайдов и лайфхаков, подписывайтесь на канал Alfa QA Talks.

Тестирование требований — это не про поиск багов в коде. Это процесс проверки того, насколько сами требования корректны, полны и понятны.

Зачем это вообще нужно?

Ошибки в требованиях → баги в реализации → потери времени и денег.

Тестирование требований позволяет:

• Выявлять дефекты до этапа кодинга

• Экономить время команды

• Делать ожидания всех сторон прозрачными

• Повышать качество продукта без доработок «в последний момент»

Как понять, что требование хорошо сформулировано:

Какие техники тестирования требований использовать?

Взаимный просмотр
Показываем свою работу коллегам

Вопросы
Уточняем у заказчиков и коллег

Тест-кейсы и чек-листы
Прорабатываем набор вопросов для проверки требований

Рисунки
Наглядно представляем приложение

Прототипирование
Делаем наброски интерфейса и переходов между экранными формами

Исследование поведения системы
Мысленно моделируем работу пользователя с системой

Как проверить количество и атомарность?

1. Делаем блок-схему, чтобы увидеть дубли и лишние шаги

2. Проверяем, что требование описывает Create / Read / Update / Delete / List

3. При помощи сценария использования проверяем, что требование покрывает весь путь пользователя

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

5. Ищем отсылки на неопределенную информацию — если есть «и т.д.», «как обычно», стоит уточнить

6. Проверяем на союз «и» — часто он объединяет в одном требовании сразу два, а иногда и больше

Как проверить выполнимость и однозначность?

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

Что важно:

• Терминология

• Отсутствие качественных определений

• Простое изложение

• Возможность составить набор тестов

• Тестирование внешних сервисов

Как проверить актуальность и последовательность?

Если требование забыли, потеряли или поняли не так — беда в процессе.

На что обращаем внимание:

• Одно требование описано в одном месте

• Есть user story или хотя бы сценарий использования

• У автора требований есть знание предметной области

• Учтены интересы всех пользователей

• Договоренности из чатов перенесены в документацию

• Согласована дата последнего обновления требований и документации

Хорошие требования — это результат не только опыта, но и осознанной практики.

Альфа-Банк увеличил выплаты по программе поиска уязвимостей до 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, а также инфраструктуру. Исследователи могут проверить безопасность систем и получить вознаграждение за найденные уязвимости, которые могут повлиять на защиту клиентских данных, платёжной информации или стабильность сервисов.

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

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

Открываем набор на бесплатное обучение по IT-направлениям по программе Альфа-Будущее Кампус

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

• QA

• Android-разработка

• Бизнес-анализ

• Системный анализ

Сроки программ — от 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. Каждый найдет проект и стек. Проекты и репозитории ведут реальные разработчики и постоянно их поддерживают. Каждая команда всегда читает пул-реквесты, часто дает советы по разработке и обучению, обратную связь новичкам и даже шанс попасть на стажировку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сегодня, 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 и прошивками.