Заметки консультанта

Шамрай Александр Владимирович

Руководство по управлению требованиями VS TFS 2010 – Контрольные списки для разработки требований

Posted by Шамрай Александр на Ноябрь 30, 2010

<<Содержание

  1. Планирование приемочного тестирования
  2. Оценка результатов приемочного тестирования
  3. Запросы на изменения
  4. Декомпозиция работ
  5. Рецензирование проектирования верхнего уровня
  6. Рецензирование детального проектирования
  7. Рецензирование документов
  8. Формальная проверка проекта
  9. Инспекция документации
  10. Приемка продукта
  11. Определение вех проекта
  12. Проверка требований
  13. Стиль требований
  14. Сценарии или процедуры тестирования
  15. Проектирование тестов
  16. Рецензирование плана тестирования
  17. План управления тестированием
  18. Рецензирование вариантов использования

Планирование приемочного тестирования
Предполагаемое использование списка Для команды проекта или менеджера закупки ПО при планировании приемочных испытаний. Этот список вопросов позволит включить важные пункты для организации эффективного приемочного тестирования продукта.
ID

Вопрос

1 Решались ли проблемы с предыдущими поставками от этого поставщика, которые могут быть включены при планировании этих приемочных тестов?
2 Определены методы проверки по каждому требованию (инспекции, анализ, демонстрации или тесты)?
3 Критерии принятия задокументированы?
4 Трассировка Требований обеспечена и все требования были учтены? (Пользовательские требования — процедура тестирования)
5 Задокументированы условия испытаний для каждой среды?
6 Определено и согласовано специальное оборудование для тестирования?
7 Если необходимо восстановление данных, то инструменты, оборудование и люди для этого определены и согласованы?
8 Есть ли люди с необходимой специализацией для проведения тестов и люди, которые имеют эту специализацию, согласованы?
9 Разработаны детальные пошаговые процедуры для каждого теста?
10 Если пользователь должен подтвердить процедуру для теста, сделал ли он это?
11 Если необходимо применение QA, запланированы ли работы для отдела QA?
12 Если пользователь (или заказчик) должен заверить тесты, это запланировано?
13 Есть ли ограничения тестирования или результатов тестирования со стороны поставщиков, которые говорят, что специальные тесты должны быть выполнены во время приемочных тестов? Если это так, они включены в план?
14 Были ли определены возможные аномалии тестирования вместе с условиями, при которых они могут возникнуть, и методы работы с ними?
15 Определены процессы работы с отклонениями от тестовых процедур?
16 Определен процесс работы с дефектами до их закрытия?
17 Процедуры и инструменты тестирования позволяют выполнять удобное регрессионное тестирование?
18 Есть ли согласованный процесс для хранения результатов тестирования, в том числе, ответственный за журнал тестирования?
19 Другое

Оценка результатов приемочного тестирования
Предполагаемое использование списка Для команды проекта или менеджера закупки ПО при планировании приемочных испытаний. Этот список вопросов позволит включить важные пункты для организации эффективного приемочного тестирования продукта.
ID

Вопрос

1 Все тестовые процедуры выполнены?
2 Аномалии были проанализированы, чтобы подтвердить правильность тестов?
3 Тесты были проведены при надлежащих условиях?
4 Тесты были заверены соответствующими людьми?
5 Восстановление данных было выполнено и проверено соответствующими лицами?
6 Отклонения были проанализированы и адресованы соответствующим лицам?
7 Все необходимые повторные тесты были выполнены без ошибок?
8 Если продукт был изменен в период тестирования, соответствующие лица проверили изменения на необходимость регрессионного тестирования?
9 ПО правильно работает с ограничениями других систем или платформ?
10 Приемочные тесты демонстрируют адекватность пользовательской документации?
11 Приемочные тесты демонстрируют адекватность обучения поставщика?
12 Приемочные тесты демонстрируют все необходимые характеристики качества?
13 Другое

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

Вопрос

