Жизненный цикл тестирования

Жизненный цикл тестирования. Тестирование документации и требований. Свойства качественных требований.

Стадия 1 (общее планирование и анализ требований)  необходима для того, чтобы иметь ответ на такие вопросы, как: что нам предстоит тестировать; как много будет работы; какие есть сложности; всё ли необходимое у нас есть и т.п. Получить ответы на эти вопросы невозможно без анализа требований, т.к. именно требования являются первичным источником ответов.

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

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

Стадия 4 (разработка тест-кейсов) посвящена разработке, пересмотру, уточнению, доработке, переработке и прочим действиям с тест-кейсами, наборами тест-кейсов, тестовыми сценариями и иными артефактами, которые будут использоваться при непосредственном выполнении тестирования. 

Стадия 5 (выполнение тест-кейсов) и стадия 6 (фиксация найденных дефектов) тесно связаны между собой и фактически выполняются параллельно: дефекты фиксируются сразу по факту их обнаружения в процессе выполнения тест-кейсов. Однако после выполнения всех тест-кейсов и написания всех отчётов о найденных дефектах проводится выделенная стадия уточнения, на которой все отчёты о дефектах рассматриваются повторно с целью формирования единого понимания проблемы и уточнения таких характеристик дефекта, как важность и срочность.

Стадия 7 (анализ результатов тестирования) и стадия 8 (отчётность) также тесно связаны между собой и выполняются практически параллельно. Формулируемые на стадии анализа результатов выводы напрямую зависят от плана тестирования, критериев приёмки и уточнённой стратегии, полученных на стадиях 1, 2 и 3. Полученные выводы оформляются на стадии 8 и служат основой для стадий 1, 2 и 3 следующей итерации тестирования. Таким образом, цикл замыкается.

Тестирование документации и требований

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

• Продуктная документация используется проектной командой во время разработки и поддержки продукта. Она включает: 

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

2. Проектная документация включает в себя как продуктную документацию, так и некоторые дополнительные виды документации и используется не только на стадии разработки, но и на более ранних и поздних стадиях (например, на стадии внедрения и эксплуатации). Она включает:

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

На рисунке ниже показано соотношение проектной и продуктной документации

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

Что такое «требование»?

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

В них описывается поведение, свойства или атрибуты программного

продукта.  Они  могут  быть  ограничены процессом разработки системы.  

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

Уровни требований

Выделяют три уровня требований к ИС: 

•  бизнес-требования; 

•  требования пользователей; 

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

Каждая  система  имеет  свои  функциональныеи нефункциональные требования. 

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

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

Определение  границ  проекта представляет  собой первый этап  управления  общими  проблемами расползания границ. 

Требования пользователей описывают цели и задачи, которые позволит пользователям решить ПО (система). 

К способам  представления  этого  вида  требований относятся диаграммы

вариантов использования, сценарии и таблицы «событие – отклик». 

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

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

требованиями  поведения,  они  содержат  положения «должен»  или  «должна»:  «Система  должна  по  электронной  почте отправлять

пользователю подтверждение о заказе». 

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

Говоря о системе, подразумевается  программное  обеспечение  или

подсистемы  ПО  и оборудования. 

Люди – часть системы, поэтому определенные функции системы могут

распространяться и на людей.

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

снаружи границ любой системы. 

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

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

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

Ограничения касаются выбора  возможности  разработки внешнего  вида и  структуры  продукта. 

  Спецификация  требований   не  содержит  деталей дизайна или реализации  (кроме  известных  ограничений), данных о планировании проекта или сведений о тестировании.

Свойства качественных требований 

В процессе тестирования требований проверяется их соответствие определённому набору свойств (рисунок на следующем слайде)

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

Типичные проблемы с завершённостью: 

• Отсутствуют нефункциональные составляющие требования или ссылки на соответствующие нефункциональные требования (например: «пароли должны храниться в зашифрованном виде» — каков алгоритм шифрования?).
• Указана лишь часть некоторого перечисления (например: «экспорт осуществляется в форматы PDF, PNG и т.д.» — что мы должны понимать под «и т.д.»?).
• Приведённые ссылки неоднозначны (например: «см. выше» вместо «см. раздел 123.45.b»). 

Способы обнаружения проблем  

Способы устранения проблем 

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

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

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

Типичные проблемы с атомарностью:

