Согласна, что в разных командах подход к грумингу, документации и тестовым окружениям может отличаться. Мы тоже сталкивались с разными вариантами: где-то груминг - это только оценка задач, а где-то это полноценная площадка для обсуждения деталей и критериев качества. Здесь многое зависит от терминологии и внутренних процессов в команде.
Темы выделенных сред под каждую фичу (branch=env или пул тестовых окружений) действительно важны - такой подход ускоряет обратную связь и снижает зависимости между задачами. На мой взгляд, это отлично вписывается в agile-принципы: быстрее проверять результаты и не мешать работе других. Развёртывание изолированных сред - отдельная тема, причём тут многое зависит еще и от возможностей инфраструктуры.
Agile, действительно, не делает упор на тяжёлую документацию, чтобы не замедлять процессы. Но на практике приходится искать баланс между минимальными описаниями и прозрачностью требований, и для многих команд это вопрос рано или поздно становится актуальным.
По инструментам - я действительно имела в виду процессы и подходы, а не конкретные тулзы, возможно, стоило это уточнить.
Вы абсолютно правы в том, что подобные встречи действительно должны напоминать историю про трёх друзей. На мой взгляд, груминги не должны превращаться в арену для споров. В целом, по моему мнению, здоровая коммуникация — один из ключевых факторов успеха команды. Критический взгляд должен быть направлен на поиск лучшего решения для всех, а не на подчеркивание чьих-то ошибок. Важно развивать навык слышать друг друга, даже в стрессовых ситуациях.
Что касается найма на определённые позиции, я больше выступаю в роли оптимиста и верю в то, что нужного специалиста часто можно вырастить внутри команды. При наличии энтузиазма и желания развиваться, груминги могут стать отличной площадкой для реализации такого потенциала. С небольшим менторством у специалиста появляется возможность "натренировать взгляд" и научиться конструктивной критике. Дополнительным плюсом станет расширение экспертизы и развитие культуры обмена знаниями внутри коллектива, как максимум, и расширение технической базы знаний у такого специалиста, как минимум.
Во многом это зависит от самой команды и её возможностей.
У меня в разных командах, где был опыт проведения грумингов, как правило задачи передавались из рук в руки, то есть необязательно участвовавший человек дальше смотрел задачи, которые обсуждал.
По поводу состава, я могу поделиться тремя кейсами:
1. Когда команда небольшая, и уровень тестировщиков примерно одинаковый, полезно, чтобы на встречи ходили все участники. Это помогает не только набраться опыта в техническом понимании продукта, но и способствует профессиональному росту внутри команды: появляется практический взгляд и насмотренность.
2. Когда команда большая, но уровень тестировщиков всё так же примерно одинаковый, можно ходить на груминги по очереди. Но для этого нужно заранее сформировать инструменты передачи информации - это может быть документация по шаблону, регулярные тестировочные синки или другие подходящие способы. Такой подход позволяет учиться работать с информацией и делиться ею внутри команды.
3. Когда команда большая, и уровень тестировщиков разный, участие в грумингах можно делегировать разным грейдам специалистов в зависимости от целей. Если на начальных этапах важно быстро запустить процесс, имеет смысл привлекать к обсуждению более опытных коллег, чтобы запустить процесс. Если приоритет - развитие и рост команды, стоит вовлекать в такие активности менее опытных тестировщиков, чтобы они получили необходимые знания и навыки на практике.
Что бы вы ни решили, удобнее всего пользоваться одним шаблоном для всех — так данные не теряются и все в курсе. Из моего опыта: когда я только начала участвовать на грумингах, от отдела тестирования на встречи приходили два человека — старший и младший тестировщик. Такой подход позволял не только расширять экспертизу команды, но и способствовал профессиональному росту менее опытных коллег
Надеюсь, мой опыт будет вам полезным! Буду рада, если один из кейсов подойдет вам.
Как много интересных и важных инструментов вы перечислили. Это очень здорово! Я попытаюсь разобрать их в контексте статьи. TDD и сами юнит-тесты могут в командах лежать в зоне ответственности у разных специалистов. В тех командах, которых я была, как правило, они были в руках разработки, не тестирования. Я была бы рада, если бы вы поделились своим опытом в задаче делегировании этой области в тестирование. Сами эти подходы требуют оформленной и проработанной документации с ясными требованиями, по которым возможно составить тесты. В этом как раз помогают груминги, чтобы спецификация обрела ясные контуры. Как по мне, груминги, это как раз тот этап, когда бизнес идея превращается в стабильные требования.
Что касается функциональных тестов руками, как и автотестов (ui, e2e, интеграционные, api), по моему мнению, они больше относятся не к раннему тестированию, а к самому этапу тестирования, когда тестировщик непосредственно смотрит задачу. Хотя, например, написание документации, структуры тест-кейсов, пользовательских сценариев, даже подготовка на моках, можно вынести за рамки "до отдачи кода", чтобы при проверки сократить время на подготовку. Но это так же возможно только в рамках, когда тестировщик получил ранний контекст.
Моя цель была сосредоточиться на "серых", как мне показалось, этапах в раннем тестировании, где можно сократить время и оптимизировать его для дальнейшего процесса. То есть от появления идеи до старта самого тестирования.
Если говорить о практике, на грумингах полезно сразу формировать критерии DoD, делать акцент на сценариях BDD, а также заранее обсуждать требования, связанные с переходами состояний. Это помогает команде быть на одной волне уже до старта активного тестирования
Вполне согласна, иногда грабли — это самый быстрый и эффективный учитель. Главное — сделать выводы и превратить их в ценный опыт. Здорово, что ваша команда не только прошла через это, но и выстроила рабочий процесс, который действительно приносит пользу
спасибо вам! действительно, не подумала об этом, учту на будущее :)
можно отнести к большой
поправила вопрос, чтобы не путались! спасибо
Согласна, что в разных командах подход к грумингу, документации и тестовым окружениям может отличаться. Мы тоже сталкивались с разными вариантами: где-то груминг - это только оценка задач, а где-то это полноценная площадка для обсуждения деталей и критериев качества. Здесь многое зависит от терминологии и внутренних процессов в команде.
Темы выделенных сред под каждую фичу (branch=env или пул тестовых окружений) действительно важны - такой подход ускоряет обратную связь и снижает зависимости между задачами. На мой взгляд, это отлично вписывается в agile-принципы: быстрее проверять результаты и не мешать работе других. Развёртывание изолированных сред - отдельная тема, причём тут многое зависит еще и от возможностей инфраструктуры.
Agile, действительно, не делает упор на тяжёлую документацию, чтобы не замедлять процессы. Но на практике приходится искать баланс между минимальными описаниями и прозрачностью требований, и для многих команд это вопрос рано или поздно становится актуальным.
По инструментам - я действительно имела в виду процессы и подходы, а не конкретные тулзы, возможно, стоило это уточнить.
Благодарю, что обратили внимание на эти аспекты!
Вы абсолютно правы в том, что подобные встречи действительно должны напоминать историю про трёх друзей. На мой взгляд, груминги не должны превращаться в арену для споров. В целом, по моему мнению, здоровая коммуникация — один из ключевых факторов успеха команды. Критический взгляд должен быть направлен на поиск лучшего решения для всех, а не на подчеркивание чьих-то ошибок. Важно развивать навык слышать друг друга, даже в стрессовых ситуациях.
Что касается найма на определённые позиции, я больше выступаю в роли оптимиста и верю в то, что нужного специалиста часто можно вырастить внутри команды. При наличии энтузиазма и желания развиваться, груминги могут стать отличной площадкой для реализации такого потенциала. С небольшим менторством у специалиста появляется возможность "натренировать взгляд" и научиться конструктивной критике. Дополнительным плюсом станет расширение экспертизы и развитие культуры обмена знаниями внутри коллектива, как максимум, и расширение технической базы знаний у такого специалиста, как минимум.
Во многом это зависит от самой команды и её возможностей.
У меня в разных командах, где был опыт проведения грумингов, как правило задачи передавались из рук в руки, то есть необязательно участвовавший человек дальше смотрел задачи, которые обсуждал.
По поводу состава, я могу поделиться тремя кейсами:
1. Когда команда небольшая, и уровень тестировщиков примерно одинаковый, полезно, чтобы на встречи ходили все участники. Это помогает не только набраться опыта в техническом понимании продукта, но и способствует профессиональному росту внутри команды: появляется практический взгляд и насмотренность.
2. Когда команда большая, но уровень тестировщиков всё так же примерно одинаковый, можно ходить на груминги по очереди. Но для этого нужно заранее сформировать инструменты передачи информации - это может быть документация по шаблону, регулярные тестировочные синки или другие подходящие способы. Такой подход позволяет учиться работать с информацией и делиться ею внутри команды.
3. Когда команда большая, и уровень тестировщиков разный, участие в грумингах можно делегировать разным грейдам специалистов в зависимости от целей. Если на начальных этапах важно быстро запустить процесс, имеет смысл привлекать к обсуждению более опытных коллег, чтобы запустить процесс. Если приоритет - развитие и рост команды, стоит вовлекать в такие активности менее опытных тестировщиков, чтобы они получили необходимые знания и навыки на практике.
Что бы вы ни решили, удобнее всего пользоваться одним шаблоном для всех — так данные не теряются и все в курсе. Из моего опыта: когда я только начала участвовать на грумингах, от отдела тестирования на встречи приходили два человека — старший и младший тестировщик. Такой подход позволял не только расширять экспертизу команды, но и способствовал профессиональному росту менее опытных коллег
Надеюсь, мой опыт будет вам полезным! Буду рада, если один из кейсов подойдет вам.
Как много интересных и важных инструментов вы перечислили. Это очень здорово! Я попытаюсь разобрать их в контексте статьи. TDD и сами юнит-тесты могут в командах лежать в зоне ответственности у разных специалистов. В тех командах, которых я была, как правило, они были в руках разработки, не тестирования. Я была бы рада, если бы вы поделились своим опытом в задаче делегировании этой области в тестирование. Сами эти подходы требуют оформленной и проработанной документации с ясными требованиями, по которым возможно составить тесты. В этом как раз помогают груминги, чтобы спецификация обрела ясные контуры. Как по мне, груминги, это как раз тот этап, когда бизнес идея превращается в стабильные требования.
Что касается функциональных тестов руками, как и автотестов (ui, e2e, интеграционные, api), по моему мнению, они больше относятся не к раннему тестированию, а к самому этапу тестирования, когда тестировщик непосредственно смотрит задачу. Хотя, например, написание документации, структуры тест-кейсов, пользовательских сценариев, даже подготовка на моках, можно вынести за рамки "до отдачи кода", чтобы при проверки сократить время на подготовку. Но это так же возможно только в рамках, когда тестировщик получил ранний контекст.
Моя цель была сосредоточиться на "серых", как мне показалось, этапах в раннем тестировании, где можно сократить время и оптимизировать его для дальнейшего процесса. То есть от появления идеи до старта самого тестирования.
Если говорить о практике, на грумингах полезно сразу формировать критерии DoD, делать акцент на сценариях BDD, а также заранее обсуждать требования, связанные с переходами состояний. Это помогает команде быть на одной волне уже до старта активного тестирования
Вполне согласна, иногда грабли — это самый быстрый и эффективный учитель. Главное — сделать выводы и превратить их в ценный опыт. Здорово, что ваша команда не только прошла через это, но и выстроила рабочий процесс, который действительно приносит пользу