Информация, предоставляемая поставщиком Запроса на Изменение
1 Уникальный идентификатор для запроса
2 Дата запроса
3 Кто внес запрос?
4 Тип запроса (например, дефект, улучшение, проблема и т.д.)
5 Запрос для какого продукта?
6 Запрос для какой версии?
7 Во время какой фазы обнаружен? (например, сборка, тестирование, внедрение, эксплуатация и т.д.)
8 Описание запроса
9 Важность для пользователя (пользовательский приоритет и уровень важности)
10 Другие
Информация, заполняемая экспертом
11 Имя эксперта
12 Дата экспертизы
13 Описание экспертизы
14 Если это дефект, наименование части жизненного цикла, в которую дефект был вставлен.
15 Если это дефект, наименование части жизненного цикла, в которой дефект был обнаружен.
16 Описание исправления
17 Время на исправление
18 Основные причины
19 Влияние изменения (описать все применяемые области)
Влияние на размер
Влияние на границы
Влияние на бюджет
Влияние на разработку
Влияние на график
Влияние на качество
Другое влияние
20 Влияние, если не будет исправлено
21 Приоритет разработки (приоритет для разработчика)
22 Рекомендуемая реализация
23 Рекомендуемое распоряжение
24 Другое
Параметры отслеживания запроса
25 Состояние запроса (например, открыт, на экспертизе, утвержден/отклонен, в процессе, завершен, закрыт и т.д.)
25 Дата утверждения/отклонения
25 Кем утвержден
25 Дата завершения
25 Дата закрытия
25 Кем закрыт
25 Другое

Структура декомпозиции работ
Предполагаемое использование списка Для команды проекта, менеджера и/или наставника для разработки или проверки структуры декомпозиции работ.
Руководства декомпозиции работ Декомпозиция работ предполагает разделение основных работ проекта на небольшие, более управляемые компоненты до тех пор, пока эти работы не будут достаточны для поддержки задач будущего проекта (планирование, исполнение, контроль и закрытие)
ID

Вопрос

1 Все работы представлены в плане?
2 Каждый рабочий элемент связан с одной задачей в плане?
3 Каждая задача имеет определенные критерии окончания?
4 Каждая задача имеет единственный связанный рабочий элемент?
5 Каждая задача требует небольшое количество людей для реализации?
6 Каждая задача настолько мала, что позволяет быстро обнаружить проблему для ее быстрого исправления?
7 Декомпозиция задач уточняется при выполнении проекта?
8 Задачи были декомпозированы корректно?
Элементы нижнего уровня необходимы и достаточны для выполнения декомпозируемого элемента? Если нет, составные элементы должны быть модифицированы (добавлены к, удалены из или пересмотрены).
Каждый элемент четко и полностью определен? Если нет, то описания должны быть модифицированы или расширены.
Возможно ли на каждый элемент надлежащим образом определены плановые сроки и бюджет? Возможно ли на каждый элемент соответствующим образом назначить специальную организационную единицу (например, отдел, группа или лицо), которая будет нести ответственность за удовлетворительное завершение этого элемента? Если нет, то необходимо внести изменения, чтобы обеспечить адекватный контроль для управления.
9 Элементы декомпозиции часто забываются
Верификация и валидация включены?
Управление проектом и администрирование включены?
Анализ обеспечения качества включен?
Управление конфигурациями включено?
Документация (руководства, процедуры) включены?
Разработка тренингов и тренинги включены?

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

Тип дефекта

Вопрос

