Тестирование требований — Особенности

Введение

Требования – это первое, на что смотрит команда проекта, это фундамент для проектирования и разработки продукта. Допущенная в документации ошибка или неточность может проявиться в самый неподходящий момент. Очевидно, что гораздо проще устранить дефект в паре строк требований, чем позже «перелопачивать» несколько сотен (или даже тысяч) строк кода.

Тестирование требований направлено на то, чтобы уже на начальных этапах проектирования системы устранить максимально возможное количество ошибок. В перспективе, это позволяет:

значительно снизить итоговую стоимость проекта;
улучшить качество продукта;
сохранить нервы всей команде.

Отношение к тестированию требований на проектах

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

1. Группа А: лучшие практики в деле

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

2. Группа Б: успеть все

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

3. Группа В: все усилия на разработку

Если указаны требования трехлетней давности – ты счастливчик, даже если этот функционал менялся уже 3 раза; у команды есть хоть какое-то понимание, как должна работать система. Большую же часть требований, раскиданных по чатам, приходится долго и упорно их искать (при этом со временем и сообщения из чата теряются, особенно при использовании бесплатной версии Slack). Зачастую при нахождении очередного дефекта отсутствует понимание того, как на самом деле все должно работать, кто должен править, и дефект ли это вообще. В таком случае все спорные вопросы адресуются аналитику или и без того загруженному менеджеру проекта. Ответ может занимать от часа до недели. Соответственно, в случае любой спорной ситуации тестирование останавливается на неопределенный срок.

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

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

Параметры тестирования документации

1. Четкость и ясность

Начать тестирование требований можно с поверхностного осмотра документации. Это сложно назвать именно тестированием, но нередко уже на данном этапе выявляется немало недочетов. Начнем с обычного сценария. Вы начали читать требования, и уже с первых строк у Вас возникает масса вопросов к автору (например, «Каков ожидаемый результат после нажатия на эту кнопку?» или «Что будет, если я отменю заказ?»). Это плохо. После прочтения документации не должно быть вопросов. Совсем. Требования – это как свод законов для продукта, а законы не допускают двусмысленность, «воду» и неточности. Документация должна давать предельно ясную информацию о том, как должен работать каждый отдельный модуль и весь продукт в целом. К сожалению, после прочтения большинства требований остается целый ряд вопросов.

Пример. В требованиях было записано: «В поле «Имя пользователя» могут быть введены буквы и цифры». Разработчик начал выяснять у аналитика, какие именно буквы (кириллица, латиница или арабские) и какие цифры (целые, дробные, римские) имеются в виду. После уточнения требований разработчик реализовал функционал согласно комментариям аналитика. Задача перешла в тестирование. Тестировщик не понимал, по каким критериям проверять данное поле, и тоже начал расспрашивать аналитика.

Последствия:

затраченное время нескольких членов команды;
несовпадение итогового и изначально планируемого функционалов.

Как тестировать:

если у Вас после прочтения требований остались вопросы – значит, необходима доработка;
если разработчики часто уточняют детали в чатах – это плохой знак.

Дальнейшее («более глубокое») исследование требует гораздо больших временных затрат.

2. Актуальность

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

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

Последствия:

время нескольких членов команды потрачено впустую;
итоговая позиция кнопок не соответствует ожидаемому результату.

Как тестировать:

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

3. Логика

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

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

Последствия:

пользователь в бешенстве;
дальнейшая работа с аккаунтом без обращения в техподдержку невозможна.

Как тестировать:

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

4. Возможные сценарии

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

Пример. Часто из виду упускаются такие моменты, как тексты ошибок, поведение системы при потере связи, а также обработка ошибок, связанных со сторонними сервисами (например, с оплатой).

Последствия:

при потере связи система ведет себя некорректно (отсутствие ошибок, зависание);
сообщения об ошибках не очевидны;
в худшем случае возможны репутационные или финансовые потери.

Как тестировать:

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

5. Интеграция

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

Пример. На проекте необходимо было реализовать возможность авторизации через сторонний сервис. Аналитик по ошибке изучил устаревшую документацию стороннего сервиса и описал заведомо нерабочую схему взаимодействия. Разработчики начали работу, в соответствии с готовой схемой, но постоянно получали ошибки. Они «допрашивали» аналитика, а тот в спешке звонил в техподдержку стороннего сервиса и выяснял причины ошибок.

Последствия:

задержка разработки функционала на неделю.

Как тестировать:

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

Основные принципы тестирования требований

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

Итог

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

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