# Процессы Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Архитектура Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD Анализ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux Тестирование Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Нагрузочное Данные Ресурсы MDM Big data Об информации SQL intro MongoDB intro Библиотека Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps Gaming Библиотека ПРОЦЕССЫ ТЕСТИРОВАНИЕ: + ТЕСТИРОВАНИЕ - Тестирование требований | Черпнуть мудрости | Зачем | Кто | Когда | Что делать | Результат + Тест-анализ и тест дизайн + Импакт-анализ в тестировании + API, интеграционное и E2E + Тест план + Метрики качества + Android + Автоматизация + Selenium WebDriver + XPATH + Различные расчёты + Безопасность + Нагрузочное
Тестирование требований
latest update of the page: 27-01-2024, 09:53 UTC
Черпнуть мудрости
Зачем
Тестирование Бизнес-, Пользовательских и Системных требований направлено на то, чтобы уже на начальных этапах проектирования Продукта/Системы устранить максимально возможное количество ошибок.
Это позволяет:
  • снизить итоговую стоимость Проекта/доработки;
  • повысить скорость в цепи поставки / сэкономить время в Проекте;
  • улучшить качество Продукта/Системы;
  • сохранить нервы всей команде.
Кто
  • тест-аналитики
  • тестировщики
В любом случае, это должны быть НЕ авторы требований.
Качество проверки документации зависит от квалификации сотрудника, который её проводит. Для этой задачи стоит выделить опытного специалиста.
Когда
До старта разработки. Для этого нужно рассчитать необходимое время на проверку и заморозить тестируемую документацию до окончания проверки.
В том случае, когда проверка требований ведется параллельно с разработкой, крайне важно оперативно предупредить Разработчиков и Аналитиков о найденных дефектах, чтобы они могли вовремя исправить ошибку в документации и в коде.
Что делать
В документе, содержащем Требования, нужно проверить:
  1. Что нет опасных и подозрительных путаных опечаток:
    Разработчики/Аналитики иногда дают похожие названия компонентам, методам, сущностям, полям. И в документации начинает возникать путаница: написали одно, а имели в виду другое;
  2. Завершённость и полноту требований. Каждое требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям "это и так всем понятно".
    1. поискать неучтённые случаи, используя карту состояний или диаграмму переходов;
    2. нет видимых логических нестыковок в схемах и диаграммах, описывающих те самые состояния и переходы.
  3. Непротиворечивость и последовательность — каждое требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам. Логика новых/изменённых функций составлена с учётом ранее реализованных и логически связанных с изменениями функций и не портит их.
  4. Недвусмысленность — требование должно быть описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок, должно допускать только однозначное объективное понимание и быть атомарным в плане невозможности различной трактовки сочетания отдельных фраз.
  5. Обязательность/нужность и актуальность — если требование не является обязательным к реализации, оно должно быть просто исключено из набора требований. Если требование нужное, но "не очень важное", для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть требования, утратившие актуальность.
  6. Прослеживаемость/трассируемость — убедиться, что Бизнес- и Пользовательские требования покрыты как минимум одним (не)функциональным в документе Системного уровня;
  7. Проранжированность (приоритизированность) по важности и срочности. Важность характеризует зависимость успеха проекта от успеха реализации требования. Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования.
  8. Проверяемость — подразумевает возможность создания объективного тест-кейса, однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию.
  9. Если есть интеграция с другими Системами,
    то удостовериться, что схема и формат взаимодействия описание отправляемого/ожидаемого соответствует ожидаемому/отправляемому в документе сопряжённой системы;
Необходимо понимать, что все ошибки в требованиях всё равно не найти, и если удалось обнаружить хотя бы несколько, и их поправили, то это уже хорошо.
Результат
  • Более качественные требования
  • Зарегистрированные дефекты документации