Организация и Структура Документации
1 Стандарты Каждый компонент спецификации соответствует стандартам организации?
2 Стандарты Целевая аудитория определена?
Полнота и корректность
3 Неполный Все элементы проекта верхнего уровня включены?
4 Неполный Все предложения проектирования включены в спецификацию?
5 Некорректный Документ не имеет фактических ошибок?
6 Неполный Основные альтернативные пути и их оценки представлены? Компромиссные проекты и критерии выбора задокументированы?
7 Неполный Критерии или условия, необходимые для разработки эффективного решения, адекватно описаны? Разумны ли они?
8 Неполный Проект отражает действительную операционную среду, аппаратное и программное обеспечение?
9 Неполный Вопросы производительности затронуты?
10 Неполный Все возможные состояния и сценарии рассмотрены?
11 Неполный Требования к хранению данных определены?
12 Неполный Проект описывает обнаружение ошибок и восстановление?
13 Неполный Есть ли модель пользовательского интерфейса?
14 Неполный Есть ли модели для других интерфейсов?
15 Неполный Количество и сложность интерфейсов задокументированы?
16 Неполный Есть ли функциональная модель высокого уровня?
17 Неполный Есть ли концептуальное представление для всех составных элементов данных?
18 Неполный Управление и использование общих данных описано?
Последовательность и прозрачность
19 Неоднозначный Документ имеет неоднозначные и слова, имеющие различные варианты интерпретации?
20 Непоследовательный Документ последователен между своими компонентами?
21 Неоднозначный Границы и ограничения проекта ясны, и в документе четко указано, какие функции будут (и не будут) обеспечены и какие ожидания будут (и не будут) удовлетворены?
22 Неоднозначный Существуют ли ограничения и последствия, если таковые имеются, в этом решении ясно описано?
23 Непроверяемый Может проект быть поэтапно протестирован и интегрирован?
24 Непоследовательный Проект соответствует установленным бизнес практикам и стандартам?
Трассируемость
25 Другое — Трассируемость Проект имеет связь с требованиями?
26 Другое — Трассируемость Требования имеют связь с проектом?
Интерфейсы
27 Другое – Качество Дизайна Документ удовлетворяет потребности аудитории?
28 Другое – Качество Дизайна Проект адаптивен к будущим изменениям?
29 Другое – Качество Дизайна Проект модульный?
30 Другое – Качество Дизайна Модули имеют сильное зацепление и слабую связанность?
31 Другое – Качество Дизайна Проект отражает систему, которую просто поддерживать?
32 Другое – Качество Дизайна Есть разумные доводы того, что люди, которые разработали проект, задали правильные вопросы и действительно поняли потребности и проблемы клиентов?

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

Тип дефекта

Вопрос

Организация и Структура Документации
1 Стандарты Каждый компонент спецификации соответствует организационным стандартам?
2 Стандарты Документ прост в использовании и поддержке?
Полнота и корректность
3 Неполный Все компоненты или интерфейсы, которые необходимы для этой части архитектуры системы, выявлены и полны?
4 Неполный Каждый компонент проектной спецификации внутренне полон? Это задокументировано адекватно?
Последовательность и прозрачность
5 Непроверяемый Каждый элемент дизайна тестируемый или как-то иначе проверяемый?
6 Непроверяемый Каждый элемент может быть протестирован, продемонстрирован или проанализирован на соответствие требованиям и, следовательно, проверен?
7 Непоследовательный Детализируемые компоненты и их интерфейсы согласованы с друг с другом?
8 Непоследовательный Спецификация каждого компонента последовательна внутри?
Данные
9 Данные Все внутренние данные, которые необходимы для каждого компонента, определены?
10 Данные Все элементы данных имеют наименование и используются согласовано в проекте?
11 Данные Все внешнее использование общих данных идентифицировано?
12 Данные Все внешнее использование общих данных определено?
13 Данные Существуют какие-либо конфликтные использования данных?
14 Данные Переменные инициализируются и их значения проверяются перед использованием?
Интерфейсы
15 Интерфейс Детальный проект связан с проектом высокого уровня?

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

Тип дефекта

Вопрос

Организация и структура документации
1 Стандарты Цели документа определены?
2 Стандарты Технический уровень соответствует выбранной аудитории и целям?
3 Стандарты Формат документа последователен?
4 Стандарты Документ отвечает стандартам документации?
5 Стандарты Организация документа способствует простому поиску информации?
Полнота и корректность
6 Неполный Все фазы жизненного цикла документа были пройдены?
7 Неполный Отзывы пользователей были получены?
8 Неполный Адекватны ли условия для поставки документации и последующих изменений?
9 Неполный Все содержание документа адекватно?
10 Неполный Все важные темы присутствуют?
11 Некорректный Документация не имеет актуальных ошибок?
12 Неполный Есть ли глоссарий, если необходимо? Он полон?
13 Некорректный Определения верны?
14 Неполный Есть ли лист содержания, если необходимо?
15 Некорректный Лист содержания корректный и легкодоступен?
16 Неполный Разделы руководства включены, если необходимо?
17 Некорректный Примеры, диаграммы, рисунки и другие визуальные материалы корректны?
18 Неполный Есть ли индекс, если необходимо? Он легкодоступен?
19 Неполный Индекс адекватно детализирован
20 Некорректный Номера страниц в индексе совпадают?
21 Неполный Все ли элементы, которые могут искать различные пользователи, включены в индекс?
Последовательность и прозрачность
22 Неоднозначный Цели документа четко определены?
23 Непоследовательный В документе отсутствуют противоречия?
24 Неоднозначный Верна ли терминология? Она соответствует аудитории и целям?
25 Непоследовательный Терминология непротиворечива в документе?
26 Неоднозначный Стиль написания понятен? Отдельные параграфы отражают только одну мысль или связанные мысли?
27 Неоднозначный Примеры, диаграммы, рисунки и другие визуальные материалы понятны?
28 Непоследовательный Примеры, диаграммы, рисунки и другие визуальные материалы необходимы и относятся к тому месту, где используются?
29 Непоследовательный Индексы находятся под правильными разделами?

