Всем привет!

У меня пара вопросов по best practices взаимодействия разработчиков и QA

Вводные данные: небольшая команда, работающая по Agile, тестировщики яляются ее частью: 2 тестировщика на 4 разработчиков.

Вопросы:

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

2.1. При наборе задач в очередной спринт оценка в SP проводится относительно эталонной задачи. При этом в эталонную задачу также входит и тестирование этой эталонной задачи. Тестировщики присутствуют на покере и иногда высказывают недовольство тем, что на тестирование той или иной задачи может уйти больше времени, чем планируется. В то же время МП и разработчики могут быть не согласны с позицией QA.

2.2. Также случается так, что разработчик выполняет задачу в одном спринте, а тестироваться она начинает уже в другом.

Правильно ли в случаях 2.1 и 2.2 при расчете времени тестирования полностью полагаться на оценку в SP, данную QA? Как в ваших командах QA участвуют в формировании итоговой оценки задачи в SP?

3. Этот пункт вытекает из двух предыдущих. Разработчики и МП иногда получают со стороны QA упреки о том, что тестирование задач сложнее, чем кажется. Частенько это бывает как раз-таки на покере. Есть ли в ваших командах практики, когда тестировщики ведут просветительскую работу среди разработчиков?

Работал по той схеме, которую описал Руслан, практически один в один. Нормально так работал. Могу рассказать с позиции тестировщика, т.к сам тестер

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

Я еще не видел компаний, где бы тестировщика воспринимали как полноценного участника обсуждения)

Я еще не видел компаний, где бы тестировщика воспринимали как полноценного участника обсуждения)

Задача считается выполненной, если она протестирована тестировщиком (или тем, кто выполняет эту роль) и выкачена на стейджинг среду. В противном случае - не выполнена. Соотв. в спринт надо закладывать и разработку, и деплой, и тестирование. Если какой-то из этих этапов пропущен в спринте - задача не сделана в спринте.

Всем привет!

У меня пара вопросов по best practices взаимодействия разработчиков и QA

Вводные данные: небольшая команда, работающая по Agile, тестировщики яляются ее частью: 2 тестировщика на 4 разработчиков.

Вопросы:

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

2.1. При наборе задач в очередной спринт оценка в SP проводится относительно эталонной задачи. При этом в эталонную задачу также входит и тестирование этой эталонной задачи. Тестировщики присутствуют на покере и иногда высказывают недовольство тем, что на тестирование той или иной задачи может уйти больше времени, чем планируется. В то же время МП и разработчики могут быть не согласны с позицией QA.

2.2. Также случается так, что разработчик выполняет задачу в одном спринте, а тестироваться она начинает уже в другом.

Правильно ли в случаях 2.1 и 2.2 при расчете времени тестирования полностью полагаться на оценку в SP, данную QA? Как в ваших командах QA участвуют в формировании итоговой оценки задачи в SP?

3. Этот пункт вытекает из двух предыдущих. Разработчики и МП иногда получают со стороны QA упреки о том, что тестирование задач сложнее, чем кажется. Частенько это бывает как раз-таки на покере. Есть ли в ваших командах практики, когда тестировщики ведут просветительскую работу среди разработчиков?

Должен ли техлид проверять задачу от аналитиков и заворачивать ее до этапа оценки на доработку? Не всегда аналитики учитывают все нюансы

Всем привет!

У меня пара вопросов по best practices взаимодействия разработчиков и QA

Вводные данные: небольшая команда, работающая по Agile, тестировщики яляются ее частью: 2 тестировщика на 4 разработчиков.

Вопросы:

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

2.1. При наборе задач в очередной спринт оценка в SP проводится относительно эталонной задачи. При этом в эталонную задачу также входит и тестирование этой эталонной задачи. Тестировщики присутствуют на покере и иногда высказывают недовольство тем, что на тестирование той или иной задачи может уйти больше времени, чем планируется. В то же время МП и разработчики могут быть не согласны с позицией QA.

2.2. Также случается так, что разработчик выполняет задачу в одном спринте, а тестироваться она начинает уже в другом.

Правильно ли в случаях 2.1 и 2.2 при расчете времени тестирования полностью полагаться на оценку в SP, данную QA? Как в ваших командах QA участвуют в формировании итоговой оценки задачи в SP?

3. Этот пункт вытекает из двух предыдущих. Разработчики и МП иногда получают со стороны QA упреки о том, что тестирование задач сложнее, чем кажется. Частенько это бывает как раз-таки на покере. Есть ли в ваших командах практики, когда тестировщики ведут просветительскую работу среди разработчиков?

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

Прочтите всей командой книгу «Цель». Там есть ответ, почему так всегда делают и почему это контрпродуктивно

Всем привет!

У меня пара вопросов по best practices взаимодействия разработчиков и QA

Вводные данные: небольшая команда, работающая по Agile, тестировщики яляются ее частью: 2 тестировщика на 4 разработчиков.

Вопросы:

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

2.1. При наборе задач в очередной спринт оценка в SP проводится относительно эталонной задачи. При этом в эталонную задачу также входит и тестирование этой эталонной задачи. Тестировщики присутствуют на покере и иногда высказывают недовольство тем, что на тестирование той или иной задачи может уйти больше времени, чем планируется. В то же время МП и разработчики могут быть не согласны с позицией QA.

2.2. Также случается так, что разработчик выполняет задачу в одном спринте, а тестироваться она начинает уже в другом.

Правильно ли в случаях 2.1 и 2.2 при расчете времени тестирования полностью полагаться на оценку в SP, данную QA? Как в ваших командах QA участвуют в формировании итоговой оценки задачи в SP?

3. Этот пункт вытекает из двух предыдущих. Разработчики и МП иногда получают со стороны QA упреки о том, что тестирование задач сложнее, чем кажется. Частенько это бывает как раз-таки на покере. Есть ли в ваших командах практики, когда тестировщики ведут просветительскую работу среди разработчиков?