- •Структура курса «Управление качеством»
- •Место курса «Управление качеством» в подготовке IT- специалистов
- •Ошибка в контролирующем программном обеспечении, написанном на языке программирования Ada, вызвало самоликвидацию ракеты
- •Сетецентрическое управление системами
- •MANET, VANET and FANET.
- •High-Level JAUS system architecture ( Joint Architecture for Unmanned Systems )
- •A FANET scenario to extend the scalability of multi-UAV systems
- •A FANET application scenario for reliable multi-UAV communication network.
- •Architecture of MBSS containing mesh STAs, APs and portals as designed in IEEE
- •Использования беспроводных технологий четвертого поколения
- •Коммуникационная инфраструктура GIG
- •Схема информационных взаимодействий в сети DTN
- •Обобщённая модель сетецентрического подхода в военном деле
- •Эффект GIG
- •Интероперабельность информационных систем различного назначения
- •Обеспечение интероперабельности – основная тенденция в развитии открытых систем
- •Интероперабельность информационных систем различного масштаба
- •Р.П. Быстров, В.Н. Корниенко, А.Я. Олейников Интероперабельность, информационное противоборство и радиоэлектронная борьба//“Успехи современной
- •Соотношение основных понятий, связанных с проблемой итероперабельности
- •Industry 4.0 | Что это?
- •Слияние виртуального и реального миров с образованием гибридного мира мираобразованием
- •Industry 4.0 | Где человек?
- •Industry 4.0 | Ключевые компоненты*
- •Новая реальность: сетецентрические системы
- •Цифровая экосреда «умного
- •Определение SoS
- •Свойства SoS
- •Парадокc SoS
- •Концептуальная основа графодинамических систем
- •Вопрос
- •Статистические данные о текущей эффективности реализации программных проектов
- •About The Standish Group
- •The Standish Group is a primary research advisory organization that focuses on software
- •The Standish Group was formed in 1985 with a vision of innovating group
- •Эффективность реализации программных проектов по данным 2010 г.
- •Динамика эффективности реализации программных проектов
- •Последствия недостаточного качества реализации программных проектов
- •Реальная востребованность возможностей программного продукта
- •Статистические данные о эффективности реализации программных проектов
- •Статистические данные о эффективности реализации программных проектов
- •Основной вывод отчетаThe Standish Group
- •Факторы, приводящие к провалу проекта
- •Факторы успеха проекта и их значимость
- •Вывод:
- •Общие положения Total Quality Management (TQM)
- •Эволюция подходов к управлению качеством
- •Что такое качество ?
- •Project Triangle
- •Project Triangle
- •Пещера Платона
- •Компоненты TQM
- •Содержание TQM
- •Содержание «Цикла Деминга»
- •Цикл Деминга
- •Базовые положения TQM
- •Базовые положения TQM
- •Базовые положения TQM
- •Роль дисциплины при проектировании сложных программных систем
- •Содержание MDA
- •Место спецификации требований в жизненном цикле программной системы
- •Куликов С.С. Тестирование программного обеспечения. Базовый курс.- Минск, Четыре четверти, 2017.-312 с.
- •Краткий очерк истории тестирования
- •Краткий очерк истории тестирования (продолжение)
- •Реализация классических подходов
- •Виды тестирования
- •Философия «белого» и «черного» ящиков
- •Стратегии тестирования интеграции
- •Краткий очерк истории тестирования (продолжение)
- •Краткий очерк истории тестирования (продолжение)
- •Петля обратной связи как инструмент контроля реализации проекта
- •Содержание регрессионного тестирования
- •Сценарное тестирование
- •Краткий очерк истории тестирования (продолжение)
- •Новые подходы к тестированию программных средств
- •Понятия альфа- тестирования
- •Понятие бета-тестирования
- •Сценарное тестирование
- •Ad hoc тестирование
- •Содержание Ad hoc тестирования
- •Виды свободного тестирования (ad-hoc testing)
- •Основные преимущества ad-hoc testing
- •Исследовательское тестирование
- •Понятие исследовательского тестирования
- •Когда следует применять исследовательское тестирование?
- •Предпосылки к использованию исследовательского тестирования в чистом виде
- •Использование исследовательского тестирование в дополнение к сценарному тестированию
- •Использование исследовательского тестирование в дополнение к сценарному тестированию (продолжение)
- •Когда одним исследовательским тестированием не обойтись
- •Когда одним исследовательским тестированием не обойтись
- •Системное сочетание исследовательского и сценарного тестирования
- •Краткий очерк истории тестирования (продолжение)
- •Краткий очерк истории тестирования (продолжение)
- •Менеджмент на основе качества
- •Принципы менеджмента на основе качества
- •Принципы менеджмента на основе качества (продолжение)
- •Точки зрения на проект в рамках методологии MSF
- •PMBOK
- •Анализ коренных причин (Root Cause Analysis)
- •Принципы SMART
- •Краткое описание содержания задач RCA
- •Краткое описание содержания задач RCA (продолжение)
- •Краткое описание содержания задач RCA (продолжение)
- •Краткое описание содержания задач RCA (продолжение)
- •Краткое описание содержания задач RCA (продолжение)
- •Базовые положения RCA
- •Базовые положения RCA
- •Инструментарий и технологии RCA.
- •«Пять Почему?»
- •Парето – анализ
- •Диаграмма причинно – следственных связей
- •Контрольные диаграммы (отдельный процесс)
- •Контрольные диаграммы (совокупность процессов)
- •Краткие рекомендации по применению RCA
- •Краткие рекомендации по применению RCA
- •Возможные причины неудачного применения RCA
- •Возможные причины неудачного применения RCA (продолжение)
- •Ситуации повторяются
- •Системы, состоящие из частей абсолютно разной природы, имеющих совершенно несхожие функции, подчиняются одним
- •Гоме́р — древнегреческий поэт-сказитель, создатель эпических поэм «Илиада» и «Одиссея». Предположительно, был рапсодом*.
- •Определение
- •Базовые конструкции системных архетипов
- •Направления применения архетипов
- •Архетип 1. Уравновешивание с задержкой
- •Архетип 2. Пределы роста:
- •Пределы роста (пределы улучшений)
- •Противодействие приходит либо из неподконтрольных подразделений, либо из внешней среды
- •Шаги по урегулированию ситуации
- •Подмена проблем (Shifting the Burden)
- •Содержание системного архетипа
- •Шаги по урегулированию ситуации
- •Эрозия целей
- •Эрозия целей (1)
- •Шаги по урегулированию ситуации
- •Нормативное обеспечение управления проектами, портфелями, программами
- •Роли проекта
- •Назначение проекта как модели создаваемого объекта
- •Принципы проектирования
- •Принципы проектирования (продолжение)
- •Принципы проектирования (продолжение)
- •Принципы проектирования (продолжение)
- •Роль стандартизации жизненного цикла в управлении качеством СОД и У
- •Наиболее значимые стандарты
- •Базовые этапы (процессы) ЖЦ СОД и У
- •Направления стандартизации ЖЦ СОД и У
- •Направления стандартизации ЖЦ СОД и У (продолжение)
- •Направления стандартизации ЖЦ СОД и У (продолжение)
- •Структура стандартов ESA PSS-05-XX
- •МОДЕЛЬ СММ
- •Пять уровней зрелости СММ
- •Начальный уровень
- •повторяемый уровень
- •Определенный уровень
- •Управляемый уровень
- •Оптимизирующий уровень
- •ПЛАНИРОВАНИЕ ПРОЕКТА
- •Различие между SQA и SVV
- •Петля обратной связи как инструмент контроля реализации проекта
- •Роль модели ЖЦ программного продукта в управлении его качеством
- •См. курс «Моделирование» - «внешняя и внутренняя среды программного проекта»
- •Концептуальная основа гарантированного управления качеством
- •Планирование проекта
- •Компоненты плана проекта
- •Показатели реалистичности плана проекта (дефекты планирования)
- •Объекты контроля на стадии валидации и верификации программного продукта
- •Системные Архетипы
- •Ситуации повторяются
- •Системы, состоящие из частей абсолютно разной природы, имеющих совершенно несхожие функции, подчиняются одним
- •Определение
- •Базовые конструкции системных архетипов
- •Архетип 1. Уравновешивание с задержкой
- •Архетип «Уравновешивание с задержкой»
- •Пример реализации архетипа «Уравновешивание с задержкой»
- •Архетип 2. Пределы роста:
- •Пределы роста (пределы улучшений)
- •Архетип «Пределы Роста»
- •Пример учета стоимости устранения дефектов
- •Пример архетипа «Пределы роста»
- •Архетип 3. Подмена проблемы
- •Эрозия целей
- •Несбалансированность параметров проекта по показателю количества дефектов
- •Несбалансированность проекта по показателю бюджета
- •КОНЕЦ ЛЕКЦИЙ
Когда следует применять исследовательское тестирование?
•Когда нужно обеспечить быструю обратную связь для нового продукта или новой функциональности продукта.
•Когда нужно быстро ознакомиться с продуктом.
•Когда уже были проведены основные виды тестирования и время позволяет разнообразить методы тестирования.
•Когда нужно найти дефект, локализованный в определенном модуле в кратчайшие сроки.
•Когда проверяется работа другого специалиста по тестированию.
•Когда нужно изучить состояние конкретного риска для принятия решения о необходимости покрытия конкретной области тестами.
101
Предпосылки к использованию исследовательского тестирования в чистом виде
•Мало времени : если тестовая документация написана, но времени на прохождение тестов уже нет, нужно выбирать наиболее критичные области приложения, которые реально протестировать за имеющееся время. Составить чек-лист с идеями и тестировать вокруг них.
•Сложности с требованиями: требований нет, они не полны или устарели и нет возможности их актуализировать.
•Небольшой проект: продукт маленький, и разработка тестовых сценариев займет больше времени, чем сам процесс тестирования.
102
Использование исследовательского тестирование в дополнение к сценарному тестированию
•Тестировщики постоянно проходят одни и те же тестовые сценарии
•При многократном прохождении одних и тех же тестов, например, при регрессионном тестировании. Тестировщики теряют концентрацию и начинают пропускать дефекты. В этом случае исследовательское тестирование помогает взглянуть на проект под новым углом и найти пропущенные дефекты.
•Тестировщик отвлекается от шаблонных действий и чувствует себя в большей степени обычным пользователем. Это помогает найти дефекты, сильнее влияющие на конечного потребителя разрабатываемого продукта.
103
Использование исследовательского тестирование в дополнение к сценарному тестированию (продолжение)
•Пришел внезапный запрос на изменения Времени на разработку новых сценариев нет, так как все заняты другими запланированными задачами или
изменения потребуют переработать большую часть документации. В этой ситуации тестирование исследовательским методом может быть наиболее оптимальным.
•Когда хочется перестраховаться Продукт уже протестирован по сценариям, но всё еще
хочется убедиться в том, что ничего не было упущено.
104
Когда одним исследовательским тестированием не обойтись
•Приложение стандартизованное: Приложения, работающие по стандартам и гостам, а также системы, для которых малейшее отклонение может быть критичным. Это могут быть приложения, отвечающие за полеты ракет или проводящие финансовые операции.
•Проводится интеграционное тестирование. В этом случае исследовательское тестирование возможно, например, при тестировании API. Но обычно интеграционное тестирование проводится для проверки взаимодействия внутренних компонентов приложений. Эта работа хорошо покрыта документацией и часто автоматизируется
105
Когда одним исследовательским тестированием не обойтись
(продолжение)
•Тестовые сценарии отдаются на в стороннюю организацию.
Контролировать поставленную задачу и процент ее выполнения проще по формализованным сценариям.
•Длительный проект. Тестировщики могут быть подключены к проекту на время определенной фазы, а после, пока разработчики реализовывают новый
функционал, заниматься другими проектами. Если долго не тестировать конкретную функциональность, то ее специфика забывается
106
Системное сочетание исследовательского и сценарного тестирования
Исследовательское тестирование — не означает полное отсутствие документации и хаос, а является мощным инструментом.
Используя ранжирование типов тестирования от полностью исследовательского до полностью сценарного, можно подобрать оптимальный уровень документации для вашего проекта и сэкономить время.
Сценарное и исследовательское тестирование являются полностью совместимыми и компенсируют недостатки друг друга. Можно покрыть детальными тестами сложные технические аспекты проекта и написать поверхностные чек- листы для пользовательского интерфейса.
107
Краткий очерк истории тестирования (продолжение)
2000-е годы
1.Поиск новых подходов к обеспечению качества
2.Автоматизация тестирования
3.Во главу процесса тестирования ставятся не соответствие программы требованиям, а её способность предоставить конечному пользователю возможность эффективно решать свои задачи
Краткий очерк истории тестирования (продолжение)
Текущее состояние
1.Гибкие методологии и гибкое тестирование
2.Глубокая интеграция процессов испытаний с процессами разработки и автоматизации
3.Огромный набор методологий и инструментальных средств
4.Кросс функциональные команды (программист и тестировщик могут выполнять работу друг друга)
Менеджмент на основе качества
110