Формальная проверка проекта
Предполагаемое использование списка Выполняя формальную проверку проекта, рецензент может использовать эти вопросы.
ID

Вопрос

Статическая документация
1 Описание проекта (назначение, границы и цели)
2 Основные заинтересованные лица, включая спонсоров
3 Основные поставки, включая бизнес цели и выгоду
4 Архитектурные диаграммы высокого уровня, отражающие организационные и системные интерфейсы
5 Команда проекта
Промежуточная версия документации
6 Описание проекта (назначение/границы/цели)
7 Основные заинтересованные лица, включая спонсоров
8 Основные поставки, включая бизнес цели и выгоду
9 Архитектурные диаграммы высокого уровня, отражающие организационные и системные интерфейсы
10 Команда проекта
Документация по рискам
11 Основные проблемы и вопросы
12 Основные риски
13 Основные зависимости, особенно которые в ожидании или в риске
Планируемая на последующие шаги документация
14 Основные промежуточные корректировки, связанные с требованиями, кадровым обеспечением и зависимостью изменений
15 Основной план рисков (стратегия снижения и план последствий)
16 Следующие шаги
17 Запрос помощи от исполнителей, если требуется
18 Специализированная отчетность только по этому проекту (добавление любых необходимых отчетов для последующего использования)

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

Тип дефекта

Вопрос

1 Прозрачность Некоторые элементы документа сложны восприятия или весь документ сложно читать.
2 Полнота Некоторые необходимые компоненты пропущены.
3 Сложность Некоторые части документа необходимо упростить для целевой аудитории.
4 Последовательность Некоторые части документа конфликтуют с другими связанными документами.
5 Корректность Документ имеет ошибки.
6 Определение Определения пропущены, ошибочны или лишние.
7 Формат Документ не соответствует предопределенному формату организации для этого типа документа.
8 Грамматика Присутствуют грамматические ошибки в документе
9 Организация Порядок, в котором представлен документ, неудобен и неэффективен.
11 Излишество Некоторые части документа избыточны и не соответствуют целям документа.
12 Пунктуация Присутствуют несоответствия в пунктуации и выделениях в документе.
13 Стандарты Документ не соответствует стандарту документации для этого типа документа.
14 Стиль Документ в некоторых моментах не соответствует руководству организации по стилям документации.
15 Версия Нигде нет информации о версии или она не соответствует стандартам организации.

Приемка продукта
Предполагаемое использование списка Для команды проекта или менеджера закупки ПО для использования для оценки продукта для финальной приемки.
ID

Вопрос

1 Результаты приемочных тестов проанализированы?
2 Поставляемые материалы соответствуют всем функциональным требованиям?
3 Поставляемые материалы соответствуют всем требованиям к продукту?
4 Готова ли документация по эксплуатации?
5 Соответствующие люди проверили и утвердили документацию (заказчик, покупатель и поставщик)?
6 Документация соответствует конечному продукту?
7 Информация о релизе описывает дефекты и методы их обхода?
8 Если существуют требования обязывающие принять продукт «как есть», соответствующие документы были оформлены и утверждены?
9 Все ли поставки, описанные в контракте, были предоставлены поставщиком?
10 Все ли поставки, описанные в контракте, были обновлены до последней версии?
11 Описаны ли процедуры обработки ошибок после поставки продукта?
12 Если предусмотрено контрактом, программное обеспечение и другие необходимые артефакты были помещены под условное хранение?
13 Если продукт будет поддерживаться поставщиком, существует ли соответствующие последующее соглашение, которое позволяет закрыть текущее соглашение?
14 Все ли нерешенные вопросы, связанные с продуктом или контрактом, были обработаны и закрыты?
15 Другое

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

