ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПО

ТЕСТИРОВАНИЕ ТРЕБОВАНИЙ

ЗАЧЕМ ТЕСТИРОВАТЬ ТРЕБОВАНИЯ?

ЗАЧЕМ ТЕСТИРОВАТЬ ТРЕБОВАНИЯ?

ЗАЧЕМ ТЕСТИРОВАТЬ ТРЕБОВАНИЯ?

Именно в требованиях закрадывается больше всего багов,

а не в коде, как думают многие:

ПРОБЛЕМЫ АНАЛИЗА ТРЕБОВАНИЙ

Проблемы заинтересованных лиц

• Заказчики не понимают то, что они хотят, или у пользователей нет

ясного представления об их требованиях

• Заказчики не соглашаются с ранее записанными требованиями

• Заказчики настаивают на новых требованиях после того, как

стоимость и график работ были установлены

• Коммуникация с заказчиками является медленной

• Заказчики часто не участвуют в обзорах требований или

неспособны в них участвовать

• Заказчики технически неподготовлены

• Заказчики не понимают процесса разработки ПО

ПРОБЛЕМЫ АНАЛИЗА ТРЕБОВАНИЙ

Проблемы инженеров / разработчиков

• У технического персонала и конечных пользователей могут быть

различные мнения.

• Инженеры и разработчики могут попытаться подкорректировать

требования, чтобы они соответствовали существующей системе

или модели, вместо того, чтобы разработать систему,

соответствующую потребностям клиента.

• Анализ может часто выполняться инженерами или

программистами, а не персоналом с навыками работы с

людьми и знаниями проблемной области.

Проблема самих требований (их просто нет)

СТАНДАРТНАЯ СИТУАЦИЯ ИЗ ЖИЗНИ:

ТИПЫ ТРЕБОВАНИЙ

oФункциональные

что система должна делать?

oНефункциональные

при каких условиях система должна

работать?

ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

• Бизнес-требования (business requirements) – определяют

высокоуровневые цели организации или клиента

(потребителя) – заказчика разрабатываемого программного

обеспечения.

• Пользовательские требования (user requirements) –

описывают цели/задачи пользователей системы, которые

должны достигаться/выполняться пользователями при помощи

создаваемой программной системы.

• Функциональные требования (functional requirements) –

определяют функциональность (поведение) программной

системы, которая должна быть создана разработчиками для

предоставления возможности выполнения пользователями

своих обязанностей в рамках бизнес-требований и в

контексте пользовательских требований.

НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)

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

• Ограничения на программные интерфейсы, в том числе к внешним системам

• Требования к атрибутам качества• Требования к применяемому оборудованию и ПО Требования к документированию Требования к дизайну и юзабилити Требования к безопасности и надёжности Требования к показателям назначения (производительность,

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

мобильность, автономность и т.п.)

ТЕСТИРОВАНИЕ ДОКУМЕНТАЦИИ ОХВАТЫВАЕТ СЛЕДУЮЩИЕ ВИДЫ ДОКУМЕНТОВ:

• Функциональные спецификации;

• Спецификации по графическому

интерфейсу пользователя;

• Руководства пользователя и онлайновые

справочные системы.

ИСТОЧНИКИ ТРЕБОВАНИЙ

• Законодательство (конституция, законы,

распоряжения)

• Нормативное обеспечение организации

(регламенты, положения, уставы, приказы)

• Текущая организация деятельности объекта

• Модели деятельности (диаграммы бизнес-

процессов)

• Представления и ожидания потребителей и

пользователей системы

• Конкурирующие программные продукты

ТРЕБОВАНИЯ К ТРЕБОВАНИЯМ

Единичность Требование описывает одну и только одну вещь.

Завершённость

(полнота)Требование полностью определено в одном месте и вся необходимая информация присутствует.

Избыточность Отсутствуют избыточные данные.

ПоследовательностьТребование не противоречит другим требованиям и полностью соответствует внешней документации.

АтомарностьТребование «атомарно». То есть оно не может быть разбито на ряд более детальных требований без потери завершённости.

Актуальность Требование не стало устаревшим с течением времени.

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

НедвусмысленностьТребование кратко и определено выражает факты. Возможна одна и только одна интерпретация. Определение не содержит нечётких фраз.

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

ПроверяемостьРеализованность требования может быть определена через один из методов: осмотр, демонстрация, тест или анализ.

Логичность Логическая взаимосвязь компонентов

КАК ТЕСТИРОВАТЬ ТРЕБОВАНИЯ?

иметь хорошие доменные знания в области

форматировать требования в виде таблиц со

всеми возможными вариантами

обращать внимание на общие формулировки

представить себя на месте

заказчика/аналитика/простого пользователя и

пытаться предположить, будет ли понятно то или

иное требование

руководствоваться здравым смыслом и собственным опытом

КТО ТЕСТИРУЕТ ТРЕБОВАНИЯ?

• Тестировщик (QC, QA)

• Аналитик

• Разработчик (Архитектор, Тех лидер)

• ПМ

• Эксперт в области

• И, вы не поверите, Пользователи и Заказчик

• Иногда все они даже собираются группами!

ЧТО НА ВЫХОДЕ? (РЕЗУЛЬТАТ)

• Требования с указанием недочетов и

рекомендаций по исправлению (логично, да?)

• Список дефектов в баг-трекинг системе (если

по процессу)

• Минимизация будущих расходов на

переработку

• Happy Customers! (а также менеджеры,

аналитики, разработчики и, конечно,

тестировщики)