Привет, Хабр! На связи На связи Денис Киров, руководитель отдела тестирования "дочки" ДОМ.РФ, компании «Цифровые технологии» и Илья Новиков, главный инженер по тестированию. Сегодня мы расскажем, почему необходимо тестирование документации, и на какие грабли можно наступить, если этого не делать. 

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

Давайте определим, что является требованием: 

Спецификация требований программного обеспечения (англ. software requirements specification, SRS) — структурированный набор требований (функциональность, производительность, конструктивные ограничения и атрибуты) к программному обеспечению и его внешним интерфейсам. Предназначен для того, чтобы установить базу для соглашения между заказчиком и разработчиком (или подрядчиками) о том, как должен функционировать программный продукт. 

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

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

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

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

Сегодня мы поговорим о том, насколько важно тестировать требования и расскажем, как мы к этому пришли.  

Как было раньше 

Наша команда работает по методологии Scrum, следовательно, каждые 2 недели выпускаем релиз, тут все по классике.   

Выявив все пожелания со стороны заказчика, план по выпуску релиза строили следующим образом: 

• формировались бизнес требования; 

• аналитика составляла функциональные требования; 

• определялся скоуп задач, которые войдут в релиз; 

• проводилась оценка трудозатрат разработки; 

• по требованиям дорабатывался продукт. 

На этом этапе далее подключается тестирование: 

• проводилась оценка трудозатрат тестирования; 

• составлялась тестовая документация; 

• производилось функциональное тестирование в дэв и предпрод среде; 

• фиксирование дефектов и последующий ретест; 

• регресс/смоук тестирование; 

• демо бизнесу (опционально); 

• выпуск релиза в прод.  

Как мы жили в такой парадигме 

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

Баги, найденные при тестировании (несоответствие реализованной функциональности/задачи тому, что описано непосредственно в задаче в Jira) и замечания заказчика после демо, либо выявленные любым другим путем заводились разными сущностями. Мы проанализировали соотношение багов и «замечаний от бизнеса» и увидели, что 28% от общего кол-ва – замечания, после чего стало понятно, что необходимо менять подход. 

Как стало

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

• формируются бизнес требования; 

• аналитика составляет функциональные требования; 

На этом этапе далее подключается тестирование: 

• тестирование верифицирует составленные функциональные требования, дальнейшее движение по флоу идет только после получения подтверждения от тестирования 

• проводится оценка трудозатрат разработки; 

• проводится оценка трудозатрат тестирования; 

• составляется тестовая документация; 

• определяется скоуп задач, которые войдут в релиз; 

• по требованиям дорабатывается продукт; 

• производится функциональное тестирование в предпрод среде; 

• фиксируются дефекты и производится последующий ретест; 

• регресс/смоук тестирование; 

• демо бизнесу (опционально); 

• выпуск релиза в прод.  

Изменения, которые были внедрены в части тестирования требований: 

1. Ясность. Здесь все понятно. Читая требования не должно быть лишних вопросов. Должен быть четко определен сценарий, ожидаемый результат, указаны все атрибуты и параметры. 

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

3. Логика. Довольно прозрачный пункт. Система должна быть логичной. Должны быть учтены все моменты.  

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

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

6. Соответствие исходным БТ. Требования должны соответствовать тому, что хочет бизнес – заказчик, никакие пункты не должны быть упущены.   

Какой профит мы получили: 

• Бизнес и пользователи удовлетворены качеством продукта; 

• Требования стали более качественными и понятными всем участникам; 

• В команде все понимают последовательность действий в рамках спринта; 

• Нет переработок и негатива в команде. 

Метрика, которую мы взяли за основу – «замечания заказчика» снизилась с 28% до 19% за первый месяц после внедрения. 

Заключение

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