Вопрос

Документ Границы Проекта на достаточном уровне описывает, что проект должен достичь и в какой среде? Следующие пункты должны быть определены:
1 Общие Границы Проекта
2 Элементы вне границ
3 Бизнес Цели/Потребности
4 Бизнес и Технические Ограничения
5 Разделы по Изменениям в Бизнес Процессе/Получение Подтверждения Изменений
6 Основные Интерфейсы/Интеграционные Требования
7 Основные Системные Возможности и Функции с указанными потенциальными релизами продукта
8 Затрагиваемые Организации и Подразделения
Альтернативы Продукта определены и рассмотрены? Компоненты могут включать:
9 Технико-экономическое обоснование
10 Оценка Альтернативных Решений (включая существующие приложения и/или компоненты)
11 Потенциальные Продукты Поставщика
12 Анализ необходимости Покупки или Разработки
Условия Развертывания были задокументированы и рассмотрены соответствующими участниками?
13 Все основные вопросы, поступившие от рецензентов, были решены?
План проекта это включает?
14 Высокоуровневую оценку по стоимости и трудозатратам для всего проекта
15 Детальную оценку стоимости трудозатрат, стоимости, плана и планируемых трудовых ресурсов для фазы Анализа
16 Предлагаемый жизненный цикл
17 Проектные роли и ответственности
18 Начальный набор проектных рисков и планы снижения
Анализ оценки рентабельности выполнен?
19 Какой приоритет у проекта по сравнению с другими проектами, которые находятся в очереди ожидающих разработку проектов?

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

Тип дефекта

Вопрос

Организация и структура документа
1 Стандарты Соответствующие стандарты документирования требований выдержаны?
2 Стандарты Все рисунки, таблицы и диаграммы подписаны и имеют ссылку?
3 Стандарты Все термины и единицы измерений определены?
4 Стандарты Все требования описаны последовательно и на соответствующем уровне детализации?
5 Стандарты Отдельные требования имеют ранг с описанием установленного приоритета?
6 Непроверяемое Требования обеспечивают адекватный базис для разработки и системного тестирования?
Полнота и корректность
7 Корректность Все ли внутренние перекрестные связи с другими требованиями корректны? (Для модифируемости минимизируйте перекрестные связи)
8 Неполное Все классы пользователей описаны? Все пользовательские характеристики описаны?
9 Неполное Спецификация включает все известные потребности заказчика или системы? Все ли задачи, которые необходимо выполнять пользователям, указаны?
10 Неполное Каждое функциональное требование описывает вход, выход и функцию, если это необходимо?
11 Неполное Все зависимости от других систем определены? Включены другие приложения или интерфейсы приложений, базы данных, связующие подсистемы, сеть и т.д.
12 Неполное Требования к документации и обучению определены?
13 Неполное Аппаратная и программная среда указана?
14 Неполное Все поставляемые требования были включены? Здесь включаются те, которые подразумевают системные и программные требования, которые в основном ограничивают разработку или верификациию.
15 Неполное Полный жизненный цикл определен, включая поддержку?
16 Неполное Какие либо ограничения разработки и реализации описаны?
17 Неполное Все требования к надежности, восстанавливаемости (непрерывности бизнеса) и производительности правильно указаны??
18 Неполное Все требования к безопасности правильно указаны?
19 Неполное Все требования к защищенности правильно указаны?
20 Неполное Все требования к конфиденциальности данных указаны?
21 Неполное Определены ли критичные ко времени/длительности функции, и критерии определения времени указаны для них?
22 Неполное Нормативные, законодательные и требования на основе стандартов были указаны?
23 Неполное Все атрибуты (характеристики) качества были правильно указаны (например, эффективность, гибкость, совместимость, возможность поддержки, мобильность, возможность многократного использования, удобство и доступность)?
24 Неполное Требования к непрерывности бизнес процесса и восстановлению после сбоев были учтены?
25 Интерфейс Требования к интерфейсам взаимодействия с пользователем были учтены? Они корректны?
26 Интерфейс Все внешние аппаратные, программные и коммуникационные интерфейсы определены? Они корректны?
Последовательность и прозрачность
27 Противоречивое Спецификация согласуется с соответствующими документами верхнего уровня?
28 Противоречивое Требования имеют дубликаты или конфликты с другими требованиями?
29 Противоречивое Все требования написаны последовательно, понятно и лаконично?
30 Неоднозначное Каждое требование имеет только одну интерпретацию? Если термины имеют несколько значений, это указано?
31 Непроверяемое Каждое требование может быть проверено через тест, демонстрацию, рецензию или анализ?
32 Непроверяемое Существуют измеряемые критерии приемки для каждого функционального или нефункционального требования?
Трассируемость
33 Интерфейс Каждое требование уникально и корректно идентифицировано?
34 Интерфейс Каждое требование имеет связь с его источником (включая производные требования)?
35 Другое Каждое требования в границах проекта?

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

