Планирование процесса автоматизации и обучение тестировщиков

управление
, , , ,
#1

Добрый день. Думаю как должно выглядить планирование автоматизации в рамках Agile. Вот есь у нас несколько проектов в компании, условно “бэкенд”/“фронтенд”. Тикеты на разработку автотестов лучше держать внутри этих же проектов или лучше завести отдельный проект в Джире? В плане репозиториев - они отдельные, но не думаю, что только от этого должно зависеть.

Плюсы и минусы отдельный проект на автоматизацию:

  1. Тестировщики сами решают когда что начинать разрабатывать
  2. Можно создать полностью отличный воркфлоу
  3. Не отвлекать продукт менеджеров и разработчиков на планированиях и дейли митингах задачами на автоматизацию.
  4. Но, не понятно, как согласовывать и координировать работу тестировщика на двух проектах.
  5. Считаю что в agile тестировщики должны быть встроенны в продуктовую команду и не должны выделяться в отдельный “сервис”.
  6. Также хотелось бы привлекать продукт менеджеров иногда возможно, помогать с приоритизацией и т.д.
  7. Хотелось бы привлекать разработчиков для парного программирования и ревью, получается тоже надо будет их координировать между двумя проектами, это сложнее.

Плюсы и минусы один проект с продуктом:

  1. Продукт менеджеры видят “лишние” таски на своей продуктовой борде, которые никакой профит клиентам вроде и не приносят.
  2. Труднее планировать и продвигать таски по автоматизации?
  3. Все будут тратить больше времени на планировании и дейли, так как эти задачи на автоматизацию также попадут на борду.
  4. Процесс более видимый, официальный и запланированный, это хорошо.
  5. Разработчиков наверное так будет проще “официально” отвлекать.
  6. Легче координировать работу, приоритизировать и тд.

1 лайк
#2

Добрый день.

  1. Отдельный проект в Jira может пригодится в случае если автоматизация идёт отдельным проектом (почти не зависит от основной разработки, отдельно управляется, имеет отдельный беклог задач и независимые сроки).
  2. Фильтры на Jira board можно настроить чтобы исключить таски на автоматы (дабы не отвлекать уважаемых продукт оунеров ).
1 лайк
#3

Как можно совместить 3 и 5?
Если автоматизаторы будут вариться в собственном соку и не отчитываться на общих митингах - это первый шаг к тому, чтобы автоматизация стала неэффективной.

Если клиент не дал добро на автоматизацию, и вы пытаетесь сделать ее как скрытый сервис для ускорения тестирования, тогда наверное. Но когда клиент знает про автоматизацию, то эти таски имеет смысл учитывать и показывать так же, как остальные таски на тестирование.

#4
  1. у каждого issue type может быть свой workflow. Например, у вас на ваши тестинг таски есть отдельный issue type (“Test Task” допустим). К этому issue type вы можете создать workflow какой захотите. Но если вы хотите чтоб всё было в одном проекте и тестинг таски появлялись на главном agile board, то надо так же не забыть добавить “общие” статусы из главного workflow
#5

В общем обсудила с коллегами и еще раз подумала, решили пропихивать автоматизацию открыто, в продуктовых командах. У кого есть опыт ведения автоматизации в отдельном проекте - буду очень рада услышать про ваш опыт.