Отвечает автор: Да, и так бывает. Здесь уже не про революцию, а про то, что у новичка видимо было совсем по-другому. Не так давно в нашей команде был похожий кейс: ментору пришлось не легко. Как он поступил: ответил на все «почему» и часть маленьких изменений поручил самому новичку на исправление.
Отвечает автор: да это тоже один из кейсов, так тоже бывает. В одну статью сложно уместить все варианты) возможно, это тема для новой статьи.
В моей практике был пример, когда улучшения и революция не вели ни к чему хорошему. Возможно, руководитель или новичок как раз не знал про метод «пауза» и не уточнил, почему сейчас именно так.
Отвечает автор: Я понимаю, о чём вы говорите, так как вы описали ситуацию, которая встречается чаще, чем хотелось бы. И точно соглашусь с тем, что если компания не видит ценности в QA (или в любой другой роли), не готова инвестировать в процессы, а вместо этого ищет «кого-то, кто заткнёт дыру», — это не проблема лида, а системная, иногда даже культурная особенность организации. В нашей компании мы работаем по-другому, и я опиралась именно на этот опыт. Спасибо что написали о своем опыте, это важно - учитывать весь контекст и видеть разные проявления.
1) Согласен, в статье не хватает практических примеров, статью преподношу как теоретическую, в дальнейшем, при раскрытии этой темы планирую освещать уже практические кейсы
2) Про изменение API: не совсем так: если аналитики документируют API условно в нескольких источниках (именно само описание запросов), то из-за этого дублирования потребуется хN времени на изменения.
Давайте попробуем разобрать конкретно ваш кейс: "Если произошло изменение в сценарии" - тут зависит от того, как сценарии выглядят. Если сценарий содержит в себе URL запроса, имя параметров, описание или условия отображения UI элементов - то по такому сценарию лучше пробежаться под призмой SRP (принцип единой ответственности) и принципом абстракции. Вместо детализированного URL - POST-запрос /api/v1/users, рекомендую писать "запрос на создание пользователя", под это подкреплять ссылку, которая ведет на описание этого запроса Параметры API в сценарии, иногда лишняя детализация сценария, без которой, хотелось бы попробовать обойтись Описание элементов UI и их условия отображения, вместо опять же детализации UI в сценариях - советую ссылаться на блок с описанием UI, например: Пользователь нажимает на кнопку "Создать", Система отображает Экран "Наименование экрана" (ссылка).
Касаемо сценариев, они должны вести по логическому пути, от А до Б, но без излишней детализации там, где она не нужна. Согласен, что не все так гладко, главное, что со временем - эти принципы в любом случае помогут минимизировать количество правок
3) По поводу средств обработки документации, я использую для проектирования API : YAML + MS Visual Studio Code. Результат (спецификацию) подгружаю в ТЗ, в Confluence, через плагин для Swagger UI. Поделюсь, в ТЗ мы описываем, грубо говоря - направление, то, как по предположительно по итогу API должно выглядеть. Реализация остается все равно за разработчиками, могут поменять имя параметра, обсудить, подсветить и т.д. Если разработчики что-то меняют, то тут вопрос, если в задаче есть только бэкенд, то можно ТЗ не править, а в доке уже ссылаться на Swagger. Если в задаче есть фронт, то тут другой вопрос, работаете вы по API-first или Code-first: Если API-first, то ТЗ поправить надо будет в моменте, когда разработчик подсвеичвает какое-то отклонение от проекта спецификации. Если Code-first, то просто ссылаемся на Swagger В случае, если по задаче у нас один фронт, а не два (и, если разработчик меняет имя параметра - то ТЗ мы не правим, в доке ссылаемся на Swagger, чтобы не делать двойную работу. Ситуаций, чтобы я спроектировал API, а потом ко мне пришел разработчик со словами: "тут надо целиком переделывать логику" - пока что не было, но если вдруг, то да, нужно будет вносить изменения в документацию P.S. не вносить правки в ТЗ можно, если у вас
4) Про "быструю проверку": зависит от масштаба проекта, и состояния документации. Соглашусь, что формулировка "быстро" может подойти не везде, но чем чаще будут проводиться ретроспективы по состоянию документации, в целом, ее переработки - тем быстрее этот процесс будет проходить.
Спасибо за вопрос. Разработка и развертывание нашей мобильной фермы прошло в два этапа. Изначально реализовали MVP и на это ушло 3 дня. Далее, с учетом всех требований и согласований, выпустили рабочий вариант и это примерно еще 1 мес.
Как дизайнер, я часто сталкиваюсь с необходимостью быстро и надёжно проверять макеты на соответствие гайдлайнам. Из-за особенностей домена (и NDA) не могу делиться внутренними кейсами, но с радостью поделюсь подходами, которые реально работают.Многие команды дизайнеров активно используют автоматизацию в Figma: например, плагины вроде Adee или Design Lint помогают ловить несоответствия по отступам, шрифтам, цветам и размерам компонентов — вроде кнопки 44×44 вместо 48×48. Это особенно полезно в сложных интерфейсах, где легко пропустить деталь. Для проверки доступности использую Contrast Checker — он быстро выявляет, соответствует ли контрастность требованиям WCAG 2.1. А с помощью Figma Tokens удобно сверяться с дизайн-токенами: так проще избежать “плавающих” значений цветов или отступов.
Интересный момент: однажды подобный инструмент за пару минут нашёл три разных оттенка серого в подсказках одной формы — вручную на это ушло бы в разы больше времени.Также в современных процессах популярен подход “проверка дизайна через код”: например, Storybook в связке с Chromatic позволяет делать снапшоты компонентов и отслеживать визуальные регрессии. Это помогает держать дизайн и реализацию в синхронизации и сокращает количество UI-багов на релизах.
Надеюсь, этот лайфхак будет полезен и твоей команде!
Финальное ревью всех тест-кейсов остаётся за 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 (или в любой другой роли), не готова инвестировать в процессы, а вместо этого ищет «кого-то, кто заткнёт дыру», — это не проблема лида, а системная, иногда даже культурная особенность организации.
В нашей компании мы работаем по-другому, и я опиралась именно на этот опыт.
Спасибо что написали о своем опыте, это важно - учитывать весь контекст и видеть разные проявления.
Добрый день!
Спасибо за комментарий. Отвечает автор:
1) Согласен, в статье не хватает практических примеров, статью преподношу как теоретическую, в дальнейшем, при раскрытии этой темы планирую освещать уже практические кейсы
2) Про изменение API: не совсем так: если аналитики документируют API условно в нескольких источниках (именно само описание запросов), то из-за этого дублирования потребуется хN времени на изменения.
Давайте попробуем разобрать конкретно ваш кейс:
"Если произошло изменение в сценарии" - тут зависит от того, как сценарии выглядят.
Если сценарий содержит в себе URL запроса, имя параметров, описание или условия отображения UI элементов - то по такому сценарию лучше пробежаться под призмой SRP (принцип единой ответственности) и принципом абстракции.
Вместо детализированного URL - POST-запрос /api/v1/users, рекомендую писать "запрос на создание пользователя", под это подкреплять ссылку, которая ведет на описание этого запроса
Параметры API в сценарии, иногда лишняя детализация сценария, без которой, хотелось бы попробовать обойтись
Описание элементов UI и их условия отображения, вместо опять же детализации UI в сценариях - советую ссылаться на блок с описанием UI, например: Пользователь нажимает на кнопку "Создать", Система отображает Экран "Наименование экрана" (ссылка).
Касаемо сценариев, они должны вести по логическому пути, от А до Б, но без излишней детализации там, где она не нужна.
Согласен, что не все так гладко, главное, что со временем - эти принципы в любом случае помогут минимизировать количество правок
3) По поводу средств обработки документации, я использую для проектирования API : YAML + MS Visual Studio Code. Результат (спецификацию) подгружаю в ТЗ, в Confluence, через плагин для Swagger UI.
Поделюсь, в ТЗ мы описываем, грубо говоря - направление, то, как по предположительно по итогу API должно выглядеть. Реализация остается все равно за разработчиками, могут поменять имя параметра, обсудить, подсветить и т.д.
Если разработчики что-то меняют, то тут вопрос, если в задаче есть только бэкенд, то можно ТЗ не править, а в доке уже ссылаться на Swagger. Если в задаче есть фронт, то тут другой вопрос, работаете вы по API-first или Code-first:
Если API-first, то ТЗ поправить надо будет в моменте, когда разработчик подсвеичвает какое-то отклонение от проекта спецификации.
Если Code-first, то просто ссылаемся на Swagger
В случае, если по задаче у нас один фронт, а не два (и, если разработчик меняет имя параметра - то ТЗ мы не правим, в доке ссылаемся на Swagger, чтобы не делать двойную работу. Ситуаций, чтобы я спроектировал API, а потом ко мне пришел разработчик со словами: "тут надо целиком переделывать логику" - пока что не было, но если вдруг, то да, нужно будет вносить изменения в документацию
P.S. не вносить правки в ТЗ можно, если у вас
4) Про "быструю проверку": зависит от масштаба проекта, и состояния документации. Соглашусь, что формулировка "быстро" может подойти не везде, но чем чаще будут проводиться ретроспективы по состоянию документации, в целом, ее переработки - тем быстрее этот процесс будет проходить.
Спасибо за вопрос. STF - это open source проект – мы взяли эту платформу и развернули у себя.
Добрый день!
Спасибо за вопрос. Разработка и развертывание нашей мобильной фермы прошло в два этапа. Изначально реализовали MVP и на это ушло 3 дня. Далее, с учетом всех требований и согласований, выпустили рабочий вариант и это примерно еще 1 мес.
Спасибо! Старались)
Спасибо вам!
Добрый день!
Отвечает Катя:
Привет, спасибо за вопрос!
Как дизайнер, я часто сталкиваюсь с необходимостью быстро и надёжно проверять макеты на соответствие гайдлайнам. Из-за особенностей домена (и NDA) не могу делиться внутренними кейсами, но с радостью поделюсь подходами, которые реально работают.Многие команды дизайнеров активно используют автоматизацию в Figma: например, плагины вроде Adee или Design Lint помогают ловить несоответствия по отступам, шрифтам, цветам и размерам компонентов — вроде кнопки 44×44 вместо 48×48. Это особенно полезно в сложных интерфейсах, где легко пропустить деталь. Для проверки доступности использую Contrast Checker — он быстро выявляет, соответствует ли контрастность требованиям WCAG 2.1. А с помощью Figma Tokens удобно сверяться с дизайн-токенами: так проще избежать “плавающих” значений цветов или отступов.
Интересный момент: однажды подобный инструмент за пару минут нашёл три разных оттенка серого в подсказках одной формы — вручную на это ушло бы в разы больше времени.Также в современных процессах популярен подход “проверка дизайна через код”: например, Storybook в связке с Chromatic позволяет делать снапшоты компонентов и отслеживать визуальные регрессии. Это помогает держать дизайн и реализацию в синхронизации и сокращает количество UI-багов на релизах.
Надеюсь, этот лайфхак будет полезен и твоей команде!
Добрый день!
Спасибо за вопросы!
Финальное ревью всех тест-кейсов остаётся за 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-команды при планировании спринтов
Если остались еще вопросы, мы на связи!