# ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Теория ограничений АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision (Концепция) Сервисы АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Solution Design (Проектное решение) DDD Микросервисы и service mesh ESB HTTP/REST RPC DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Шаблоны Тестирование требований Тест-анализ Тест план Тест дизайн Метрики качества Автотесты Selenium XPATH Генератор данных Безопасность Нагрузочное ДАННЫЕ Ресурсы MDM Big data Об информации SQL intro MongoDB intro БИБЛИОТЕКА Курсы Системная инженерия Сознание, интеллект Политэкономия Сумма технологии Экстраполяция в будущее Красивые диаграммы Арт
Эта страница:
Черпнуть мудрости Зачем Кто Когда Что делать Результат
Другие страницы:
ТЕСТИРОВАНИЕ Тестирование требований Тест-анализ Тест план Тест дизайн Метрики качества Android Автоматизация Selenium WebDriver XPATH Генератор случайных данных Различные расчёты Безопасность Нагрузочное
Другие разделы:
# АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Тестирование требований
last update: 16-07-2020, 13:23
Черпнуть мудрости
Зачем
Тестирование Бизнес-, Пользовательских и Системных требований направлено на то, чтобы уже на начальных этапах проектирования Продукта/Системы устранить максимально возможное количество ошибок.
Это позволяет:
  • снизить итоговую стоимость Проекта/доработки;
  • повысить скорость в цепи поставки / сэкономить время в Проекте;
  • улучшить качество Продукта/Системы;
  • сохранить нервы всей команде.
Кто
  • тест-аналитики
  • тестировщики
В любом случае, это должны быть НЕ авторы требований.
Качество проверки документации зависит от квалификации сотрудника, который её проводит. Для этой задачи стоит выделить опытного специалиста.
Когда
До старта разработки. Для этого нужно рассчитать необходимое время на проверку и заморозить тестируемую документацию до окончания проверки.
В том случае, когда проверка требований ведется параллельно с разработкой, крайне важно оперативно предупредить Разработчиков и Аналитиков о найденных дефектах, чтобы они могли вовремя исправить ошибку.
Что делать
В документе, содержащем Требования, нужно проверить:
  1. Что нет опасных и подозрительных путаных опечаток:
    Разработчики/Аналитики иногда дают похожие названия компонентам, методам, сущностям, полям. И в документации начинает возникать путаница: написали одно, а имели в виду другое;
  2. Завершённость и полноту требований. Каждое требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям "это и так всем понятно".
    1. поискать неучтённые случаи, используя карту состояний или диаграмму переходов;
    2. нет видимых логических нестыковок в схемах и диаграммах, описывающих те самые состояния и переходы.
  3. Непротиворечивость и последовательность -- каждое требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам. Логика новых/изменённых функций составлена с учётом ранее реализованных и логически связанных с изменениями функций и не портит их.
  4. Недвусмысленность -- требование должно быть описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок, должно допускать только однозначное объективное понимание и быть атомарным в плане невозможности различной трактовки сочетания отдельных фраз.
  5. Обязательность/нужность и актуальность -- если требование не является обязательным к реализации, оно должно быть просто исключено из набора требований. Если требование нужное, но "не очень важное", для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть требования, утратившие актуальность.
  6. Прослеживаемость/трассируемость -- убедиться, что Бизнес- и Пользовательские требования покрыты как минимум одним (не)функциональным в документе Системного уровня;
  7. Проранжированность (приоритизированность) по важности и срочности. Важность характеризует зависимость успеха проекта от успеха реализации требования. Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования.
  8. Проверяемость -- подразумевает возможность создания объективного тест-кейса, однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию.
  9. Если есть интеграция с другими Системами,
    то удостовериться, что схема и формат взаимодействия описание отправляемого/ожидаемого соответствует ожидаемому/отправляемому в документе сопряжённой системы;
Необходимо понимать, что все ошибки в требованиях всё равно не найти, и если удалось обнаружить хотя бы несколько, и их поправили, то это уже хорошо.
Результат
  • Более качественные требования
  • Зарегистрированные дефекты документации