Вопрос

1 Каждое требование должно включать слова должно быть или должно.
2 Каждое требование должно быть написано в кратком предложении и с использованием простых терминов.
3 Каждое предложение должно включать только одно требование.
4 Каждое требование должно четко совпадать с содержанием, приведенным в предложении.
5 Обобщающие термины (такие как все, каждый, никогда и всегда) не должны использоваться в требованиях, если требование должно быть проверяемым.
6 Неопределенные термины (такие как будет определено в дальнейшем, будет описано в дальнейшем и т.д.) не должны использоваться в требованиях, кроме случаев, когда будут выполнены согласования и утверждения для каждого такого термина.
7 Каждое требование должно быть написано в утвердительной форме.
8 Каждое требование должно быть грамматически правильным.
9 Объединение И показывает, что все элементы в требовании должны быть в значении «истина», чтоб удовлетворять назначению требования.
10 Каждое требование, которое включает объединение ИЛИ должно четко показывать где «включаемое или» или «исключаемое или». «Включаемое или» позволяет одному или обеим альтернативам быть в значении «истина», а «исключаемое или» позволяет только одной альтернативе быть в значении «истина».
11 Использование косой черты , например, и/или или проводник/земля не должны использоваться в требованиях.
12 Каждое требование должно быть в границах проекта.
13 Термины и сокращения должны быть определены в глоссарии, списке или в тексте.

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

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты Соответствующие заинтересованные лица были вовлечены в разработку и утверждение сценариев тестирования и процедур тестирования?
2 Стандарты Люди, которые разрабатывают тестовые сценарии или процедуры, имеют глубокий опыт в области приложений, технической среды и техник тестирования, чтоб быть достаточно способными для разработки адекватных тестов?
3 Стандарты Тестовые процедуры или сценарии отвечают стандартам организации?
Полнота и корректность
4 Неполный Когда выполняется оценка всего пакета тестов, сценарии или процедур тестирования охватывают все типы необходимых тестов (например, тестирование функциональности приложения, тестирование производительности, тестирование удобства использования, тестирование на нескольких платформах, он-лайн помощи, тестирование документации пользователя и т.д.)
5 Неполный В каждом тесте полностью указаны все необходимые входные параметры, альтернативные пути и ожидаемый результат?
6 Другое Отдельные тесты возможны и выполнимы?
7 Неполный Описание целей каждого теста полное?
8 Другое Описание целей каждого теста точное?
9 Неполный Ожидаемый результат для каждого шага каждого теста описан, даже если входные параметры вне требуемого диапазона?
10 Неполный Тестовые сценарии демонстрируют реакцию системы на неправильные или конфликтующие входные параметры?
11 Неполный Зависимости тестовых процедур идентифицированы?
12 Неполный Каждая процедура тестирования определяет предшествование вовлеченных тестов?
Последовательность и прозрачность
13 Другое Пользовательские инструкции подробны и понятны для выполнения каждого тестового сценария?
14 Другое Инструкции для каждого теста представляют пошаговое и упорядоченное выполнение?
15 Неоднозначный Критерии успешного выполнения или провала теста понятны и однозначны?
16 Противоречивый Глубина и основательность тестирования (т.е. процент детального покрытия, которые обеспечивает тест) для каждой возможности совпадает с операционным профилем этой возможности?
17 Противоречивый Величина функционального покрытия соответствует рискам продукта?
18 Противоречивый Процедуры тестирования совместимы с возможностями средств тестирования?
Трассируемость
19 Интерфейс Тестовые сценарии обратно связанны с требованиями?
20 Интерфейс Есть ли перекрестная связь между сценариями тестирования и тестируемыми возможностями?

