Это когда скрам-команда подключилась к разработки нового проекта - в таком случае нужно посчитать соотношение исходя из нового проекта и по нему формировать команду тестирования.
Второй вариант, это когда команда разделена на небольшие скрам-команды и которые занимаются своими проектам - в таком случае по каждому проекту отдельно считается соотношение разработки к тестированию.
Помочь ментору не выгореть – ключевой элемент устойчивости системы менторства. Потому что если ментор выгорает — он перестаёт быть эффективным, теряет энтузиазм, а иногда и сам уходит. Это потеря не только для новичка, но и для всей команды. У нас в команде ментор не один, мы все вместе помогаем новичку.
Оптимальный лимит на одного ментора – 1–2 новичка. Максимум – 3, если новички с опытом и на одном проекте. Никогда — более 3, если новички — без опыта, на разных проектах, в разное время.
Статья написана реальным человеком и нашей коллегой Олесей. Однако нейронки стабильно помогают нам с редактурой, не воспринимайте их как угрозу - это отличный помощник.
Отвечает автор: Времена меняются — меняются процессы, и, конечно, люди. Хорошо, что вы адаптировались – ваш опыт – отличный пример! А сейчас, как начальник, вы создаёте среду, где новички чувствуют себя комфортно – и это действительно ценно. Это мой способ — но он не единственный. Кто-то предпочитает мартини, а кто-то – чай с печеньем.😊
Добрый день! Спасибо за комментарий. Отвечает автор:
Спасибо за обратную связь!
Действительно, в статье довольно часто упоминаются микросервисы, и это может создавать ощущение, что C4 применима в основном для таких архитектур. На самом деле модель одинаково хорошо работает и для монолитов, и для распределенных систем. В статье микросервисный пример использован скорее потому, что в таких системах особенно заметна польза многоуровневого описания архитектуры.
По поводу границ микросервисов на компонентной диаграмме согласна, их можно было бы обозначить явно. В примере сознательно упростили схему, чтобы сфокусироваться на принципе декомпозиции сервиса на компоненты, но рекомендация Саймона Брауна действительно предполагает явное выделение границ контейнеров/сервисов.
Что касается подписей к стрелкам и технологий - здесь тоже справедливое замечание. В примере они использованы скорее как иллюстративные (REST/API), без строгой унификации, а технологии не везде указаны, чтобы не перегружать диаграммы. В более «производственной» версии схем такие детали, конечно, лучше фиксировать последовательно.
Из альтернатив смотрела Compose Preview Screenshot Testing и Paparazzi. Paparazzi не удалось нормально запустить для Compose - по итогу остановилась на Roborazzi, который закрыл все потребности. От Compose Preview отказалась из-за ключевого ограничения: нужно вручную помечать каждый Preview аннотацией @PreviewTest и располагать в отдельном sourceSet screenshotTest. Мне хотелось полного автомата - создаёшь Preview как обычно, и тест появляется сам. Без дополнительных аннотаций (про которые легко забыть), без отдельного sourceSet. Именно это и даёт связка ComposablePreviewScanner + Roborazzi.
С Allure интеграции нет - у нас всё через GitLab, как описано в статье. Скриншоты различий доступны прямо в MR, этого пока достаточно.
Тесты живут в :app, так что да - всё запускается одной командой через :app. Фичевые модули отдельно не покрыты, модуляризация ещё впереди - когда дойдём, будем думать как масштабировать.
Импакт анализ не делали - при текущем объёме в этом нет смысла, все тесты прогоняются быстро. Если проект вырастет и время выполнения станет проблемой, тогда уже будет повод думать в эту сторону.
По "системе с пакетами" - имеется в виду вот этот кусок из шага 7: AndroidComposablePreviewScanner() .scanPackageTrees("com.example.myapp")
Scanner нужно явно указать, по какому пакету искать Preview - без этого он просто не знает где смотреть. Указываешь корневой пакет своего приложения, и он находит все Preview во всём дереве. Ничего хитрого, просто стандартное поведение библиотеки.
Статистика отражает реальное вовлечение сотрудников в использование технологий и внедрение инициатив, направленных на улучшение процессов, сервисов и клиентского опыта.
Большое внимание уделяем развитию компетенций в области искусственного интеллекта. Обучение и практическое применение ИИ — это не формальная метрика, а часть профессионального развития сотрудников и важный элемент трансформации рабочих процессов.
Спасибо за вовлечённость и интерес к развитию технологий в компании 🙂
Отвечает автор: Да, и так бывает. Здесь уже не про революцию, а про то, что у новичка видимо было совсем по-другому. Не так давно в нашей команде был похожий кейс: ментору пришлось не легко. Как он поступил: ответил на все «почему» и часть маленьких изменений поручил самому новичку на исправление.
Отвечает автор: да это тоже один из кейсов, так тоже бывает. В одну статью сложно уместить все варианты) возможно, это тема для новой статьи.
В моей практике был пример, когда улучшения и революция не вели ни к чему хорошему. Возможно, руководитель или новичок как раз не знал про метод «пауза» и не уточнил, почему сейчас именно так.
Отвечает автор: Я понимаю, о чём вы говорите, так как вы описали ситуацию, которая встречается чаще, чем хотелось бы. И точно соглашусь с тем, что если компания не видит ценности в 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), а не для отчётности.
Добрый день!
Отвечает автор:
Хороший вопрос, возможны несколько вариантов:
Это когда скрам-команда подключилась к разработки нового проекта - в таком случае нужно посчитать соотношение исходя из нового проекта и по нему формировать команду тестирования.
Второй вариант, это когда команда разделена на небольшие скрам-команды и которые занимаются своими проектам - в таком случае по каждому проекту отдельно считается соотношение разработки к тестированию.
Добрый день!
Отвечает автор:
Спасибо за вопрос!
Помочь ментору не выгореть – ключевой элемент устойчивости системы менторства. Потому что если ментор выгорает — он перестаёт быть эффективным, теряет энтузиазм, а иногда и сам уходит. Это потеря не только для новичка, но и для всей команды. У нас в команде ментор не один, мы все вместе помогаем новичку.
Оптимальный лимит на одного ментора – 1–2 новичка. Максимум – 3, если новички с опытом и на одном проекте. Никогда — более 3, если новички — без опыта, на разных проектах, в разное время.
Добрый день!
Статья написана реальным человеком и нашей коллегой Олесей. Однако нейронки стабильно помогают нам с редактурой, не воспринимайте их как угрозу - это отличный помощник.
Добрый день!
Отвечает автор:
Времена меняются — меняются процессы, и, конечно, люди.
Хорошо, что вы адаптировались – ваш опыт – отличный пример!
А сейчас, как начальник, вы создаёте среду, где новички чувствуют себя комфортно – и это действительно ценно. Это мой способ — но он не единственный. Кто-то предпочитает мартини, а кто-то – чай с печеньем.😊
Добрый день! Спасибо за комментарий. Отвечает автор:
Спасибо за обратную связь!
Действительно, в статье довольно часто упоминаются микросервисы, и это может создавать ощущение, что C4 применима в основном для таких архитектур. На самом деле модель одинаково хорошо работает и для монолитов, и для распределенных систем. В статье микросервисный пример использован скорее потому, что в таких системах особенно заметна польза многоуровневого описания архитектуры.
По поводу границ микросервисов на компонентной диаграмме согласна, их можно было бы обозначить явно. В примере сознательно упростили схему, чтобы сфокусироваться на принципе декомпозиции сервиса на компоненты, но рекомендация Саймона Брауна действительно предполагает явное выделение границ контейнеров/сервисов.
Что касается подписей к стрелкам и технологий - здесь тоже справедливое замечание. В примере они использованы скорее как иллюстративные (REST/API), без строгой унификации, а технологии не везде указаны, чтобы не перегружать диаграммы. В более «производственной» версии схем такие детали, конечно, лучше фиксировать последовательно.
Добрый день!
Отвечает автор:
Из альтернатив смотрела Compose Preview Screenshot Testing и Paparazzi. Paparazzi не удалось нормально запустить для Compose - по итогу остановилась на Roborazzi, который закрыл все потребности. От Compose Preview отказалась из-за ключевого ограничения: нужно вручную помечать каждый Preview аннотацией @PreviewTest и располагать в отдельном sourceSet screenshotTest. Мне хотелось полного автомата - создаёшь Preview как обычно, и тест появляется сам. Без дополнительных аннотаций (про которые легко забыть), без отдельного sourceSet. Именно это и даёт связка ComposablePreviewScanner + Roborazzi.
С Allure интеграции нет - у нас всё через GitLab, как описано в статье. Скриншоты различий доступны прямо в MR, этого пока достаточно.
Тесты живут в :app, так что да - всё запускается одной командой через :app. Фичевые модули отдельно не покрыты, модуляризация ещё впереди - когда дойдём, будем думать как масштабировать.
Импакт анализ не делали - при текущем объёме в этом нет смысла, все тесты прогоняются быстро. Если проект вырастет и время выполнения станет проблемой, тогда уже будет повод думать в эту сторону.
По "системе с пакетами" - имеется в виду вот этот кусок из шага 7:
AndroidComposablePreviewScanner().scanPackageTrees("com.example.myapp")
Scanner нужно явно указать, по какому пакету искать Preview - без этого он просто не знает где смотреть. Указываешь корневой пакет своего приложения, и он находит все Preview во всём дереве. Ничего хитрого, просто стандартное поведение библиотеки.
Добрый день. Благодарим за комментарий)
Статистика отражает реальное вовлечение сотрудников в использование технологий и внедрение инициатив, направленных на улучшение процессов, сервисов и клиентского опыта.
Большое внимание уделяем развитию компетенций в области искусственного интеллекта. Обучение и практическое применение ИИ — это не формальная метрика, а часть профессионального развития сотрудников и важный элемент трансформации рабочих процессов.
Спасибо за вовлечённость и интерес к развитию технологий в компании 🙂
Даже не знаем, что ответить – думаете менеджер хуже?
Добрый день! Это точно)
Добрый день! Спасибо за внимательность: там действительно не 14, а 7
Добрый день! Спасибо за комментарий
Отвечает автор: Да, и так бывает. Здесь уже не про революцию, а про то, что у новичка видимо было совсем по-другому. Не так давно в нашей команде был похожий кейс: ментору пришлось не легко. Как он поступил: ответил на все «почему» и часть маленьких изменений поручил самому новичку на исправление.
Добрый день!
Спасибо за комментарий
Отвечает автор: да это тоже один из кейсов, так тоже бывает. В одну статью сложно уместить все варианты) возможно, это тема для новой статьи.
В моей практике был пример, когда улучшения и революция не вели ни к чему хорошему. Возможно, руководитель или новичок как раз не знал про метод «пауза» и не уточнил, почему сейчас именно так.
Добрый день! Спасибо за комментарий
Отвечает автор: Я понимаю, о чём вы говорите, так как вы описали ситуацию, которая встречается чаще, чем хотелось бы.
И точно соглашусь с тем, что если компания не видит ценности в 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), а не для отчётности.