Финальное ревью всех тест-кейсов остаётся за QA-инженерами: ИИ генерирует черновики, но ответственность за валидацию, приоритезацию и сложные сценарии всегда лежит на экспертах.
Автоматизация контроля: Уже в активной разработке специализированный ИИ-агент для первичного ревью — он проверяет дубликаты, соответствие шаблонам и базовые критерии качества, что сокращает рутину на 40%.
Качество > отчёты: Решение внедрялось для перераспределения ресурсов (например, высвобождает 30% времени тестировщиков для RCA), а не для отчётности.
Спасибо за вопрос! В работе — доработанная Qwen. По железу и архитектуре решения: детали не публикуем из-за соглашений о конфиденциальности, но ключевой акцент — полная изоляция среды выполнения.
Детали инфраструктуры и технические спецификации разглашать не можем. Важно отметить, что модель работает в полностью изолированном корпоративном контуре — это принципиально для банковской среды.
Спасибо за комментарий и внимание к деталям! Действительно, в статье используется данная фраза. Однако упомянутый оборот — это не случайность, а сознательная отсылка к книге Влада Головача «Дизайн пользовательского интерфейса. Искусство мыть слона». В гонке за релизом фокус часто смещается на "чтобы просто работало", а юзабилити отходит на второй план, и в потоке правок и дебагов суть "хорошего приложения" может потеряться. В финтехе особенно важно не забывать, что даже самое функциональное приложение проиграет, если юзеры не смогут им удобно пользоваться.
Действительно, в классическом понимании BA должен работать с бизнесом, чтобы выяснить суть требований, а SA — проектировать техническое решение. Однако в крупных компаниях (в частности, в "Совкомбанк Технологиях") процессы часто бывают гибкими: SA может получать требования как через BA, так и напрямую от бизнеса. Главное — чётко определять границы: если вопрос касается сложной бизнес-логики (расчёты, регуляторика), привлекаются BA или эксперты (юристы, бухгалтеры).
Не совсем. SA занимается технической реализацией на уровне проектирования интерфейсов, интеграций и структур данных — это ближе к аналитике, чем к архитектуре. Архитектор обычно выбирает технологии, определяет масштабируемость системы, стратегию развертывания и т. д. SA фокусируется на деталях, которые позволят реализовать требования, а архитектор — на том, как вся система будет работать в целом.
Бизнес-аналитик исследует рыночные тренды, формирует требования к продукту и согласует их.
Системный аналитик проектирует техническую реализацию: разрабатывает схемы API для платежных шлюзов, настраивает интеграцию с процессинговыми системами или проектирует базы данных для обработки транзакций. BA отвечает за то, «что нужно бизнесу», а SA — за то, «как это реализовать технически».
Отвечает Владимир: – Я с гитлабом с 2020 года, периодически изучаю новые фишки. Компоненты - одна из фишек в которые влюбился с первых строк документации. Да, они чем-то похожи на другие include, но тут много нового с ними добавили.
Они попадают в отдельный CI/CD Catalog, где есть отдельный README и описание каждого параметра компонента. Ну и сами параметры, конечно. Они предлагают более гибкий процесс настройки пайплайнов: их можно использовать не только внутри скриптов или, например, rules, как это бывает с переменными, но с помощью них можно так же задать имя задания, или переопределить целый блок rules.
Выделю ещё downstream pipelines, особенно динамические пайплайны. Недавно открыл для себя уже не такую новую фичу - parallel:matrix. В ней много своих минусов, но там где ей место - встает как влитая.
Рад, что статья понравилась. Успехов в изучении и работе с компонентами!
Работа с таблицей коэффициентов — это, по сути, аналитический инструмент, который помогает на старте проекта (или при его масштабировании) оценить необходимое количество QA-специалистов.
Каждый коэффициент (тип приложения, этап разработки, сложность, критичность) выбирается на основе анализа текущего или планируемого состояния проекта. Это делается совместно с тимлидом, архитектором, QA-лидом и/или проектным менеджером.
Как правило, это происходит на этапе инициации проекта или при масштабировании команды.
Формально это может быть зафиксировано: в проектной документации (например, в разделе о ресурсном планировании), в Confluence или другой wiki-системе команды, в оценке нагрузки QA-команды при планировании спринтов
По количеству возможных аффилированных объектов (при росте сложности растет кол-во проверок)
По количеству логики и вариативности (чем больше комбинаций, тем сложнее логика)
Для анализа можно использовать:
Сравнить оценки похожих задач на самом раннем этапе и на текущем (если похожая задача стала занимать больше времени, то это говорит об увеличении сложности)
Рост модулей/компонентов приложения + сложность этих модулей. Можно использовать матрицу компетенций.
Количество задеваемого функционала в задаче. У нас есть практика, когда разработчик пишет, что может быть задето в той или иной правке.
Согласны, что количество тестировщиков действительно зависит от проекта. В статье перечисляются основные аспекты, которые необходимо учитывать для определения оптимального соотношения: тип приложения, этап разработки, сложность проекта и требования к тестированию.
Добрый день!
Спасибо за вопросы!
Финальное ревью всех тест-кейсов остаётся за QA-инженерами: ИИ генерирует черновики, но ответственность за валидацию, приоритезацию и сложные сценарии всегда лежит на экспертах.
Автоматизация контроля: Уже в активной разработке специализированный ИИ-агент для первичного ревью — он проверяет дубликаты, соответствие шаблонам и базовые критерии качества, что сокращает рутину на 40%.
Качество > отчёты: Решение внедрялось для перераспределения ресурсов (например, высвобождает 30% времени тестировщиков для RCA), а не для отчётности.
Спасибо за вопрос! В работе — доработанная Qwen. По железу и архитектуре решения: детали не публикуем из-за соглашений о конфиденциальности, но ключевой акцент — полная изоляция среды выполнения.
Добрый день!
Используем кастомизированную версию Qwen.
Детали инфраструктуры и технические спецификации разглашать не можем. Важно отметить, что модель работает в полностью изолированном корпоративном контуре — это принципиально для банковской среды.
Спасибо за комментарий и внимание к деталям! Действительно, в статье используется данная фраза. Однако упомянутый оборот — это не случайность, а сознательная отсылка к книге Влада Головача «Дизайн пользовательского интерфейса. Искусство мыть слона». В гонке за релизом фокус часто смещается на "чтобы просто работало", а юзабилити отходит на второй план, и в потоке правок и дебагов суть "хорошего приложения" может потеряться. В финтехе особенно важно не забывать, что даже самое функциональное приложение проиграет, если юзеры не смогут им удобно пользоваться.
Добрый день! Рады, что вам понравилось!) Солидарны - без аналитиков никак!
Добрый день!
Отвечает автор:
Действительно, в классическом понимании BA должен работать с бизнесом, чтобы выяснить суть требований, а SA — проектировать техническое решение. Однако в крупных компаниях (в частности, в "Совкомбанк Технологиях") процессы часто бывают гибкими: SA может получать требования как через BA, так и напрямую от бизнеса. Главное — чётко определять границы: если вопрос касается сложной бизнес-логики (расчёты, регуляторика), привлекаются BA или эксперты (юристы, бухгалтеры).
Добрый день!
Отвечает автор статьи:
Не совсем. SA занимается технической реализацией на уровне проектирования интерфейсов, интеграций и структур данных — это ближе к аналитике, чем к архитектуре. Архитектор обычно выбирает технологии, определяет масштабируемость системы, стратегию развертывания и т. д. SA фокусируется на деталях, которые позволят реализовать требования, а архитектор — на том, как вся система будет работать в целом.
Точно подмечено!)
Добрый день!
Ответим в разрезе финтеха:
Бизнес-аналитик исследует рыночные тренды, формирует требования к продукту и согласует их.
Системный аналитик проектирует техническую реализацию: разрабатывает схемы API для платежных шлюзов, настраивает интеграцию с процессинговыми системами или проектирует базы данных для обработки транзакций. BA отвечает за то, «что нужно бизнесу», а SA — за то, «как это реализовать технически».
Добрый день!
Спасибо за комментарий.
Отвечает Владимир:
– Я с гитлабом с 2020 года, периодически изучаю новые фишки. Компоненты - одна из фишек в которые влюбился с первых строк документации. Да, они чем-то похожи на другие include, но тут много нового с ними добавили.
Они попадают в отдельный CI/CD Catalog, где есть отдельный README и описание каждого параметра компонента. Ну и сами параметры, конечно. Они предлагают более гибкий процесс настройки пайплайнов: их можно использовать не только внутри скриптов или, например, rules, как это бывает с переменными, но с помощью них можно так же задать имя задания, или переопределить целый блок rules.
Выделю ещё downstream pipelines, особенно динамические пайплайны. Недавно открыл для себя уже не такую новую фичу - parallel:matrix. В ней много своих минусов, но там где ей место - встает как влитая.
Рад, что статья понравилась. Успехов в изучении и работе с компонентами!
Добрый день! Спасибо за вопрос!
Работа с таблицей коэффициентов — это, по сути, аналитический инструмент, который помогает на старте проекта (или при его масштабировании) оценить необходимое количество QA-специалистов.
Каждый коэффициент (тип приложения, этап разработки, сложность, критичность) выбирается на основе анализа текущего или планируемого состояния проекта. Это делается совместно с тимлидом, архитектором, QA-лидом и/или проектным менеджером.
Как правило, это происходит на этапе инициации проекта или при масштабировании команды.
Формально это может быть зафиксировано:
в проектной документации (например, в разделе о ресурсном планировании),
в Confluence или другой wiki-системе команды,
в оценке нагрузки QA-команды при планировании спринтов
Если остались еще вопросы, мы на связи!
Добрый вечер! Спасибо!
Сложность приложения оценивается:
По количеству возможных аффилированных объектов (при росте сложности растет кол-во проверок)
По количеству логики и вариативности (чем больше комбинаций, тем сложнее логика)
Для анализа можно использовать:
Сравнить оценки похожих задач на самом раннем этапе и на текущем (если похожая задача стала занимать больше времени, то это говорит об увеличении сложности)
Рост модулей/компонентов приложения + сложность этих модулей. Можно использовать матрицу компетенций.
Количество задеваемого функционала в задаче. У нас есть практика, когда разработчик пишет, что может быть задето в той или иной правке.
Количество легаси кода без документации
Ну вот, в целом как-то так:)
Согласны, что количество тестировщиков действительно зависит от проекта. В статье перечисляются основные аспекты, которые необходимо учитывать для определения оптимального соотношения: тип приложения, этап разработки, сложность проекта и требования к тестированию.