Обеспечение качества и тестирование программного обеспечения

Содержание

Слайд 2

Слияние виртуального и реального миров с образованием гибридного мира мираобразованием

Слияние виртуального и реального миров с образованием гибридного мира мираобразованием

Слайд 3

Industry 4.0 | Что это? Концепция четвертой промышленной революции («Индустрии 4.0»)

Industry 4.0 | Что это?

Концепция четвертой промышленной революции («Индустрии 4.0») была

сформулирована в 2011 году во время Ганноверской ярмарки группой представителей немецкой промышленности и бизнесс-сообщества в рамках инициативы по повышению конкурентоспособности Германии

ПУМСС-2018, 03-06 сентября 2018, г. Самара

Слайд 4

Industry 4.0 | Где человек? ПУМСС-2018, 03-06 сентября 2018, г. Самара

Industry 4.0 | Где человек?

ПУМСС-2018, 03-06 сентября 2018, г. Самара

Слайд 5

Industry 4.0 | Ключевые компоненты* Cyber-Physical Systems (CPS) Internet of Things

Industry 4.0 | Ключевые компоненты*

Cyber-Physical Systems (CPS)
Internet of Things (IoT)
Internet of

Services
Smart Factory

*[Hermann M., Pentek T., Otto B. Design Principles for Industrie 4.0 Scenarios: A Literature Review. Working Paper No. 01. 2015. http://www.snom.mb.tu-dortmund.de/cms/de/forschung/Arbeitsberichte/Design-Principles-for-Industrie-4_0-Scenarios.pdf]

ПУМСС-2018, 03-06 сентября 2018, г. Самара

Слайд 6

ВОПРОС 1: РОЛЬ ЗАДАЧ УПРАВЛЕНИЯ ФУНКЦИОНАЛЬНОЙ БЕЗОПАСНОСТЬЮ В ОБЕСПЕЧЕНИИ ЭФФЕКТИВНОГО ФУНКЦИОНИРОВАНИЯ АПК

ВОПРОС 1:
РОЛЬ ЗАДАЧ УПРАВЛЕНИЯ ФУНКЦИОНАЛЬНОЙ БЕЗОПАСНОСТЬЮ В ОБЕСПЕЧЕНИИ ЭФФЕКТИВНОГО ФУНКЦИОНИРОВАНИЯ АПК

Слайд 7

1 Ошибка в космическом агентстве В июне 1996 года специалисты Европейского

1 Ошибка в космическом агентстве
В июне 1996 года специалисты Европейского космического

агентства осуществляли запуск ракеты Ariane 5.
Слайд 8

Ошибка в контролирующем программном обеспечении, написанном на языке программирования Ada, вызвало

Ошибка в контролирующем программном обеспечении, написанном на языке программирования Ada, вызвало

самоликвидацию ракеты через 37 секунд после взлета
Слайд 9

Сбой в медицинском оборудовании Сбои случались и в медицинском оборудовании. В

Сбой в медицинском оборудовании
Сбои случались и в медицинском оборудовании. В

1980-годы несколько пациентов погибли после получения слишком большой дозы облучения рентгеновским аппаратом Therac-25 (лучевая терапия).
Слайд 10

Слайд 11

Света не было не только в домах граждан, но и в

Света не было не только в домах граждан, но и

в больницах, школах, на вокзалах. Не работали компьютеры в полицейских участках, не функционировали радары сил противовоздушной обороны, самолёты не могли подняться со взлётных полос. Хуже того: умолкли диспетчерские вышки, и несколько страшных часов самолёты, находящиеся в воздухе, не могли сесть. Глобальный каскадный сбой, вызванный неприметной ошибкой, послужил причиной одного из самых масштабных отключений электроэнергии в истории
Слайд 12

Авария в Мексиканском заливе: возможна ли программная ошибка?

Авария в Мексиканском заливе:
возможна ли программная ошибка?

Слайд 13

В статье, появившейся в Houston Chronicle от 19 июля 2010 года,

В статье, появившейся в Houston Chronicle от 19 июля 2010

года, утверждается, что "экраны дисплеев на основной рабочей станции (ее называли A-chair), использовавшейся для управления буровой установкой на Deepwater Horizon, перед инцидентом несколько раз 'зависали'". Стефен Бертон, главный инженер компании Transocean по платформе Deepwater Horizon, заявил: "По существу, экраны могли перестать обновляться, и все данные... оказались бы заблокированы".
Слайд 14

Вопрос 2: Место системы информационной поддержки управления в обеспечении функционирования сложных систем

Вопрос 2:
Место системы информационной поддержки управления в обеспечении функционирования сложных систем

Слайд 15

Объект управления Управляющая система Окружающая объект управления среда Данные и информация,

Объект управления

Управляющая система

Окружающая объект управления среда

Данные и информация, характеризующие состояние объекта

управления

Информационные продукты/услуги

Информационные потребности

Управляющие воздействия

Запросы на исходные данные, информацию

Информационные продукты и услуги, получаемые помимо автоматизированной системы

Автоматизированная информационная система

Программная система

Аппаратная составляющая

Персонал

Место информационной системы в управлении бизнес-процессами

Слайд 16

Вывод: Необходимо рассматривать как единое целое Hard+soft+brain

Вывод:
Необходимо рассматривать как единое целое Hard+soft+brain

Слайд 17

Место программной компоненты в управлении сложными техническими системами ПО Компонент системы

Место программной компоненты в управлении сложными техническими системами

ПО

Компонент
системы

Компонент
системы

Компонент
системы

Компонент
системы

Компонент
системы

Компонент
системы

Компонент
системы

Компонент
системы

Слайд 18

Основные подходы к обеспечению безопасности программных систем

Основные подходы к обеспечению безопасности программных систем

Слайд 19

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

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

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

Вопрос 3: В чем причина кризиса в IT?


Вопрос 3:
В чем причина кризиса в IT?

Слайд 21

Статистические данные о текущей эффективности реализации программных проектов (по данным, относящимся

Статистические данные о текущей эффективности реализации программных проектов (по данным, относящимся к

США)

Источники данных
The Standish Group Report CHAOS. Project Smart- 2014, 16p.
CHAOS MANIFESTO The Laws of CHAOS and the
CHAOS 100 Best PM Practices – 2011, 51p.

Слайд 22

Слайд 23

About The Standish Group


About The Standish Group

Слайд 24

The Standish Group is a primary research advisory organization that focuses

The Standish Group is a primary research advisory organization that focuses

on software project performance. Using our extensive primary research you can improve your investments in software projects.  We are a group of highly dedicated professionals with years of practical experience helping organizations improve.
Слайд 25

The Standish Group was formed in 1985 with a vision of

The Standish Group was formed in 1985 with a vision of

innovating group refection using case-based reasoning techniques. We do this in order to profile your projects and environments against thousands of cases to deliver more precise advice based on collective wisdom. For over 30 years The Standish Group has been researching and providing advice on how to increase the value of software investments
Слайд 26

Эффективность реализации программных проектов по данным 2010 г.

Эффективность реализации программных проектов по данным 2010 г.

Слайд 27

Динамика эффективности реализации программных проектов

Динамика эффективности реализации программных проектов

Слайд 28

Последствия недостаточного качества реализации программных проектов

Последствия недостаточного качества реализации программных проектов

Слайд 29

Реальная востребованность возможностей программного продукта Источник:The Standish Group Report CHAOS. Project Smart, 2014

Реальная востребованность возможностей программного продукта


Источник:The Standish Group Report CHAOS. Project Smart,

2014
Слайд 30

Статистические данные о эффективности реализации программных проектов (по данным, относящимся к

Статистические данные о эффективности реализации программных проектов (по данным, относящимся к США)

Ежегодные

затраты на реализацию IT-приложений: 250 млрд. $
Количество реализуемых проектов: 175 000
Диапазон стоимости проектов: 34000$- 2 322 000$
Слайд 31

Статистические данные о эффективности реализации программных проектов (по данным, относящимся к

Статистические данные о эффективности реализации программных проектов (по данным, относящимся к США,

продолжение)

4. Среднее превышение плановой стоимости -189%
5. Среднее превышение плановых сроков реализации – 222%
6. Реализуется лишь 61% функциональных и нефункциональных требований, заявленных в техническом задании
7.Общие потери, учитывающие упущенные возможности – триллион долларов

Слайд 32

Основной вывод отчетаThe Standish Group Report CHAOS. Project Smart, 2014 В

Основной вывод отчетаThe Standish Group Report CHAOS. Project Smart, 2014
В

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

Факторы, приводящие к провалу проекта

Факторы, приводящие к провалу проекта

Слайд 34

Факторы успеха проекта и их значимость

Факторы успеха проекта и их значимость

Слайд 35

Вывод: ...В следующий раз, услышав о провале проекта по внедрению корпоративной

Вывод:
...В следующий раз, услышав о провале проекта по внедрению

корпоративной информационной системы, подумайте прежде всего о плохой работе менеджмента, а потом уже об отказе программного обеспечения. Плохое программное обеспечение не убивает компании, это делает плохой менеджмент...
Источник:www.rbcgrp.com/erp-bi.html
Слайд 36

Конус неопределенности программного продукта 4х 2х х 0,5х 0,25х Точность оценки

Конус неопределенности программного продукта



х

0,5х

0,25х

Точность оценки стоимости и времени

Анализ требований
пользовате-лей

Проектирование системы

Реализация

Интеграция и

внедрение

Функционирование и сопровождение

Слайд 37

Роль дисциплины при проектировании сложных программных систем

Роль дисциплины при проектировании сложных программных систем

Слайд 38

Возможности модели жизненного цикла программной системы (потенциальность модели) должна соответствовать сложности

Возможности модели жизненного цикла программной системы (потенциальность модели) должна соответствовать

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

Некоторые модели жизненного цикла


Некоторые модели жизненного цикла

Слайд 40

Слайд 41

Слайд 42

Содержание MDA

Содержание MDA

Слайд 43

Code-and-fix model Реализация программного продукта сводится к непосредственному кодированию задачи в

Code-and-fix model

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

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

Stagewise model Разработка программного продукта сводится к следующей последовательности действий: Планирование

Stagewise model

Разработка программного продукта сводится к следующей последовательности действий:
Планирование разработки.
Разработка

операционной спецификации.
Кодирование.
Параметрическое тестирование модулей.
Тестирование сборки.
Опытную эксплуатацию.
Оценку системы пользователем.
Слайд 45

Слайд 46

Слайд 47

Общий вид V-модели жизненного цикла Ветка конструирования Ветка требований 42

Общий вид V-модели жизненного цикла

Ветка конструирования

Ветка требований

42

Слайд 48

Взаимосвязь разработки и испытаний 1. Это две стороны одной медали: разработки

Взаимосвязь разработки и испытаний

1. Это две стороны одной медали: разработки и

тестирование неделимое целое
2. Создание процесс созидательный, испытания – разрушительный.
3. Испытания – процесс затратный не повышающий качества продукта
4. Модель жизненного цикла создает методическую основу выбора стратегии испытаний
Слайд 49

Куликов С.С. Тестирование программного обеспечения. Базовый курс.- Минск, Четыре четверти, 2017.-312 с.

Куликов С.С. Тестирование программного обеспечения. Базовый курс.- Минск, Четыре четверти, 2017.-312

с.
Слайд 50

Краткий очерк истории тестирования 50-60 годы Концепция «исчерпывающего тестирования» (exhausting testing):

Краткий очерк истории тестирования

50-60 годы
Концепция «исчерпывающего тестирования» (exhausting testing): проверка всех

возможных путей выполнения со всеми возможными исходными данными.
Процесс тестирования предельно формализован, отделен от процесса разработки ПО и «математизирован»
Ограничения:
Невозможно найти ошибки в документации
Исчерпывающее тестирование практически невозможно (слишком большое число возможных путей)
Слайд 51

Краткий очерк истории тестирования (продолжение) 70-е годы Возникли две фундаментальные идеи

Краткий очерк истории тестирования (продолжение)

70-е годы
Возникли две фундаментальные идеи тестирования:
(а). Доказательство

работоспособности программ в некоторых заданных условиях (positive testing)
(б). Доказательство неработоспособности программ в некоторых заданных условиях (negative testing)
Ограничения:
Необходимо заранее четко определить условия использования
Слайд 52

Философия «белого» и «черного» ящиков «Белый» ящик. Цель – проверить каждый

Философия «белого» и «черного» ящиков

«Белый» ящик. Цель – проверить каждый путь

алгоритма. При этом спецификация не представляет интереса
«Черный» ящик. Цель: проверить поведение программы при всех возможных сочетаниях входных данных.«...Меня не интересует, как выглядит эта программа и выполнил ли я все команды или все пути. В буду удовлетверен, если программа будет вести себя так, как указано в спецификациях...»
Источник: Г.Майерс Надежность программного обеспечения М.: Мир, 1980
Слайд 53

Стратегии тестирования интеграции Восходящее тестирование Нисходящее тестирование Модифицированный нисходящий метод Метод

Стратегии тестирования интеграции

Восходящее тестирование
Нисходящее тестирование
Модифицированный нисходящий метод
Метод сэндвича
Метод «большого скачка»
Источник: Г.Майерс

Надежность программного обеспечения М.: Мир, 1980
Слайд 54

Краткий очерк истории тестирования (продолжение) 80-е годы 1. Ключевое изменение места

Краткий очерк истории тестирования (продолжение)

80-е годы
1. Ключевое изменение места тестирования в разработке

ПО: вместо финальной стадии реализации проекта тестирование стало применяться в течение всего жизненного цикла разработки, что позволило не только сократить «латентный период» ошибки, но и в известной степени предотвратить их появление
2. Бурное развитие и формализация методов тестирования
3. Первые попытки автоматизации тестирования
Слайд 55

Краткий очерк истории тестирования (продолжение) 90-е годы Переход от тестирования к

Краткий очерк истории тестирования (продолжение)

90-е годы
Переход от тестирования к более всеобъемлющему процессу,

именуемому «Управление качеством» («quality assurance»), который охватывает весь цикл разработки ПО и захватывает процесс планирования, проектирования, реализации ПО.
(фактически признание неразделимого единства основного, вспомогательного и обеспечивающего процессов в рамках программного проекта-PMBOK)
Слайд 56

Слайд 57

Слайд 58

Различие между SQA и SVV Процессы Продукты

Различие между SQA и SVV

Процессы

Продукты

Слайд 59

Краткий очерк истории тестирования (продолжение) 2000-е годы Поиск новых подходов к

Краткий очерк истории тестирования (продолжение)

2000-е годы
Поиск новых подходов к обеспечению качества
Автоматизация тестирования
Во

главу процесса тестирования ставятся не соответствие программы требованиям, а её способность предоставить конечному пользователю возможность эффективно решать свои задачи
Слайд 60

Project Triangle (PMI-1994) Budget Time Required features & Functions

Project Triangle (PMI-1994)

Budget

Time

Required features &
Functions

Слайд 61

Project Triangle (Standish Group-2015) Budget Time Target, Goal, Value & Satisfaction ?

Project Triangle (Standish Group-2015)

Budget

Time

Target, Goal, Value
& Satisfaction

?

Слайд 62

Краткий очерк истории тестирования (продолжение) Текущее состояние Гибкие методологии и гибкое

Краткий очерк истории тестирования (продолжение)

Текущее состояние
Гибкие методологии и гибкое тестирование
Глубокая интеграция процессов

испытаний с процессами разработки и автоматизации
Огромный набор методологий и инструментальных средств
Кросс функциональные команды (программист и тестировщик могут выполнять работу друг друга)
Слайд 63

Основные выводы 1. Границы, критерии качества систем, требования к потребительским свойствам

Основные выводы

1. Границы, критерии качества систем, требования к потребительским свойствам становятся

все более размытыми.
2. Рост масштабов и сложности систем (поведения, устройства, проектирования, внедрения, сопровождения,…)
3. Подходы к разработке и испытаниям, хорошо зарекомендовавшие себя при реализации локальных программных продуктов, локальных и корпоративных информационных систем, в новых условиях имеют ограниченное применение.
Слайд 64

Слайд 65

Разноаспектные подходы к тестированию программных средств (классические подходы)

Разноаспектные подходы к тестированию программных средств (классические подходы)

Слайд 66

Слайд 67

Слайд 68

Слайд 69

Виды тестирования

Виды тестирования

Слайд 70

Слайд 71

Понятия альфа- тестирования …После того, как отдельные программные модули готовы, они

Понятия альфа- тестирования

…После того, как отдельные программные модули готовы, они объединяются

в некое единое целое. Это еще не полнофункциональная программа, но она уже способна работать и выполнять, хотя бы частично, свои главные задачи. Такой вариант программы и называют альфа-версией…
Альфа-тестирование — это этап отладки и проверки альфа-версии программы, а люди, которые будут заниматься ее тестированием — альфа-тестерами. Это могут быть штатные тестировщики компании или люди, которые работают по договору, но это квалифицированные специалисты, умеющие работать со специализированным программным обеспечением и пользоваться специальными методиками.
Слайд 72

Понятие бета-тестирования По окончании работы с альфа-версией выпускается бета-версия. Она представляет

Понятие бета-тестирования

По окончании работы с альфа-версией выпускается бета-версия. Она представляет собой

реально работающую версию программы с полным функционалом. И задача бета-тестов – оценить возможности и стабильность работы программы с точки зрения ее будущих пользователей. Поэтому на роль бета-тестеров приглашаются просто люди, имеющие опыт работы с программами такого типа или, что еще лучше, с предыдущей версией этой же программы.
…Может быть объявлено открытое бета-тестирование, когда на роль бета-тестеров приглашают всех желающих…
Слайд 73

Место альфа- и бета тестирования в испытании ПО

Место альфа- и бета тестирования в испытании ПО

Слайд 74

Сценарное тестирование Сценарное тестирование- классическое тестирование по предварительно написанным и задокументированным

Сценарное тестирование

Сценарное тестирование- классическое тестирование по предварительно написанным и задокументированным сценариям.
В

пользу сценарного тестирования:
сравнительная легкость планирования: тест-кейсы можно легко поделить между различными тестировщиками или командами.
Слайд 75

Новые подходы к тестированию программных средств

Новые подходы к тестированию программных средств

Слайд 76

Cloud, Fog, Edge computing

Cloud, Fog, Edge computing

Слайд 77

Ad hoc тестирование

Ad hoc тестирование

Слайд 78

Содержание Ad hoc тестирования Свободное тестирование (ad-hoc testing) – это вид

Содержание Ad hoc тестирования

Свободное тестирование (ad-hoc testing) – это вид тестирования, который выполняется без

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

Виды свободного тестирования (ad-hoc testing) Buddy testing – процесс, когда 2

Виды свободного тестирования (ad-hoc testing)

Buddy testing – процесс, когда 2 человека, как

правило разработчик и тестировщик, работают параллельно и находят дефекты в одном и том же модуле тестируемого продукта. Такой вид тестирования помогает тестировщику выполнять необходимые проверки, а разработчику исправлять множество дефектов на ранних этапах.
Pair testing – процесс, когда 2 тестировщика проверяют один модуль и помогают друг другу. К примеру, один может искать дефекты, а второй их документировать. Таким образом, у одного тестера будет функция, скажем так, обнаружителя, у другого – описателя.
Monkey testing – произвольное тестирование продукта с целью как можно быстрее, используя различные вариации входных данных, нарушить работу программы или вызвать ее остановку (простыми словами – сломать).
Слайд 80

Основные преимущества ad-hoc testing Нет необходимости тратить время на подготовку документации.

Основные преимущества ad-hoc testing

Нет необходимости тратить время на подготовку документации.
Самые важные

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

Исследовательское тестирование (Exploratory testing)

Исследовательское тестирование (Exploratory testing)

Слайд 82

Слайд 83

Понятие исследовательского тестирования Исследовательское тестирование (exploratory testing) — это одновременное изучение

Понятие исследовательского тестирования

Исследовательское тестирование (exploratory testing) — это одновременное изучение программного продукта, проектирование

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

Когда следует применять исследовательское тестирование? Когда нужно обеспечить быструю обратную связь

Когда следует применять исследовательское тестирование?

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

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

Предпосылки к использованию исследовательского тестирования в чистом виде Мало времени :

Предпосылки к использованию исследовательского тестирования в чистом виде

Мало времени : если

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

Использование исследовательского тестирование в дополнение к сценарному тестированию Тестировщики постоянно проходят

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

Тестировщики постоянно проходят одни

и те же тестовые сценарии
При многократном прохождении одних и тех же тестов, например, при регрессионном тестировании. Тестировщики теряют концентрацию и начинают пропускать дефекты. В этом случае исследовательское тестирование помогает взглянуть на проект под новым углом и найти пропущенные дефекты. 
Тестировщик отвлекается от шаблонных действий и чувствует себя в большей степени обычным пользователем. Это помогает найти дефекты, сильнее влияющие на конечного потребителя разрабатываемого продукта. 
Слайд 87

Использование исследовательского тестирование в дополнение к сценарному тестированию (продолжение) Пришел внезапный

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

Пришел внезапный запрос на

изменения Времени на разработку новых сценариев нет, так как все заняты другими запланированными задачами или изменения потребуют переработать большую часть документации. В этой ситуации тестирование исследовательским методом может быть наиболее оптимальным.
Когда хочется перестраховаться Продукт уже протестирован по сценариям, но всё еще хочется убедиться в том, что ничего не было упущено.
Слайд 88

Когда одним исследовательским тестированием не обойтись Приложение стандартизованное: Приложения, работающие по

Когда одним исследовательским тестированием не обойтись

Приложение стандартизованное: Приложения, работающие по стандартам и гостам, а также

системы, для которых малейшее отклонение может быть критичным. Это могут быть приложения, отвечающие за полеты ракет или проводящие финансовые операции.
Проводится интеграционное тестирование. В этом случае исследовательское тестирование возможно, например, при тестировании API. Но обычно интеграционное тестирование проводится для проверки взаимодействия внутренних компонентов приложений. Эта работа хорошо покрыта документацией и часто автоматизируется
Слайд 89

Когда одним исследовательским тестированием не обойтись (продолжение) Тестовые сценарии отдаются на

Когда одним исследовательским тестированием не обойтись (продолжение)

Тестовые сценарии отдаются на в стороннюю организацию. Контролировать

поставленную задачу и процент ее выполнения проще по формализованным сценариям.
Длительный проект. Тестировщики могут быть подключены к проекту на время определенной фазы, а после, пока разработчики реализовывают новый функционал, заниматься другими проектами. Если долго не тестировать конкретную функциональность, то ее специфика забывается
Слайд 90

Системное сочетание исследовательского и сценарного тестирования Исследовательское тестирование — не означает

Системное сочетание исследовательского и сценарного тестирования

Исследовательское тестирование — не означает полное отсутствие

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

Слайд 92

Слайд 93

Содержание регрессионного тестирования Регрессионное тестирование (regression testing) – это механизм проверки,

Содержание регрессионного тестирования

Регрессионное тестирование (regression testing) – это механизм проверки, который

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

Тема : Стандартизация – путь к успеху программных проектов

Тема : Стандартизация – путь к успеху программных проектов

Слайд 95

Слайд 96

Различие между SQA и SVV Процессы Продукты

Различие между SQA и SVV

Процессы

Продукты

Слайд 97

Вывод: Следование положениям стандартов обеспечивает «правильную» реализацию программного проекта в случае

Вывод:
Следование положениям стандартов обеспечивает «правильную» реализацию программного проекта в случае стабильного

состояния объекта управления
Испытания обеспечивают контроль соответствия промежуточных и конечных результатов проекта заранее определенным требованиям
Слайд 98

Методология «развертывание функций качества» - Quality Function Deployment-QFD

Методология «развертывание функций качества» - Quality Function Deployment-QFD

Слайд 99

Четырехфазная модель American Supplier Institute-АSI

Четырехфазная модель American Supplier Institute-АSI

Слайд 100

Тема: Реализация системного подхода при испытаниях программных систем

Тема: Реализация системного подхода при испытаниях программных систем

Слайд 101

Слайд 102

IEEE Std 1012 - 2004 IEEE Standard for Software Verification and

IEEE Std 1012 - 2004
IEEE Standard for Software Verification and Validation
Recognized

as an American National Standard (ANSI)
Слайд 103

Слайд 104

Структурирование вариантов использования на основе целей пользователей Вариант использования представляет собою

Структурирование вариантов использования на основе целей пользователей

Вариант использования представляет собою текстовое

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

Формальные приемы структурного анализа 1. Количество ошибок в программном модуле прямо

Формальные приемы структурного анализа

1. Количество ошибок в программном модуле прямо

пропорционально сложности модуля
Источник: В.В.Липаев Анализ и сокращение рисков проектов сложных программных средств. М.: СИНТЕГ, 2005
2. Цикломатический показатель сложности структуры
Источник: ESA PSS-05-10