Проектирование тестов
Предполагаемое использование списка Когда выполняется спецификация проектирования тестов, автор может использовать этот список для качества законченного продукта. Рецензент может использовать эти вопросы для оценки сценариев и процедур тестирования через формальные инспекции или другие типы рецензирования.
ID

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты Соответствующие заинтересованные лица были вовлечены в разработку и утверждение?
2 Стандарты Люди, которые разрабатывают тесты, имеют глубокий опыт в области приложений, технической среды и техник тестирования, чтоб быть достаточно способными для разработки адекватных тестов?
3 Стандарты Тестовые процедуры или сценарии отвечают стандартам организации?
Полнота и корректность
4 Неполный Границы проекта тестирования охватывают все типы тестов, которые необходимы, как указано в плане тестирования?
5 Неполный Проект тестирования включает методы определения ответа системы на неправильные и конфликтующие входные параметры?
6 Неполный Проект тестирования содержит критерии успешного выполнения или провала теста для каждой тестируемой возможности
7 Неполный Все ли поддерживаемые тестовые сценарии перечислены в спецификации проекта тестирования?
8 Неполный Каждый перечисленный тестовый сценарий имеет процедуры, определяющие его использование?
Последовательность и прозрачность
9 Противоречивый Глубина и основательность методов тестирования для каждой возможности совпадает с операционным профилем этой возможности?
10 Непонятный Критерии для теста «успешен-провален» понятны и однозначны?
11 Противоречивый Элементы, которые будут тестироваться, непротиворечивы с тестируемыми возможностями?
12 Противоречивый Величина функционального покрытия соответствует рискам продукта?
13 Противоречивый Возможности (или комбинация возможностей), которые будут тестироваться в этом проекте, совпадают с теми, которые были указаны в плане тестирования для этого теста?
14 Противоречивый Все тестовые элементы этого проекта тестирования соответствуют тем, которые идентифицированы в плане или планах тестирования?
15 Противоречивый Этот проект связывает каждую возможность (или комбинацию возможностей), которая будет тестироваться в этом проекте тестирования, с одним или более описанием требований или дизайна?
16 Противоречивый Этот проект связывает каждую возможность (или комбинацию возможностей), которая будет тестироваться в этом проекте тестирования, со всеми связанными описаниями требований или дизайна?

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

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты План тестирования соответствует шаблону плана тестирования или каким-то другим стандартам?
2 Стандарты Существуют ли перекрестные ссылки между планом тестирования и планом проекта для проекта, продукт которого будет тестироваться?
3 Стандарты Все ли заинтересованные лица вовлечены в разработку и утверждение плана тестирования?
Полнота и корректность
4 Неполный План определяет, что нужно тестировать и что не нужно тестировать?
5 Неполный План определяет критерии приемки?
6 Неполный Результирующие артефакты тестирования определены в плане?
7 Неполный Стратегия тестирования явно описана?
8 Неполный Все необходимые фазы тестирования указаны в плане тестирования?
8 Неполный План описывает ресурсы необходимые для выполнения плана?
9 Неполный Ресурсы назначены рационально по объему, доступности и уровню?
10 Неполный Риски, связанные с качеством продукта, определены в плане тестирования?
11 Неполный План содержит мероприятия по управлению рисками?
Последовательность и прозрачность
12 Противоречивый Заданные границы трассируются с требованиями к продукту?
13 Противоречивый Если некоторые возможности не тестируются или тестируются незначительно, это оправдано?
14 Противоречивый Если тест для нового релиза или обновления существующей системы, регрессионное тестирование не противоречит этой частной ситуации?
15 Противоречивый Логистика соответствует стратегии и ресурсам, определенным в плане?
16 Противоречивый Планируемый объем работ по тестированию пропорционален объему трудозатрат разработки и поддержки проекта?
Элементы, связанные с План Управления Тестированием
Полнота и корректность
17 Неполный План тестирования определяет критические факторы успешности продукта?
18 Неполный Документ явно определяет пользовательские (заказчика) критерии приемочного тестирования?
19 Неполный Общие цели тестирования явно определены?
20 Неполный План включает мероприятия по обеспечению качества для работ по тестированию?
21 Неполный План включает или ссылается на процессы управления конфигурацией?
22 Неполный План включает описание организации команды тестирования, включая структуру отчетности?
23 Неполный План явно идентифицирует какие фазы и цели тестирования должны быть выполнены?
24 Неполный Если тест для нового релиза или обновления существующей системы, опыт взаимодействия с системой и ее история предыдущих ошибок отражена в плане для тестовых сценариев?
Элементы, связанные с Детальным Планом Тестирования
Полнота и корректность
25 Неполный Задачи тестирования указаны в плане тестирования?
26 Неполный План описывает инструменты, которые должны использоваться для тестирования продукта?
27 Неполный План обучения инструментам (если необходимо) оговариваются планом?
28 Неполный Задачи по подготовке среды тестирования включены в план?
Последовательность и прозрачность
29 Противоречивый Глубина и основательность тестирования (например, процент детального покрытия, которые обеспечивает тест) совпадает с рисками продукта?
30 Неоднозначный Критерии успешного выполнения или провала теста понятны и однозначны?