• В одном требовании, фактически, содержится несколько независимых (например: «кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя» — здесь зачем-то в одном предложении описаны совершенно разные элементы интерфейса в совершенно разных контекстах).
• Требование допускает разночтение в силу грамматических особенностей языка (например: «если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату» — здесь описаны три разных случая, и это требование стоит разбить на три отдельных во избежание путаницы). Такое нарушение атомарности часто влечёт за собой возникновение противоречивости. 

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

Способы обнаружения проблем  

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

Способы устранения проблем 

Переработка и структурирование требований: разбиение их на разделы, подразделы, пункты, подпункты и т.д. 

• Непротиворечивость, последовательность. Требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

Типичные проблемы с непротиворечивостью:

• Противоречия внутри одного требования (например: «после успешного входа в систему пользователя, не имеющего права входить в систему…» — тогда как он успешно вошёл в систему, если не имел такого права?)
• Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком и текстом, требованием и прототипом и т.д. (например: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей» — так всё же красной или синей?)
• Использование неверной терминологии или использование разных терминов для обозначения одного и того же объекта или явления (например: «в случае, если разрешение окна составляет менее 800x600…» — разрешение есть у экрана, у окна есть размер).

Способы обнаружения проблем  

Способы устранения проблем 

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

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

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

Типичные проблемы с недвусмысленностью:

• Использование терминов или фраз, допускающих субъективное толкование (например: «приложение должно поддерживать передачу больших объёмов данных» — насколько «больших»?)

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

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

• Использование неочевидных или двусмысленных аббревиатур без расшифровки (например: «доступ к ФС осуществляется посредством системы прозрачного шифрования» и «ФС предоставляет возможность фиксировать сообщения в их текущем состоянии с хранением истории всех изменений» — Здесь ФС - не понятно, что это.
• Формулировка требований из соображений, что нечто должно быть всем очевидно (например: «Система конвертирует входной файл из формата PDF в выходной файл формата PNG» — и при этом автор считает совершенно очевидным, что имена файлов система получает из командной строки, а многостраничный PDF конвертируется в несколько PNG-файлов, к именам которых добавляется «page-1», «page-2» и т.д.). Эта проблема перекликается с нарушением корректности.

Способы обнаружения проблем  

Способы устранения проблем 

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

Самый страшный враг двусмысленности – числа и формулы: если что-то можно выразить в формульном или числовом виде (вместо словесного описания), обязательно стоит это сделать. Если это невозможно, стоит хотя бы использовать максимально точные технические термины, отсылки к стандартам и т.п.

• Выполнимость. Требование должно быть технологически выполнимым и реализуемым в рамках бюджета и сроков разработки проекта.

Типичные проблемы с выполнимостью:

• Так называемое «озолочение» — требования, которые крайне долго и/или дорого реализуются и при этом практически бесполезны для конечных пользователей (например: «настройка параметров для подключения к базе данных должна поддерживать распознавание символов из жестов, полученных с устройств трёхмерного ввода»).
• Технически нереализуемые на современном уровне развития технологий требования (например: «анализ договоров должен выполняться с применением искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора»).
• В принципе нереализуемые требования (например: «система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты»).

Способы обнаружения проблем  

Способы устранения проблем 

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

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

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

Типичные проблемы с обязательностью и актуальностью:

• Требование было добавлено «на всякий случай», хотя реальной потребности в нём не было и нет. 
• Требованию выставлены неверные значения приоритета по критериям важности и/или срочности.
• Требование устарело, но не было переработано или удалено.

Способы обнаружения проблем  

Способы устранения проблем 

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

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

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

  Типичные проблемы с прослеживаемостью:

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

Способы обнаружения проблем  

Способы устранения проблем 

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

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

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

Типичные проблемы с модифицируемостью:

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

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

Требования представлены в неудобной для обработки форме (например, не использованы инструменты управления требованиями, и в итоге команде приходится работать с десятками огромных текстовых документов).

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

Способы обнаружения проблем  

Способы устранения проблем 

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

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

Типичные проблемы с проранжированностью состоят в её отсутствии или неверной реализации и приводят к следующим последствиям: 

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

Способы обнаружения проблем  

Способы устранения проблем 

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

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

• Корректность и проверяемость. Фактически эти свойства вытекают из соблюдения всех вышеперечисленных (или они не выполняются, если нарушено хотя бы одно из вышеперечисленных). Проверяемость подразумевает возможность создания объективного тест-кейса (тест-кейсов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию.

К типичным проблемам с корректностью также можно отнести:

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

Способы обнаружения проблем  

Способы устранения проблем 

Здесь  имеем дело с «интегральной» проблемой, обнаруживается она с использованием ранее описанных способов. Отдельных уникальных методик для нет.

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