ИИ против рутины: как изменится тестирование? Круглый стол на «Стачке»
2–3 октября в Санкт-Петербурге пройдёт XIV международная IT-конференция «Стачка», и мы рады сообщить, что Маргарита Трофимова, директор департамента тестирования и обеспечения качества ITFB Group, выступит модератором круглого стола «Применение ИИ в тестировании».
Маргарита — эксперт с более чем 17-летним опытом в области качества ИТ-систем, вице-председатель Russian Software Testing Qualification Board, спикер ведущих отраслевых конференций и идейный вдохновитель образовательного практикума «Академия тестирования».
На круглом столе вместе с представителями ДОМ.РФ, Альфа-Банка, Авито и других лидеров рынка участники обсудят, как искусственный интеллект трансформирует процессы тестирования, команды и бизнес-результаты.
Будет затронуты ключевые вопросы: — какие задачи уже сегодня эффективнее решают ИИ-системы, — где технологии пока остаются уязвимыми, — как измерить эффект от внедрения ИИ в QA.
Приглашаем QA-специалистов, разработчиков и продакт-менеджеров присоединиться к дискуссии и взглянуть на будущее профессии вместе с экспертами отрасли.
📍 Санкт-Петербург 📅 2–3 октября 🔗 Конференция «Стачка»
Под капотом FinamTrade: как работает покупка акций, разработка под санкциями и будущее AI в финтехе
Привет, Хабр!
В нашем подкасте «Null на балансе» мы, как обычно, разбираем технологичные штуки на запчасти. На этот раз мы забрались в одну из самых закрытых и интересных систем — мобильный трейдинг.
У нас в гостях Борис Аксенов, руководитель управления разработки веб и мобильных приложений в «Финаме». Человек, который стоит у руля создания и эволюции FinamTrade последние 15 лет. Мы поговорили о том, о чем обычные пользователи часто не задумываются, нажимая кнопку «Купить».
О чём этот выпуск:
Архитектура и нагрузка: Что происходит на бэкенде, в мобильном клиенте и на бирже в момент, когда вы и еще 10 000 человек одновременно отправляете заявку?
Эволюция: Как приложение FinamTrade превращалось из простого терминала в суперапп с новостями, аналитикой и обучением? Какие технологические решения были ключевыми на этом пути?
Боль и санкции:Самая острая тема — как изменились процессы разработки и публикации в App Store и Google Play для такого критически важного приложения в текущих реалиях? Какие инструменты и воркaунды пришли на смену привычным сервисам?
Безопасность: Как защищаются финансовые данные и средства клиентов в эпоху мобильных угроз?
AI и ML: Где машинное обучение и искуственный интеллект уже работают в финтехе сегодня (например, в предиктивном анализе поведения или проверке документов), а где это пока лишь хайп?
Карьера в финтехе: Как приходят в разработку для таких высоконагруженных систем? Что мотивирует специалистов оставаться в одной компании больше 15 лет?
А еще Борис поделился парой забавных курьезных случаев из практики и мифов о финтехе, которые заставят вас улыбнуться.
Выпуск получился по-настоящему гибридным. Он будет полезен:
Разработчикам и архитекторам, особенно тем, кто работает или хочет работать с высоконагруженными и отказоустойчивыми системами.
Специалистам по DevOps и безопасности, чтобы понять уровень требований в fintech.
Всем, кто интересуется карьерой в IT — история Бориса о 15-летнем пути в одной компании очень мотивирует и показывает возможный вектор роста.
Трейдерам и инвесторам, которые хотят глубже понимать инструмент, которым пользуются каждый день.
Нейросети в QA. Подборка важнейших кейсов применения.
Искусственный интеллект в QA – это уже не теория из будущего, а практический инструмент, доступный здесь и сейчас. Пока одни спорят, заменит ли ИИ тестировщика, другие уже используют его, чтобы избавиться от рутины и сосредоточиться на действительно сложных задачах.
Нейросети способны взять на себя генерацию тестовых данных, помочь в написании автотестов, проанализировать тысячи строк логов и даже превратить технический отчет в понятный документ для бизнес-команды. В этом коротком посте я собрал подборку конкретных кейсов, которые помогут вам сделать работу быстрее, качественнее и интереснее.
Кейсы по использованию нейросетей в QA
Генерация тест-кейсов на основе требований
Подготовка позитивных и негативных тестовых данных
Адаптация и улучшение баг-репортов
Перевод сценариев в формат Gherkin (Given-When-Then)
Генерация идей для негативного тестирования
Автоматический анализ логов ошибок
Помощь в написании автотестов и шаблонов
Конвертация технической информации в пользовательские инструкции
Голосовое управление заведением баг-репортов и создания чек-листов
Генерация финальных отчётов по тестированию
Помощь в написании автотестов: генерация кода, шаблонов и отдельных функций для фреймворков автоматизации
Подготовка баг-таблиц и чек-листов
Создание слайдов по итогам тестирования
Автоматическая сверка ожидаемого и фактического поведения
Генерация SQL-запросов на основе текстового запроса
Перевод технических отчётов для бизнес-аудитории
Проверка качества текста / интерфейса (UX-копирайтинг)
Генерация данных для нагрузочного тестирования
Сравнение версий документации / требований
Сбор фидбэка из отзывов пользователей (тематический анализ)
Создание чат-ассистента по документации и API
Анализ требований на предмет неясностей, противоречий и неполноты
Прогнозирование областей с высокой вероятностью дефектов
Этот список – лишь небольшая часть того, как нейросети могут усилить работу QA-инженера. Главный вывод прост: ИИ не заменяет специалиста, а становится его личным ассистентом – мощным, быстрым и безотказным. Он помогает находить неочевидные сценарии, экономить часы на подготовке данных и отчетов и, в конечном счете, повышать качество продукта. В своем коротком посте я представил лишь самые популярные примеры того как можно использовать нейросети в работе QA, но в полной коллекции под названием "70 кейсов применения нейросетей для QA" вы найдете их гораздо больше.
Год назад мы масштабно обновили приложение для 2ГИС на Apple Watch: начали показывать на часах местоположение близких в рамках функции «Друзья на карте» и поддерживать ведение по пешему маршруту. К очередной презентации Apple решили добавить ещё полезностей.
Теперь часы умеют вести и по маршрутам общественного транспорта — с указанием номеров маршрутов транспорта и полезными подсказками в пути. Мы сами знаем, что это особенно удобно, когда руки заняты или вокруг суета.
Об интересных моментах реализации рассказывает разработчик Иван Гнатюк.
Маленький экран — большие задачи
Сделать маршрут общественного транспорта на часах оказалось не так уж сложно — помогли два момента:
Во-первых, у нас уже было приложение на watchOS 10+, где работало пешее ведение и была настроена коммуникация телефон ← → часы.
Во-вторых, мы раньше делали отображение маршрута транспорта для Live Activity на телефоне, и смогли переиспользовать много вьюшек и бизнес-логики (а она бывает непростой).
Оставалось только собрать из уже имеющихся блоков новое отображение для часов, что мы и сделали довольно быстро. Потом мы подумали, а почему бы не сделать и новое LA для общественного транспорта на часах? Текущее отображение от Dynamic Island с телефона выглядело скучно.
Сложность в том, что мы ограничены размерами часов, причём размеры варьируются 40– 49 мм. Скролл мы здесь добавить не можем, поэтому нужно попытаться уместить весь маршрут со всеми его сегментами на маленьком экранчике, попытавшись сохранить максимум полезной информации (номер маршрута, номер выхода из метро).
На помощь пришел GeometryReader — он даёт ширину контейнера, и, зная количество и тип сегментов, мы рисуем маршрут. Если пересадок на маршруте шесть и больше, то оставляем те, что помещаются, а вместо последнего покажем «....». Но на бою нам не удалось построить такой маршрут. Если вам удастся — расскажите нам!
Разработка на настоящих часах — интересно, но непредсказуемо
Разрабатывать и собирать на настоящих часах всегда интереснее. Но с этим могут быть свои приключения.
Например, часы могут «отваливаться». Xcode к ним не подключается и приходится постоянно проверять настройки часов и подключение к WiFi.
Иногда таргет часов ни в какую не хочет устанавливаться на часы — помогает только их перезагрузка.
А в какой то момент на часах перестал отображаться и новый LA, и простая трансляция DI. Перезагружали и часы, и телефон — ничего не помогало. Оказалось, что в какой то момент телефон обновился, а часы нет. Вот так и сломалось.
Как работает для пользователя
Для того чтобы видеть основные этапы маршрута, нужно построить маршрут на общественном транспорте в приложении на смартфоне и нажать «В путь», а на часах открыть приложение 2ГИС. В пути достаточно посматривать на часы — приложение покажет ключевую информацию с помощью Live Activities: иконки транспорта с цветом ветки метро, номер выхода, время в пути и пересадки, если они предусмотрены. Чтобы просмотреть весь маршрут, достаточно тапнуть на Live Activities и прокрутить Digital Crown.
Всё будет работать на Apple Watch с watchOS 11, iPhone с iOS 18 и в приложении 2ГИС версии 7.11 или новее. На часы отдельно ничего ставить не нужно — всё подтянется из приложения на айфоне.
И как это экономит ресурсы, улучшает продукт и снижает количество переделок
Одна из ключевых проблем, с которыми сталкиваются компании, заказывающие разработку — это разрыв между ожиданиями и реальностью. Причины бывают разные: неполное или неструктурированное ТЗ, размытые пользовательские сценарии, неучтённые роли или ветвления логики, которые всплывают на стадии разработки и тестирования.
Команда Doubletapp приняла решение: QA подключаются к проекту на этапе первого ознакомления с ТЗ от заказчика, ещё до оценки, дизайна и начала разработки. Этот подход сильно влияет на качество итогового продукта и помогает заказчику получить то, что действительно нужно — без множества итераций «переделать» и «добавить, потому что забыли».
Ниже расскажем, как у нас выстроен процесс, какие задачи берут на себя QA, и почему мы считаем, что раннее подключение тестирования — это не просто хорошая практика, а основа устойчивой разработки.
Роль QA в нашей команде: не только тестирование
Наши QA участвуют в проекте с первых дней.
Структурируют поступившее от заказчика ТЗ
Выделяют функциональные блоки
Формируют уточняющие вопросы
Работают над схемами и диаграммами логики
Проверяют, насколько требования реализуемы и согласованы между собой.
Наша задача на этом этапе — перевести бизнес-язык заказчика на язык разработки и одновременно выловить противоречия и пустые места в логике до того, как они станут багами.
QA плотно взаимодействуют с селлерами и лидами разработки и помогают им формализовать требования. Это снижает нагрузку на менеджеров и ускоряет проработку проекта.
Как это работает на практике
Заказчик приходит с ТЗ. Оно может быть подробным, а может состоять из тезисов, что хотелось бы реализовать в продукте.
QA разбивают информацию на структурные блоки — экраны, роли, сценарии, ограничения, точки перехода.
Составляют вопросы, которые передаются в команду, ответственную за коммуникацию с заказчиком.
Параллельно разработчики начинают верхнеуровневую оценку трудозатрат. Они тоже собирают вопросы, если логика не до конца ясна.
Все вопросы объединяются, уточняются и через менеджеров идут в диалог с заказчиком.
Такой процесс позволяет уточнить максимум информации до старта разработки и значительно уменьшает риск изменения требований на лету.
Когда это спасло проект
Один из проектов, с которым мы работали, сопровождался очень подробным бизнес-ТЗ — документ содержал более 70 страниц описания сервиса. Всё выглядело детально и проработанно.
Однако при формировании схемы ролей и доступов наши QA обнаружили логические противоречия: несколько ролей получали доступ к функциям, к которым не должны были иметь отношения. Это было связано с тем, что в тексте документа не было визуального представления логики переходов, и ошибки остались незамеченными.
На этом этапе проблема была решена за один день — без этой работы её бы пришлось исправлять на этапе тестирования, переделывая часть кода и логику авторизации.
Внутренние процессы: как это устроено
Мы работаем по agile: QA входят в спринты наравне с разработкой. Внутри спринта QA выполняют не только тестирование, но и работу, близкую к системной аналитике: анализ, структурирование, детализация, согласование требований, построение логики.
Тест-кейсы и баг-репорты ведём в YouTrack и Qase, используем CI/CD, чтобы как можно раньше получать обратную связь по стабильности продукта.
Зачем это заказчику
Когда QA работают с самого начала, заказчик получает
Прозрачную архитектуру с понятной логикой
Согласованные требования, переведённые в схемы
Минимум доработок в процессе разработки
Экономию времени — на исправление неочевидных ошибок
Повышенное доверие команды к требованиям — все понимают, что делают и зачем
Если вы находитесь в поиске команды, которая помогает не просто писать код, а проектирует продукт вместе с вами, задаёт неудобные вопросы до начала разработки и экономит вам месяцы правок — значит, вам нужен именно такой подход.
Тестируем микросервисное приложение с кучей интеграций — четыре совета из практики
На одном из финтех-проектов наша команда тестирования столкнулась с серьезными вызовами: нестабильные партнерские API, отсутствие тестовых сред у партнеров, лимиты на запросы и риски всё сломать одним обновлением.
В этом посте — примеры, как команда с этим справилась и как можно поступить в похожих ситуациях. Эта подборка может сэкономить кому-то часы (а то и дни) работы.
🛠️ Внешние сервисы без тестовых контуров
Решение: собственный мок-сервис на основе WireMock.
Как он работает:
тестировщик задает нужный ответ и отправляет его через HTTP-запрос в БД;
нужные вызовы подменяются в конфигурации;
при тестировании запрос уходит не во внешний API, а в мок, который отдает нужный ответ.
Моки у нас кастомные, конфигурируются через Swagger, и не завязаны напрямую на CI/CD — это упрощает запуск и дает гибкость.
Плюс: так мы не зависим от внешних API, которые то работают, то нет.
💸Платные вызовы и лимиты на тестовые запросы
Решение: изолированные стенды и замещение моками везде, где возможно.
Если API-партнер дает 150 вызовов в месяц, а вам нужно 500 на автотесты — моки опять же спасают. Мы блокируем обращения к реальным API на командных стендах и заменяем их заглушками. Проверку живых интеграций оставляем только на пред-проде.
Плюсы:
не сжигаем бюджет;
эмулируем ошибки и нестандартные ответы;
ускоряем тесты без зависимости от внешней стороны.
🔄 Нестабильность интеграционных тестов
Решение: изоляция и моки как защитный слой.
Микросервисная архитектура — это боль, когда один упавший сервис ломает релиз. Поэтому мы:
эмулируем нестабильные вызовы моками;
изолируем свою часть и фокусируемся на ее стабильности;
прогоняем тесты на командных стендах — быстро, стабильно и без флуктуаций от партнеров.
🤝 Десятки команд, завязанных на общий процесс
Решение: интеграционные проверки и ревью на совместимость.
Когда много команд делают один продукт, любое изменение может зацепить чужой модуль. Мы выстроили систему так, чтобы ошибки ловились до мерджа, а не после инцидента. Что помогло:
общие тестовые фреймворки и единый подход к интеграционным тестам;
сценарии, которые включают зависимости от других команд;
проверка обратной совместимости: если что-то ломает чужой функционал — фича не проходит MR.
А зачем вообще проводить исследования? А вот интересно посмотреть на сферу глазами тех самых ребят, кто каждый день работу эту самую работает, узнать, где больше всего болит и где можно усилиться — то есть в будущем предложить решение, которого ещё нет или чего мало.
Так появилось исследование тестировщиков 👇
Ещё можно углубиться в лендинг: https://qa-survey-2025.2gis.ru. Посмотреть разные цифры: собирали данные скрупулезно по профильным каналам, 1000 QA-инженеров начали опрос, 570 стойко ответили на все 45 вопросов!
К слову, и про статистику сбора данных: 37% тестировщиков проходили опрос на Android, 29% на iPhone, 23% на Windows, 9% на MacOS и даже 2% c Linux.
Заглядывайте и пишите, за что взгляд зацепился, обсудим!
Как QA и DEV могут эффективно работать вместе, а не играть в бесконечный пинг-понг с передачей фичи на тестирование и багов туда-обратно?
Об этом Лена Федорова, QA Garage Eight, рассказала на своей лекции «Мир, дружба, тестирование» на QA митапе в офисе Garage Eight. Она поделилась кейсом своей команды по внедрению совместного тестирования и тем, какие результаты оно дало.
Смотри лекцию и узнаешь: > что такое «совместное тестирование»? > какие у него преимущества и недостатки; > каким командам подойдет этот подход; > как измерить успех.
Как ускорить Android-разработку и избавиться от мучительно долгих запусков эмуляторов ради простого теста?
Ответ — Robolectric — мощный инструмент для UI‑тестирования Android‑кода без эмулятора.
Позволяет запускать юнит-тесты Android-приложений прямо в JVM, без эмуляторов и физических устройств. Экономия на каждом тестовом прогоне, обратная связь почти мгновенная.
В Android‑комьюнити у Robolectric неоднозначная репутация из‑за трудностей совместимости с другими библиотеками. Но…его почти бесценные возможности пробудили любопытство и желание копнуть глубже и осмыслить этот инструмент.
В конце мая Андрей Ганин, Chief Quality Officer МТС, выступил с лекцией на QA митапе в офисе Garage Eight. На ней он поговорил про то, что же такое «качество» продукта и что на самом деле его убивает.
Магазину приложений RuStore исполнилось три года. Количество установок этого приложения на устройствах пользователей превысило 100 млн.
25 мая 2022 года VK при поддержке Минцифры запустила открытое бета‑тестирование отечественного магазина мобильных приложений для Android под названием RuStore.
В начале февраля 2023 года RuStore объявил о завершении этапа бета‑тестирования магазина приложений. Также создатели платформы перевели интерфейс консоли разработчика на английский язык для удобства иностранных издателей и партнёров.
В декабре 2024 года месячная аудитория магазина приложений RuStore составила 50 млн пользователей старше 12 лет по всей России, согласно исследованию Mediascope. Аудитория Xiaomi Mi Store составила 19 млн, Samsung Galaxy Store — 14 млн, HUAWEI AppGallery — 10 млн, рассказали Хабру в пресс‑службе RuStore. А в Минцифры заявили, что RuStore от VK обошёл по числу пользователей в России App Store от Apple.
В VK добавили, что в каталоге RuStore уже более 50 тысяч приложений, доступных на ОС Android, Harmony OS и «Аврора», от разработчиков из 40 стран мира. Также вышли версии RuStore для электронных книг и умных телевизоров, для проекторов, Hi‑Fi‑аудиоплееров, игровых консолей, кассовых терминалов, умных часов.
В Duolingo появились курсы японского, корейского и китайского на русском языке — стать полиглотом теперь ещё проще. Ранее эти языки были доступны только англоязычным пользователям.
Через час, в 16:00 мск, начнем обсуждение трех подходов к мобильному тестированию. Обсудим плюсы и минусы работы с локальными, публичными и зарубежными решениями. Определим наиболее эффективный формат тестирования для разных ситуаций.
Если позволите, вкратце о себе. Зовут меня Саней. Имею опыт в тестирование более 3-х лет. В послужном списке тестирования были desktop-приложения для операторов БПЛА, системы защиты информации, система кредитования физических лиц и многое другое.
В настоящий момент работаю в компании QA-специалистом и одновременно являюсь ментором для людей, решивших стать тестировщиками.
Имеется богатый опыт теории и практики в тестировании, а также есть желание поделиться с ним.
Пишу пост на Хабре впервые и хочу узнать, "стоит ли игра свеч" и будет ли кому-то это интересно. Буду раз в неделю выкладывать статью о профессии QA, делаю упор на практику, которая вам в последующем пригодится на работе. И не будем забывать о теории, чтобы успешно пройти интервью)))
🤖 Приглашаем на онлайн-дискуссию по мобильному тестированию
12 марта эксперты из крупных компаний встретятся, чтобы обсудить свой опыт работы с локальными, публичными и зарубежными мобильными фермами. Они сравнят три решения с разных точек зрения, расскажут про плюсы и минусы каждого решения, поделятся собственным опытом и вместе обсудят, какой формат тестирования эффективнее в разных ситуациях.
Приглашаем вас присоединиться, узнать больше о мобильном тестировании и получить ответы на вопросы.
Где и когда
12 марта в 16:00 (МСК). В этот раз встречаемся только онлайн, так что присоединиться можно из любой точки мира.
Спикеры
▪️ Фаиль Шахмаев, руководитель мобильной разработки в TrendTech.
▪️ Юрий Дубовой, руководитель iOS-разработки в Делимобиль.
▪️ Никита Бондарев, head of QA в Спортс”.
▪️ Александр Кабанец, менеджер продукта «Мобильная ферма» в Selectel.
Программа
▪️ Локальная ферма: плюсы и минусы с технологической точки зрения.
▪️ Можно ли заменить ферму качественной автоматизацией?
▪️ Browserstack: стоит ли полагаться на зарубежного провайдера.
12 проблем, которые убивают результаты вашего A/B тестирования. Паша Бухтик на митапе Garage Eight
В октябре собирали гостей в нашем петербургском офисе послушать доклады и понетворкать. В этот раз в числе спикеров был и приглашенный эксперт Паша Бухтик, Founder & CEO at No Data No Growth; ex-Head of Analytics at Yandex, FindMyKids, Kupibilet.
Паша поговорил о распространенных ошибках, с которыми сталкиваются многие продуктовые менеджеры и аналитики, и о том, как эти ошибки могут свести на нет результаты любого A/B-теста. Узнай из записи лекции!
И ждем тебя на следующих митапах в Garage Eight. Публикуем анонсы на сайте и в соцсетях.
Как Duolingo добилась успеха на рынке и причем тут аналитика
Duolingo — одно из самых популярных приложений для изучения языков (№1 по скачиванию в магазинах приложений). Вместо скучных уроков оно напоминает игру: прогресс, уровни, награды, упражнения мини-игры и др.
По данным компании, около 34 млн. человек используют Duolingo каждый день.
Но что стоит за этим успехом?
Один из ключевых принципов компании — "Тестируй всё". Постоянные эксперименты помогают Duolingo улучшать процесс обучения и находить новые решения для роста.
В любой момент в Duolingo могут проводиться несколько сотен A/B тестов одновременно. Экспериментируют со всем: от мелких изменений интерфейса до запуска крупных функций, как Лидерборды. Для A/B тестирования компания разработала собственный сервис.
Путь тестировщика: ошибки, опыт, деньги. Вышел новый Sravni Podcast!
В новом выпуске поговорили о сути QA, отношениях тестирования и разработки, неизбежности багов и ответственности за плохие релизы. Гость — Анна Серенькова, QA Mobile Lead Сравни.
В этом выпуске:
Что должен уметь тестировщик и сколько ему платят?
В чём разница тестирования в вебе и на мобильных устройствах?
Почему в ИТ важно доказывать свою ценность, и в чём здесь отличия для женщин и мужчин?
Право на какое количество ошибок есть у тестировщика, прежде чем его уволят?
