Является ли ответственность Junior QA за сбор требований от клиента и создание документа с областью?

Я младший QA с 2-летним опытом работы в качестве ручного тестера. В моей компании работает 1 BA, 1 Project Manager и 2 менеджера по маркетингу. Однако никто не хочет собирать требования от клиента; они просят меня сделать это и создать документ с областью.

У меня нет опыта в этом. Я попросил моего BA и PM сделать это; они сказали: «Это твоя работа, а не наша». Это верно?

Я хочу знать, кто, как правило, является правильным человеком/должностью для сбора требований от клиентов и преобразования их в документ области.

Также, если какой-либо член команды задает любой вопрос BA/PM/человеку, который собрал требования, должен ли человек попросить разрешить эти запросы или ответить «напрямую поговорить с клиентом»? Когда член команды задает вопрос клиенту, который он уже очистил, к человеку, который собрал это требование, клиент получает разочарование. Что должен делать человек в этом случае?

1
Здесь вы задаете два вопроса. Рассмотрите разделение их на два вопроса.
добавлено автор Sarov, источник

4 ответы

Правильно, у вас есть пара проблем.

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

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

Предполагая на минуту, что ваша компания не собирается нанимать новых людей или повторять существующие, у вас есть пробел. Это не непреодолимо ...

В качестве QA у вас действительно неплохая позиция. Ваша задача - обеспечить, чтобы все, что было построено, не только работало, но и соответствовало требованиям ваших клиентов. Если требования неясны, то это будет очень сложно для вас!

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

Специальная коммуникация с клиентом не плохая вещь, на самом деле это очень хорошо! Однако похоже, что это немного неструктурировано. Я бы предложил пару вещей:

  • Демонстрация вашей работы клиенту каждые две недели (я намеренно избегаю слова sprint здесь, поскольку это не похоже на то, что вы особенно ловко). Это даст клиенту возможность дать обратную связь, и вы сможете задать любой вопрос.
  • Поощряйте ВСЕ, чтобы поговорить с клиентом, я не говорю о официальных письмах - я говорю о построении отношений и общении.
  • Чтобы избежать повторения одних и тех же вопросов снова и снова, убедитесь, что запросы сначала передаются внутри, а зарегистрированные вопросы/ответы добавляются в документацию (или только журнал вопросов).

Увидите это как возможность улучшить взаимодействие вашей команды и клиента, не считайте это «вашей работой» или «моей работой».

1
добавлено

Как правило, существует четыре критерия распределения ресурсов: 1) обладание надлежащими знаниями, навыками и способностью выполнять работу; 2) доступное время для выполнения работы; 3) отсутствие конфликта интересов между различными ролями, которые можно было бы принять; и 4) назначается ответственным лицом.

Похоже, вам не удалось выполнить только один критерий.

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

1
добавлено

Правильно ли это?

Это полностью зависит от ситуации. Правильно ли это во всех ситуациях? Нет. Правильно ли это в yours ? Может быть.

Там есть несколько совпадений между Business Analyst (BA) и персоналом Quality Quality (QA). Я был когда-то в команде, где один человек был официально BA и неофициально QA; он работал достаточно хорошо.

Независимо от того, имеет ли смысл в ваша ситуация зависит от нескольких факторов. Важно то, как выглядит ваша иерархия?

Является ли PM/BA вашим прямым начальником? Если это так, то ответ Дэвида Эспины о повышении рисков для них, а затем принятие их решения является прочным подходом.

Вы разделяете непосредственного начальника? Если это так, вам следует подумать о том, чтобы пойти к этому начальнику и попросить разъяснить роли. Прямо сейчас, каждый из вас думает, что это ответственность других за сбор требований. Это несогласие вызывает путаницу и, следовательно, должно быть выяснено.

Также, если какой-либо член команды спрашивает [...], клиент получает разочарование.

Это кажется отдельным вопросом для меня (на самом деле, я не уверен, как «BA/PM не будет собирать требования», «что делать, когда BA/PM просит меня собирать требования после того, как они собрали их он сам ...), но я все равно отвечу.

Первое, что вам нужно выяснить, это why , это происходит. Почему BA/PM хочет, чтобы вы сразу обратились к клиенту - снова? Действительно ли он/она фактически получает это требование раньше, просто что-то вроде похожее ? Он забыл? Он ленив? Считает ли он, что QA необходимо более непосредственное участие в работе с клиентом? Был ли он инструктором начальника действовать таким образом? Клиент запросил это?

Вам нужно узнать why , прежде чем вы сможете решить, что такое правильный подход.

1
добавлено

объем работы во время работы - это очень прерогатива компании и превосходства, и название действительно не означает, что разные компании могут использовать разные названия для обозначения той же роли, не говоря уже о небольших и/или гибких в которой каждый участник задачи охватывает множество различных работ.

для меня, я думаю, нет, это не младшая обязанность QA вызывать требование. он должен быть BA, а для PM - расширить сферу деятельности с заинтересованными сторонами. Получение требования и анализ его требуют очень отличных хороших навыков. Как упоминал Дэвид Эспина, они рискуют.

Кроме того, на пластине QA уже есть много вещей.

0
добавлено