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