Начните оформлять замечания заказчиков правильно

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

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

Выявленные замечания в рамках проекта внедрения фиксируются в выбранных командой проекта инструментах, используемых при тестировании: доска Trello, Jira, ClickUp - пока ещё дышат (если вы знаете другие инструменты , то поделитесь в комментариях); ну или старый добрый журнал замечаний в excel или google-таблицах.

Независимо от инструмента, замечания оформляются со следующими рекомендациями:

• оформляйте замечания на всё, где вы нашли дефект: стандартная компонента, которая не модифицировалась, но участвует в процессе, ошибки в документации или проекте тестирования и так далее. Если вы не оформите замечание, никто о нем и не узнает, и не исправит;
• перед оформлением замечания ошибку рекомендуется повторить, максимально подробно выявить предполагаемые причины её возникновения и только потом оформлять;
  
• также рекомендуется проверить, не обнаружили ли эту ошибку другие участники команды. Повторно оформлять такое замечание не нужно, но можно добавить/детализировать описание в уже оформленном замечании.
  

Общие рекомендации при оформлении замечания:

1. Оформлять замечания необходимо в инструменте, используемом при тестировании, выбранном командой внедрения.

2. Группировать замечания по разделу продукта и компонентам. Если в рамках одного замечания оформлять замечания к нескольким разделам, разработчик/ответственный за раздел продукта может неправильно понять суть.

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

4. Писать замечания в терминологии системы. При оформлении/обсуждении нового замечания необходимо общаться с командой на одном языке, чтобы все понимали друг друга.

5. Максимально подробно описать порядок действий, которые привели к появлению ситуации, по которой высказывается замечание, и условия, при которых она проявилась. Желательно вкладывать скриншоты и дополнительную информацию.

6. Описать результат, который наблюдается при выполнении действий.

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

8. Указать обоснование замечания (ссылка на пункт в проектных документах, неработоспособность системы, новое согласованное требование с Заказчиком).

9. Описать окружение, которое могло повлиять на возникновение замечания (ОС, Office и другие).

10. При возникновении ошибок системы (Например, «Внутренняя ошибка сервера») указывается дополнительная информация:

- время возникновения ошибки;

- текст ошибки;

- операция, которая выполнялась и привела к возникновению ошибки;

- ИД объектов системы;

- пользователи и роли, с которых выполнялись операции.

11. При оформлении критичных замечаний, которые не позволяют далее проводить тестирование, надо описать степень критичности и добиться оперативного исправления дефекта для дальнейшего продолжения тестирования.

Неправильное оформление замечания в Trello:

Правильное оформление замечания в Trello:

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

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

Мы благодарим Сергея Птицына, аналитика компании Акелон и автора статей о работе с замечаниями, за то что поделился опытом в блоге Kung Fu Аналитика.

Мы мечтаем сделать блог большой полезной площадкой для работы и общения аналитиков. У вас есть идеи и опыт, которыми хочется поделиться? - Пишите нам: поможем сформулировать, оформить, сверстать и по желанию - укажем авторство.