Управление требованиями и тестирование ПО

Управление требованиями и тестирование ПО

Начальник отдела тестирования Якимович Алексей

Введение

Требования тесно связаны с тестированием. В широком смысле тестирование - это любое действие, направленное на выявление и предотвращение дефектов в системе, где дефект- это отклонение от требований.

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

Содержание

1. Введение в общий процесс разработки и анализа требований2. Практические аспекты разработки требований3. Процесс рецензирования требований

1. Введение в общий процесс разработки и анализа требований.

V-модель разработки и тестирования

Управление изменениями

При внесении изменения необходимо выполнить следующую работу:

1. Принять или отклонить изменение2. Согласовать изменение с заказчиком3. Организовать работы по переделке

Создание и анализ связей между требованиями (1)

В контексте бизнеса связи показываются как:

• Стратегии бизнеса

конкретизируются как

• Задачи бизнеса

которые воплощаются как

• Организация бизнеса и бизнес процессов

Создание и анализ связей между требованиями (2)

В контексте системного проектирования связи показываются как:

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

удовлетворяются

• Системные требования

которые разделяются на

• Подсистемы

которые реализуются как

• Компоненты

Выгоды использования связей

• Большая уверенность в достижении целей – Всегда можем показать, как мы их достигнем.

• Возможность оценить влияние изменений.

• Возможность оценить вклад подрядчиков.

• Возможность контролировать ход работ.

• Возможность оценить выгоду от реализации.

Создание и анализ связей между требованиями (3)

Стрелка указывает источник информации!

Создание и анализ связей между требованиями (4)

Методы анализа связей требований

Методы анализа

Описание Поддерживаемый процесс

Анализ влияния Что будет если изменить это требование?

Управление изменениями

Анализ последствий

Нам это действительно нужно?

Анализ экономической целесообразности

Анализ покрытия

Все ли учтено? Проектирование, отчетность по прогрессу

Создание и анализ связей между требованиями (6)

Создание и анализ связей между требованиями (6)

Требования в области проблем и в области решений(1)

Уровень

требований

Область Точка зрения

Цель

Пользовательские требования

Область проблем

Пользователь (представитель заинтересованной стороны)

Определяет - ЧТО пользователь желает достичь с помощью

создаваемой системы. Избегаем решений!

Системные требования

Область решения

Аналитик Абстрактно определяет – КАК система будет

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

требованиям.

Системные спецификации (архитектура

системы)

Область решения

Архитектор Определяет – КАК конкретная архитектура

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

требованиям.

Требования в области проблем и в области решений(2)

Отсутствие разделения между проблемами и решениями может привести к следующим негативным последствиям:

• Недостаточное понимание существующих проблем

• Невозможность определить границы (scope) системы, т.е. невозможно понять, какой функционал должен входить, а какой- нет

• Доминирование разработчиков в дискуссиях о системе, поскольку единственные известные требования формулируют в терминах реализации, а не в терминах проблем

• Невозможность нахождения наилучшего решения из-за ограничения свободы в выборе решения

Вывод: Нужно жестко отделять описания проблем от решений!

Стратегия проверки(1)

Связи типа «удовлетворяет/удовлетворяется» отражают процесс получения производных требований из входящих требований.

Стратегия проверки- это набор проверочных мероприятий, проверяющих удовлетворенность требованиий.

Каждая проверка подразумевает следующие аспекты:

• тип проверки

• фаза, когда проверка осуществляется

• тестовый стенд для проверки

• критерий успеха

Требования и тестирование

Стратегия проверки(2)

Простой метод анализа требований - CRUD

Для любого объекта должны быть известны ответы на следующие вопросы:

Create - Кто и как создает объект?

Read - Как и где можно прочитать информацию об объекте?

Update - Кто и как может изменить информацию об объекте?

Delete – Кто и как может удалить объект?

Нефункциональные требования – FURPS+

Functionality - Feature set, Capabilities, Generality, Security

Usability - Human factors, Aesthetics, Consistency, Documentation

Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure

Performance - Speed, Efficiency, Resource consumption, Throughput, Response time

Supportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Portability, Localizability+ Requirements for Design , Implementation, Interface, etc

“Плохой архитектор проектирует функциональные требования, а хороший- нефункциональные… “

Можно продолжить: “Плохой аналитик/тестировщик …..”))

2. Практические аспекты разработки требований

.

Требования к требованиям

Требования должны предоставлять следующие возможности:

• Однозначная идентификация

• Классификация - по важности, типу, срочности в реализации,….

• Статус с разных точек зрения – рецензирования, удовлетворения, проверки,..

• Анализировать каждое требование в контексте документа, т.е. в окружении других требований

• Нахождения требования по контексту, классификации и другим признакам

• Установления связей между требованиями

…

Приложения для разработки требований

Базы Данных Текстовый Документ

Преимущества :