План управления тестированием
Предполагаемое использование списка Для команды тестирования при оценке их программных (или системных) планов тестирования для определения или соответствующие элементы покрыты.
ID

Вопрос

1 План тестирования соответствует общему плану проекта?
2 Главные функции запланированы для тестирования на ранних стадиях цикла тестирования?
3 График тестирования явно определен?
4 Ресурсы тестирования (свободное место, оборудование и персонал) уже доступны или планируется их доступность, когда это необходимо?
5 Инструменты тестирования уже доступны или они будут доступны, когда будет необходимо?
6 Механизм хранения результатов тестирования установлен?
7 Все соответствующие фазы тестирования, роли и ответственности в плане установлены (тесты модульные, системные, альфа, беты, приемочные и т.д.)?
8 Если необходимо, указаны и запланированы тесты по миграции данных, больших объемов данных, нагрузочному и стрессовому тестированию?
9 Если необходимо, производительность будет выполняться согласно спецификации продукта?
10 Все требования тестирования, которые указаны в документе по требованиям, затронуты?
11 Критерии приемки для продукта были определены?
12 Риски для плана тестирования определены, и планы смягчения разработаны?
13 Существует ли планы реакции для рисков, которые могут осуществиться?
14 Мероприятия по управлению рисками отслеживаемы?
15 Есть ли полный список того, что не будет тестироваться?
16 Другое

Рецензирование вариантов использования
Предполагаемое использование списка Когда рассматривается вариант использования, рецензент может использовать следующие вопросы для определения или вариант использования адекватен для последующей инспекции и другого типа рецензирования.
ID

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты Вариант использования самостоятельная, дискретная задача?
2 Стандарты Вариант использования написан на необходимом уровне, а не как конкретные сценарии?
3 Стандарты Вариант использования не имеет описания разработки или реализации?
4 Стандарты Вариант использования ограничен 10 шагами или менее?
5 Стандарты Варианты использования именуются фразой в виде глагола целевого действия, что указывает на цель основного актора?
Полнота и корректность
6 Неполный Цели всех акторов затронуты?
7 Неполный Все акторы представлены (прямо или косвенно)?
8 Неполный Все ожидаемые альтернативные варианты задокументированы?
9 Неполный Все известные условия исключений задокументированы?
10 Неполный Последовательности диалога для каждого курса полны?
11 Некорректный Главный актор в каждом варианте использования подходит для выполнения этой задачи?
12 Некорректный Описанный курс в варианте использования выполним?
13 Некорректный Каждый шаг в варианте использования подходит для достижения цели варианта использования?
14 Некорректный У основного актора есть верное поведение?
Последовательность и прозрачность
15 Неоднозначный Цели или измеряемое значение варианта использования понятны?
16 Неоднозначный Понятно какой атор или акторы получают выгоду от варианта использования?
17 Неоднозначный Всевозможные общие последовательности действий были заложены в отдельные варианты использования?
18 Неоднозначный Последовательность диалога для каждого курса описана понятно и однозначно?
19 Непроверяемый Каждый курс, описанный в варианте использования, проверяем?
Advertisements

Один ответ to “Руководство по управлению требованиями VS TFS 2010 – Контрольные списки для разработки требований”

  1. valensiyabest said

    Млин… мне тут за год не разобраться! 😦

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: