Question

Дарья Труфанова

Руководитель группы тестирования в AXELOT

· 10.07

Вопрос

Аналитик vs Тестировщик. Разделение ответственностей

445

Дмитрий Перов

· 11.07

Аналитик это «мостик» между бизнес-требованиями (заказчик) и командой разработки. Кто переведет с одного языка на другой и обратно. Кто понимает нюансы и бизнесовые и системные (в идеале конечно). Тестировщик проверяет конечный результат на удовлетворение этим самым требованиям. И способов проверки много.

Дарья Труфанова

· 11.07

На 100% согласна с вашим мнением)

Дмитрий Перов

· 11.07

Такого варианта и не должно быть. Тестировщик обязан докапываться до правды, но не такими методами) И тут лишь плотное взаимодействие с аналитиком поможет. По любым непоняткам идти к нему и пусть дописывает документацию, если не дошел до каких-то нюансов. Такой тандем необходим, конечно. Причем если аналитик толковый, то он будет учиться и запоминать и в будущем уже подумает 3 раза и вспомнит вопросы тестировщика, чтобы сразу отсечь возможные вопросы.

Дарья Труфанова

· 11.07

Дмитрий, в точку) Как минимизировать искажение или недостаток информации о бизнес-требованиях при тестировании? Вариант присутствия тестировщика на встречах с заказчиком исключаем)

Николай Нц

· 11.07

Аналитик и тестировщик это абсолютно разные направления ... Каждый должен заниматься своим делом. Качество будет соответствующее при таком подходе

Николай Нц

· 11.07

Требования должны быть оформлены должным образом ... Или хотя бы в гугл доках накидать. Если до тестировщика не доходят корректные требования, то он в этом не виноват. Тут уже надо разбираться с теми, кто эти требования составлял и передавал в разработку/тестирование

Дарья Труфанова

· 11.07

Николай, случались ли ситуации, когда часть требований оседает в голове аналитика и не доносится до тестировщика? Какие видите пути решения с учётом жёсткого ограничения трудозатрат для всех ролей?

Дарья Труфанова

· 10.07

Аналитики занимаются тестированием на ваших проектах?

Витольд Седышев

· 10.07

Аналитик может писать бизнес сценарии BDD (TDD). Вполне можновыстроить процесс таким образом.

Аналитик это «мостик» между бизнес-требованиями (заказчик) и командой разработки. Кто переведет с одного языка на другой и обратно. Кто понимает нюансы и бизнесовые и системные (в идеале конечно). Тестировщик проверяет конечный результат на удовлетворение этим самым требованиям. И способов проверки много.
Такого варианта и не должно быть. Тестировщик обязан докапываться до правды, но не такими методами) И тут лишь плотное взаимодействие с аналитиком поможет. По любым непоняткам идти к нему и пусть дописывает документацию, если не дошел до каких-то нюансов. Такой тандем необходим, конечно. Причем если аналитик толковый, то он будет учиться и запоминать и в будущем уже подумает 3 раза и вспомнит вопросы тестировщика, чтобы сразу отсечь возможные вопросы.
Дмитрий, в точку) Как минимизировать искажение или недостаток информации о бизнес-требованиях при тестировании? Вариант присутствия тестировщика на встречах с заказчиком исключаем)
Аналитик и тестировщик это абсолютно разные направления ... Каждый должен заниматься своим делом. Качество будет соответствующее при таком подходе
Требования должны быть оформлены должным образом ... Или хотя бы в гугл доках накидать. Если до тестировщика не доходят корректные требования, то он в этом не виноват. Тут уже надо разбираться с теми, кто эти требования составлял и передавал в разработку/тестирование
Николай, случались ли ситуации, когда часть требований оседает в голове аналитика и не доносится до тестировщика? Какие видите пути решения с учётом жёсткого ограничения трудозатрат для всех ролей?
Аналитики занимаются тестированием на ваших проектах?
Аналитик может писать бизнес сценарии BDD (TDD). Вполне можновыстроить процесс таким образом.