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

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

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

Выполнимость (feasibility)

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

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

• 
  Так называемое «озолочение» (gold plating) требования, которые крайне долго и/или дорого реализуются и при этом практически бесполезны для конечных пользователей (пример: «настройка параметров для подключения к базе данных должна поддерживать распознавание символов из жестов, полученных с устройств трёхмерного ввода»). 
  
• 
  Технически нереализуемые на современном уровне развития технологий требования (пример: «анализ договоров должен выполняться с применением искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора»). 
  
• 1   2   3   4   5   6   7   8   9   10

---

В принципе нереализуемые требования (пример: «система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты») [10]. 

Обязательность, нужность (obligation) и актуальность (up-to-date)

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

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

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

Прослеживаемость (traceability) 

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

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

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

Модифицируемость (modifiability) 

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

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

• 
  Требования неатомарны (см. «атомарность») и непрослеживаемы, а потому их изменение с высокой вероятностью порождает противоречивость. 
  
• 
  Требования изначально противоречивы. В такой ситуации внесение изменений (не связанных с устранением противоречивости) только усугубляет ситуацию, увеличивая противоречивость и снижая прослеживаемость. 
  
• 
  Требования представлены в неудобной для обработки форме (например, не использованы инструменты управления требованиями, и в итоге команде приходится работать с десятками огромных текстовых документов)[10]. 
  

---

Проранжированность по важности, стабильности, срочности (ranked for importance, stability, priority)

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

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

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

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

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

Корректность (correctness) и проверяемость (verifiability)

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

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

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

---

Техники тестирования требований

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

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

2. Следующей техникой тестирования и повышения качества требований является (повторное) использование такой техники выявления требований, как формулировка вопросов. Если хоть что-то в требованиях вызывает непонимание или подозрение – задавайте вопросы[10]. 

3. Хорошее требование является проверяемым, а значит, должны существовать объективные способы определения того, верно ли реализовано требование. Продумывание чек-листов или даже полноценных тест-кейсов в процессе анализа требований позволяет определить, насколько требование проверяемо. Помимо использования для тестирования требований в дальнейшем такие чек-листы и тест-кейсы могут составить основу тестовой документации[10]. 

4. Рисунки, схемы. Чтобы увидеть общую картину требований целиком, очень удобно использовать рисунки, схемы, диаграммы, интеллект-карты и т.д. Графическое представление удобно одновременно своей наглядностью и краткостью (например, UML-схема базы данных, занимающая один экран, может быть описана несколькими десятками страниц текста) [10]. 

5. Исследование поведения и прототипирование. Можно сказать, что прототипирование часто является следствием создания графического представления и анализа поведения системы. С использованием специальных инструментов можно очень быстро сделать наброски пользовательских интерфейсов, оценить применимость тех или иных решений и даже создать не просто «прототип ради прототипа», а заготовку для дальнейшей разработки, если окажется, что реализованное в прототипе (возможно, с небольшими доработками) устраивает заказчика[10].

---

2 СТРУКТУРНОЕ И ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ ПО

2.1 ПЛАНИРОВАНИЕ ПРОЦЕССА ТЕСТИРОВАНИЯ. ТЕСТ-ПЛАН. РИСКИ И СТРАТЕГИЯ ТЕСТИРОВАНИЯ

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

Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) [15] и стандарт IEEE 829 [16]:

• 
  Test Plan Template RUP [15];
  
• 
  Test Plan Template IEEE 829 [16].
  

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

Что надо тестировать?

• 
  описание объекта тестирования: системы, приложения, оборудование
  

Что будете тестировать?

• 
  список функций и описание тестируемой системы и её компонент.
  

Как будете тестировать?

• 
  стратегия тестирования, а именно: виды тестирования и их применение по отношению к тестируемому объекту.
  

Когда будете тестировать?

• 
  последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки
  

Критерии начала тестирования:

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

Критерии окончания тестирования:

• 
  результаты тестирования удовлетворяют критериям качества продукта;
  
• 
  требования к количеству открытых багов выполнены;
  
• 
  выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF);
  
• 
  выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB).
  

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

---

Смотрите также файлы

• Все мы едины, все мы оренбургцы так писал поэт и общественный деятель Гавриил Романович Державин.docx

• Протокол от 2022г. Рассмотрено на педагогическом совете Протокол .docx

• Отчет по производственной практике (по профилю специальности) Лит. Листов 100 втжт филиал ргупс содержание.pdf

• 10кл. Бжб2. Жер планетасындаы ауіпті алдытар, леуметтік тесіздік адам ытары жне кмек.docx

• Седьмая.docx