При работе над пользовательскими историями (user story) очень легко допустить оплошность. Если не выявить ошибку до начала разработки, желаемого результата можно не получить вовсе. В голове аналитика детали проекта просты и понятны, но на практике не всегда могут быть адекватно выражены в виде user story.

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

Многие из таких приемов описаны в новой книге Гойко Аджича (Gojko Adzic) «Fifty Quick Ideas To Improve Your Tests». Наиболее эффективными, с нашей точки зрения, оказались два подхода: проведение стартовой встречи (Kick-off meeting) и Desk Check (анализ историй «за столом»).

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

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

Стартовая встреча

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

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

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

В идеале, на стартовой встрече необходимо присутствие бизнес-аналитика, QA-инженера и разработчиков, тогда все они познакомятся с разрабатываемым функционалом приложения. Это сделает обсуждение более продуктивным и полезным.

Вот пример нашего списка вопросов, обсуждаемых на стартовой встрече:

1. Завершен ли анализ истории?
2. Была ли история проанализирована QA-инженером?
3. Все ли детали истории учтены, и вся ли информация верна?
4. Понятна ли ценность истории?
5. Зависит ли история от последующих историй?
6. Есть ли технический долг?
7. Есть ли макет для истории?
8. Отражены ли в истории сообщения об ошибках и другой пользовательский feedback?
9. Определены ли подсказки и метки историей? Где это отражено?
10. Устраивает ли команду объем истории?

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

Desk Check

Этот вид анализа проводится только тогда, когда группа разработчиков уверена, что разработка окончена. В списке ниже представлены следующие вопросы: было ли проведено приемочное тестирование? было ли проведено модульное тестирование? приглашали ли вы кого-нибудь проверить ваш код? тестировался ли продукт во всех (популярных) браузерах?

Эти вещи важны, и они помогают избежать проблем в будущем. Например, тот или иной функционал приложения будет отлично работать в Chrome, но отображаться в Internet Explorer с ошибками, потому что последний не поддерживает используемые вами библиотеки.

Участники: бизнес-аналитик, разработчики, заказчики (interested parties).

1. Было ли проведено достаточное количество тестов?
2. Проверялся ли код другой группой разработчиков?
3. Тестировалась ли история «вручную»?
4. Влияет ли история на что-то еще?
5. Все ли требования заказчика были учтены?
6. Нуждается ли история в комментариях или корректировке?
7. Проводился ли тест всех пользовательских возможностей?
8. Согласуется ли пользовательский интерфейс с приложением?
9. Работает ли приложение во всех основных браузерах?
10. Согласуется ли текст истории со всеми надписями и метками в приложении?
11. Проводилась ли проверка на грамматические ошибки?
12. Согласуется ли цветовое решение с остальными цветами приложения?

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

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

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

Автор:

Источник