Легко Нумеровать, Классифицировать, Трассировать, Сортировать, Отслеживать изменения…

Качество отдельного требования высокое!

Преимущества :

Видение всего документа в целом.

Качество документа в целом высокое!

Недостаток:

Теряется целостность видения документа.

Качество всего документа низкое!!

Недостаток:

Неудобно нумеровать, классифицировать, и т.д

Качество отдельного требования низкое!

Примеры: Enterprise Architect, Rational Requisite Pro 6.0,…

MS Word)

Оптимальные приложения для работы с требования должны совмещать преимущества баз данных и текстовых документов! Например: Rational Requisite Pro 8.0, Telelogic Doors…

Понятие «Ключевых требований»

Key User Requirement (KUR) или Key Performance Indicators (KPI)

Ключевое Требование подразумевает отрицательный ответ на вопрос:

На пользовательском уровне:

«Если решение не предполагает <эту> возможность (функцию, опцию, т.д.), стану ли я в этом случае ее приобретать?»

На системном уровне:

«Если система не обеспечивает <этого>, будет ли система все еще нужна мне?»

Ключевые требования позволяют держать в фокусе цели и задачи проекта.

Обсуждение/изменение ключевых требований должно происходить с большим вниманием и осторожностью.

Элементарные связи

UR1: Водитель должен иметь возможность проехать на автомобиле

по местности категории 4А

SR1: Автомобиль должен иметь полный привод

SR2: Автомобиль должен иметь дорожный клиренс не менее 25 см

SR3: Автомобиль должен иметь вес не более 1.5

Расширенные связи с аргументом удовлетворения

Расширенные связи

& - и (conjunction)– для реализации аргумента удовлетворения нужно выполнение всех требований

or - или (disjunction) – для реализации аргумента удовлетворения нужно выполнение любого из требований

= - требование может быть «спущено» без изменений на более низкие уровни

UR1: Водитель должен иметь возможность проехать на автомобиле

по местности категории 4АSR1: Автомобиль должен иметь

полный привод

SR2: Автомобиль должен иметь дорожный клиренс не менее 25 см

SR3: Автомобиль должен иметь вес не более 1.5

Местность категории 4А предполагает наличие жидкой грязи, что потребует наличие

ограничений по весу, клиренсу, и мощности двигателя

&

DK 5: Почва местности категории 4А может выдержать автомобиль с осевой

нагрузкой 0,5т

Классификация Требований

Первичная классификация – место в контексте документа.

Множественная вторичная классификация по следующим группам: Идентификация, Характеристики, Приоритет/Важность, Источник и владелец, Контекст, Процессы и Статусы, …

Введение классификации с начала работы с требованиями не требует больших трудозатрат.

Классификация упрощает анализ требований на непротиворечивость, полноту, связанность и согласованность.

Baselines

Baseline – это фиксирование состояния требований в какой-либо момент времени, например, когда заказчик отрецензировал требования, перед началом фазы разработки, т.п.

Baselines можно сравнить между собой – чтобы понять, как изменились требования.

Рецензирование требований

На что обращать внимание:

1. Хаос – требование должно быть сконцентрировано на самом важном

2. «Лазейки» - например фраза «если это необходимо»

3. Более одного требования в одном параграфе (союз И знак!)

4. Рассуждения

5. Размытые понятия и слова – напр.- часто, нормально, типично, т.п.

6. Неопределенные термины – удобный, универсальный, гибкий

7. Желаемое выдано за требуемое – напр. 100% надежный, приятный для пользователей, безопасный, обрабатывать неожиданные сбои, не должен никогда ломаться, и тп

3. Процесс рецензирования требований

.

Процесс рецензирования

Moderator

Author

Inspector

Reader

Verifier

Peer Review Coordinator

Создает Документ

Планирует Рецензиро

вание

Оценка готовности

Готов?НЕТ

СозданиеДокумента

Подготовка к рецензировани

ю

Рецензирует документ

ДА

Проводится встреча где принимаютс

я или не принимаются замечания к документу

Рецензирование

Исправление документа

Проверяетсявнесение изменений

Сбор статистики

Вносится данные в систему качества

Document to review

Plan of review

Inspector Checklist

Inspection Summary

Report

Встреча

Исправляется документ

Final Document

1. Не допускается рецензирование черновиков документов.

2. Обсуждение замечаний на общем собрании – не более 2х минут.

3. Инспектор следит за готовностью документа к рецензированию.

4. В рецензировании может участвовать заказчик + вся команда исполнителей! + приглашенные эксперты.

5. Обязательная проверка внесения изменений.

6. Не нужно изобретать велосипед. Процедура хорошо прописана и известна -www.processimpact.com/reviews_book/.

7. Можно использовать ПО для организации процесса рецензирования, но лучше иметь еще и личные встречи.

Рецензирование документации

Вопросы

?

Контактная информация

AliakseiYakimovich@iba.by