Освойте лучшие техники тестирования требований, чтобы обеспечить точность и полноту ваших проектов. Советы по улучшению качества и сокращению рисков.

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

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

Согласно статистике, которую указывает Стив Макконнелл в книге "Сколько стоит программный проект", порядка 30% ошибок разработки возникает по причине неправильно сформулированных требований. Именно они выступают главной опорой для составления плана разработки.

Существует множество причин, по которым этап тестирования требований крайне важен.

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

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

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

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

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

Какие могут быть последствия, если отказаться от проверки требований?

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

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

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

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

Полнота.

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

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

Корректность, согласованность и ясность.

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

Последовательность.

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

Возможность протестировать.

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

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

Соответствие целям бизнеса.

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

Неделимость требования.

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

Возможность выполнить.

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

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

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

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

Масштабируемость.

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

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

Генерация.

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

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

Создание прототипов.

То есть, прежде чем приступить к разработке основного продукта, создается его прототип. Он позволяет протестировать возможности, которые были реализованы на основании первоначальных требований. Подходит в тех случаях, если заказчик обладает достаточным на это бюджетом и имеет смутное представление о том, каким должен быть конечный результат. Возможно, ведётся разработка какого–то нового программного продукта, который ещё не представлен на рынке, либо является «сырым».

Обзор документации, требований.

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

Автоматизированный анализ согласованности.

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

Пошаговое руководство.

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

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

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

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

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

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

Моделирование.

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

Контрольные списки.

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

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

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

Увеличение времени и затрат.

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

Риск возникновения конфликта требований.

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

Риск изменения требований.

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

Неверное толкование требований.

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

Конфликт интересов.

Хотя правильнее было бы сказать, что это конфликт эго. Между заказчиком и разработчиками может возникнуть конфликт из–за непонимания друг друга. Не все требования к продукту объективны и актуальны. Если разработчики не смогут корректно и деликатно донести это до заинтересованных лиц, то это может быть воспринято как профессиональное оскорбление. В таком случае возрастает риск потерять заказчика.

Ограниченная проверка.

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