Управление требованиями и тестирование ПО Начальник отдела тестирования Якимович Алексей презентация

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

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

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

изменение
Согласовать изменение с заказчиком
Организовать работы по переделке

как:
Стратегии бизнеса
конкретизируются как
Задачи бизнеса
которые воплощаются как
Организация бизнеса и бизнес процессов

показываются как:
Пользовательские требования (stakeholder requirements)
удовлетворяются
Системные требования
которые разделяются на
Подсистемы
которые реализуются как
Компоненты

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

и решениями может привести к следующим негативным последствиям:
Недостаточное понимание существующих проблем
Невозможность определить границы (scope) системы, т.е. невозможно понять, какой функционал должен входить, а какой- нет
Доминирование разработчиков в дискуссиях о системе, поскольку единственные известные требования формулируют в терминах реализации, а не в терминах проблем
Невозможность нахождения наилучшего решения из-за ограничения свободы в выборе решения
Вывод: Нужно жестко отделять описания проблем от решений!

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

ответы на следующие вопросы:
Create - Кто и как создает объект?
Read - Как и где можно прочитать информацию об объекте?
Update - Кто и как может изменить информацию об объекте?
Delete – Кто и как может удалить объект?

- 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
“Плохой архитектор проектирует функциональные требования, а хороший- нефункциональные… “
Можно продолжить: “Плохой аналитик/тестировщик …..”))

по важности, типу, срочности в реализации,….
Статус с разных точек зрения – рецензирования, удовлетворения, проверки,..
Анализировать каждое требование в контексте документа, т.е. в окружении других требований
Нахождения требования по контексту, классификации и другим признакам
Установления связей между требованиями
…

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

Ключевое Требование подразумевает отрицательный ответ на вопрос:
На пользовательском уровне:
«Если решение не предполагает <эту> возможность (функцию, опцию, т.д.), стану ли я в этом случае ее приобретать?»
На системном уровне:
«Если система не обеспечивает <этого>, будет ли система все еще нужна мне?»
Ключевые требования позволяют держать в фокусе цели и задачи проекта.
Обсуждение/изменение ключевых требований должно происходить с большим вниманием и осторожностью.

реализации аргумента удовлетворения нужно выполнение всех требований
or - или (disjunction) – для реализации аргумента удовлетворения нужно выполнение любого из требований
= - требование может быть «спущено» без изменений на более низкие уровни

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

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

когда заказчик отрецензировал требования, перед началом фазы разработки, т.п.

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

на самом важном
«Лазейки» - например фраза «если это необходимо»
Более одного требования в одном параграфе (союз И знак!)
Рассуждения
Размытые понятия и слова – напр.- часто, нормально, типично, т.п.
Неопределенные термины – удобный, универсальный, гибкий
Желаемое выдано за требуемое – напр. 100% надежный, приятный для пользователей, безопасный, обрабатывать неожиданные сбои, не должен никогда ломаться, и тп

более 2х минут.
Инспектор следит за готовностью документа к рецензированию.
В рецензировании может участвовать заказчик + вся команда исполнителей! + приглашенные эксперты.
Обязательная проверка внесения изменений.
Не нужно изобретать велосипед. Процедура хорошо прописана и известна -www.processimpact.com/reviews_book/.
Можно использовать ПО для организации процесса рецензирования, но лучше иметь еще и личные встречи.

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