Похожие презентации:
Тестирование ПО и его связь с жизненным циклом ПО
1.
Тестирование ПО и егосвязь с жизненным
циклом ПО
2.
2Цикл разработки ПО
Жизненный цикл ПО (ЖЦ ПО, software
development life cycle) — период времени,
который начинается с момента принятия
решения о необходимости создания ПО и
заканчивается в момент его полного
изъятия из эксплуатации
Чем более отлажены каждая из стадий
ЖЦ и координация между ними, тем
эффективнее работает компания, тем
выше качество и тем счастливее
пользователи/клиенты
3.
3Жизненный цикл ПО
Формирование требований
Проектирование
Реализация
Тестирование
Внедрение
Сопровождение
4.
4Когда начать
тестировать?
5.
5Формирование
требований
Тестирование требований на
• Формирование
требований
• Проектирование
• Реализация
• Тестирование
• Внедрение
• Сопровождение
вменяемость/ осуществимость
Тестирование функциональной
спецификации
Создание предварительных тестовых
сценариев на основе требований
6.
6Проектирование
Тестирование документов,
• Формирование
требований
• Проектирование
• Реализация
• Тестирование
• Внедрение
• Сопровождение
описывающих архитектуру (product
architecture) и дизайн (product design)
Тестирование плана проекта
7.
7Реализация
Инспекция кода и модульное
• Формирование
требований
• Проектирование
• Реализация
• Тестирование
• Внедрение
• Сопровождение
тестирование
Тестирование результатов итерации
разработки
Регрессионное тестирование
8.
8Тестирование
Тестирование готового
приложения и приемочное
тестирование
• Формирование
требований
• Проектирование
• Реализация
• Тестирование
• Внедрение
• Сопровождение
9.
9Внедрение
Тестирование совместимости
• Формирование
требований
• Проектирование
• Реализация
• Тестирование
• Внедрение
• Сопровождение
продукта с существующей
инфраструктурой заказчика (типы
серверов, окружение и т. д.)
Сбор и обработка обратной связи о
приложении от пользователей
10.
10Сопровождение
Обработка отчетов об
• Формирование
требований
• Проектирование
• Реализация
• Тестирование
• Внедрение
• Сопровождение
ошибках от пользователей во
время эксплуатации
Верификация исправления ошибок
Обработка запросов новой
функциональности
Тестирование новой функциональности
11.
11Когда прекращать
тестирование?
12.
12Эвристики
Эвристики – это быстрые, недорогие
способы решения проблемы или
принятия решения
13.
13Эвристики
Эвристика «Время вышло!»
Для многих специалистов по
тестированию это наиболее
распространенная эвристика: мы
останавливаем тестирование, когда
заканчивается выделенное на него
время.
14.
14Эвристики
Эвристика пиньяты
Мы прекращаем ломать программу,
когда начинают выпадать конфеты – мы
останавливаем тестирование, когда
видим первую достаточно серьезную
проблему.
Пиньята (исп. Piñata) — мексиканская по происхождению полая игрушка
довольно крупных размеров, изготовленная из папье-маше или лёгкой
обёрточной бумаги с орнаментом и украшениями. Своей формой пиньята
воспроизводит фигуры животных (обычно лошадей) или геометрические
фигуры, которые наполняются различными угощениями или сюрпризами для
детей (конфеты, хлопушки, игрушки, конфетти, орехи и т. п.)
15.
15Эвристики
Эвристика «мертвой лошади»
В программе слишком много ошибок,
так что продолжение тестирования не
имеет смысла. Мы знаем, что все
изменится настолько, что сведет на нет
результаты текущего тестирования.
16.
16Эвристики
Эвристика «Задание выполнено»
Мы останавливаем тестирование, когда
найдены ответы на все поставленные
вопросы.
17.
17Эвристики
Эвристика «Отмена задания»
Наш клиент сказал нам: «пожалуйста,
прекратите тестирование». Это может
произойти по причине перерасхода бюджета,
или вследствие отмены проекта, и по любой
другой причине. Какова бы ни была причина,
нам поручили остановить тестирование.
Эвристика «Время вышло!» может быть
частным случаем более общей «Отмены
задания», если предпочтительнее, чтобы не мы
сами, а заказчик принял решение о том, что
время вышло
18.
18Эвристики
Эвристика «Я зашел в тупик!»
Тестирование останавливается при
обнаружении некоего препятствия:
нет информации, которая требуется (например,
нет достаточного количества спецификаций)
имеется блокирующая ошибка, из-за которой
нельзя перейти в другую область ПО
нет необходимого оборудования или
инструментария
у команды нет квалификации, требуемой для
выполнения некоторых специальных тестов
19.
19Эвристики
Эвристика «Освежающей паузы»
Вместо прекращения тестирования мы
приостанавливаем его на некоторое время.
Мы можем остановить тестирование и сделать
перерыв, когда мы устали, когда нам стало
скучно или пропало вдохновение. Мы можем
сделать паузу на то, чтобы выполнить
некоторые исследования, разработать планы,
поразмыслить над тем, что мы делали в
прошлом и понять, что делать дальше. Идея
заключается в том, что нам требуется
определенный перерыв, после которого мы
сможем вернуться к продукту со свежим
взглядом или свежими мыслями.
20.
20Эвристики
Эвристика «Отсутствие продвижения»
Что бы мы ни делали, мы получаем тот
же самый результат
Это может происходить в случае, когда
программа падает определенным
способом или перестает отвечать, но
также мы можем не продвигаться, когда
программа в основном ведет себя
стабильно
21.
21Эвристики
Эвристика «Привычного завершения»
Мы останавливаем тестирование тогда, когда
мы обычно останавливаем тестирование.
Имеется протокол, задающий определенное
количество идей для тестирования, или тесткейсов, или циклов тестирования, или
определенный объем работ по тестированию,
который мы выполняем и после этого
останавливаемся.
Agile-команды, например, часто применяют
такой подход: «когда выполнены все
приемочные тесты, мы знаем, что продукт
готов к поставке».
22.
22Эвристики
Эвристика «Больше нет интересных вопросов»
В этот момент мы решаем, что не осталось
вопросов, ответы на которые были бы достаточно
ценными, чтобы оправдать стоимость продолжения
тестирования, и поэтому мы останавливаемся
Эта эвристика используется в основном как
дополнение к другим эвристикам, помогая принять
решение о том, есть ли какие-то вопросы или
риски, которые отменяют действие этих эвристик.
Кроме того, если одна эвристика советует нам
прекратить тестирование, следует проверить, нет
ли интересных вопросов или серьезных рисков в
других областях, и если они есть, то мы скорее
продолжим тестирование, чем остановимся.
23.
23Эвристики
Эвристика уклонения/безразличия
Иногда людей не интересует дополнительная
информация, либо они не хотят знать, что
происходит в программе.
Тестируемое приложение может быть первой
версией, которую, как мы знаем, скоро заменят.
Прекращают тестирование по причине лени, злого
умысла или отсутствия мотивации.
Иногда бизнес-критичность выпуска нового релиза
настолько высока, что никакая мыслимая
проблема не остановит выход программы, и
поэтому никакие новые результаты тестирования
не будут иметь значения.
24.
24Методологии
разработки ПО
25.
25Методологии разработки
«Колхоз» против «Процесса»
26.
26Основная задача методологий
Быстрота выполнения работ и четкая
координация команд
Качественное исполнение и контроль
качества
Сокращение издержек
27.
27Отличия от «Кустарного
производства»
Большой объем параллельных проектов
Большая предсказуемость объема
работ и результата
28.
28Методология описывает
Роли
Активности
Артефакты
Фазы и критерии их начала/окончания
29.
29Типичные роли
Руководитель проекта (Project Manager)
Архитектор (Architect/Designer)
Бизнес-аналитик (Business Analyst)
Разработчик (Developer)
Тестировщик (Test Engineer/Tester)
30.
30Модели жизненного цикла ПО
Модель жизненного цикла ПО -
структура, определяющая
последовательность выполнения и
взаимосвязи процессов, действий и
задач на протяжении жизненного цикла
Каскадная модель
Итеративная модель
Спиральная модель
…
31.
31Каскадные методологии: Waterfall
Формирование
требований
Переход от одной
Проектирование
фазы к другой
происходит только
Реализация
после полного и
успешного завершения
предыдущей
Тестирование
Сопровождение
32.
32Waterfall
Следуя каскадной модели, разработчик
переходит от одной стадии к другой строго
последовательно.
1. Сначала полностью завершается этап
«определение требований», в результате
чего получается список требований к ПО.
2. После происходит переход к
проектированию, в ходе которого
создаются документы, подробно
описывающие для программистов способ
и план реализации указанных требований.
33.
33Waterfall
3.
4.
5.
6.
После проектирования программисты
выполняют реализацию полученного проекта.
На следующей стадии процесса происходит
интеграция отдельных компонентов,
разрабатываемых различными командами
программистов.
Далее производится тестирование и отладка
продукта; на этой стадии устраняются все
недочёты, появившиеся на предыдущих
стадиях разработки.
После этого ПО внедряется и обеспечивается
его поддержка — внесение новой
функциональности и устранение ошибок.
34.
34Waterfall
Каскадная модель подразумевает, что
переход от одной фазы разработки к
другой происходит только после
полного и успешного завершения
предыдущей фазы, и что переходов
назад либо вперёд или перекрытия фаз
— не происходит.
35.
35Waterfall
Недостатки:
участие
пользователей
ПО либо не
предусмотрено,
либо косвенно на
стадии сбора
требований
тестирование
появляется лишь
с середины
развития проекта
36.
36Каскадные методологии: V-model
Каждая последующая фаза начинается по
завершению получения результативных данных
предыдущей фазы.
Выделены
взаимосвязи,
существующие
между фазами
проектирования
(до кодирования)
и фазами
тестирования
37.
37V-model
38.
38Итерационная инкрементальная
модель
с точки зрения ЖЦ модель является
итерационной - многократное повторение
одних и тех же стадий
с точки зрения развития продукта
(приращения его полезных функций)
модель является инкрементальной
Является основой
современного
подхода к
разработке ПО
39.
39Итерационная инкрементальная
модель
Ключевая особенность - разбиение проекта на
относительно небольшие промежутки
(итерации), каждый из которых в общем случае
может включать в себя все классические
стадии, присущие водопадной и v-образной
моделям
Итогом итерации является приращение
(инкремент) функциональности продукта,
выраженное в промежуточном билде
40.
40Итерационная инкрементальная
модель
41.
41Итерационная инкрементальная
модель
+ Модель хорошо себя зарекомендовала на
объёмных и сложных проектах,
выполняемых большими командами на
протяжении длительных сроков
− Основной недостаток - высокие накладные
расходы, вызванные высокой
«бюрократизированностью» и общей
громоздкостью модели
42.
42Инкрементное построение
Предполагает, что у
клиента есть полностью
сформированное
представление о том, что
ему нужно
43.
43Итеративное построение
Итерация позволяет
менее разработанным
идеям развиваться и
совершенствоваться
44.
44Гибкая модель, Agile
Agile - совокупность различных
подходов к разработке ПО, базируется
на «agile-манифесте»
(http://www.agilemanifesto.org/iso/ru/)
Agile-подходы:
SCRUM
Extreme programming
Kanban
…
45.
45Agile-манифест
Люди и взаимодействие
важнее процессов и
инструментов
Работающий продукт
важнее исчерпывающей
документации
Сотрудничество с
заказчиком важнее
согласования условий
контракта
Готовность к изменениям
важнее следования
первоначальному плану
46.
46Гибкая модель, Agile
Гибкая методология разработки - серия
подходов к разработке ПО, ориентированных на:
использование итеративной разработки,
динамическое формирование требований
и обеспечение их реализации в результате
постоянного взаимодействия внутри
самоорганизующихся рабочих групп, состоящих
из специалистов различного профиля
47.
47Пояснение принципов Agileманифеста (1/2)
Удовлетворение клиента за счёт ранней и бесперебойной
поставки ценного программного обеспечения
Приветствие изменений требований даже в конце
разработки (это может повысить конкурентоспособность
полученного продукта)
Частая поставка рабочего программного обеспечения
(каждый месяц или неделю или ещё чаще)
Тесное, ежедневное общение заказчика с разработчиками
на протяжении всего проекта
Проектом занимаются мотивированные личности, которые
обеспечены нужными условиями работы, поддержкой и
доверием
Рекомендуемый метод передачи информации — личный
разговор (лицом к лицу)
48.
48Пояснение принципов Agileманифеста (2/2)
Работающее программное обеспечение — лучший
измеритель прогресса
Спонсоры, разработчики и пользователи должны
иметь возможность поддерживать постоянный темп
на неопределённый срок
Постоянное внимание улучшению технического
мастерства и удобному дизайну
Простота — искусство не делать лишней работы
Лучшие технические требования, дизайн и
архитектура получаются у самоорганизованной
команды
Постоянная адаптация к изменяющимся
обстоятельствам
49.
49Преимущества гибкого подхода
Гибкая модель - развитие и продолжение всего
того, что было за десятилетия создано и
опробовано в других моделях
+ Был достигнут ощутимый результат в снижении
бюрократической составляющей и
максимальной адаптации процесса разработки
ПО к мгновенным изменениям рынка и
требований заказчика
− Сложность применения к крупным проектам
− Частое ошибочное внедрение agile-подходов,
вызванное недопониманием фундаментальных
принципов модели
50.
50Сравнение моделей разработки ПО
Модель
Водопадная
Преимущества
Недостатки
- У каждой стадии
есть чёткий
проверяемый
результат
- В каждый момент
времени команда
выполняет один
вид работы
- Хорошо работает
для небольших
задач
- Полная
неспособность
адаптировать
проект к
изменениям в
требованиях
- Крайне позднее
создание
работающего
продукта
Тестирование
С
середины
проекта
51.
51Сравнение моделей разработки ПО
Модель
V-образная
Преимущества
Недостатки
- У каждой стадии
есть чёткий
проверяемый
результат
- Внимание
тестированию
уделяется с первой
же стадии
- Хорошо работает
для проектов со
стабильными
требованиями
- Недостаточная
гибкость и
адаптируемость
- Отсутствует
раннее
прототипирование
- Сложность
устранения
проблем,
пропущенных на
ранних стадиях
развития проекта
Тестирование
На
переходах
между
стадиями
52.
52Сравнение моделей разработки ПО
Модель
Преимущества
Недостатки
Тестирование
- Достаточно
- Недостаточная - В опредераннее прото- гибкость внутри лённые
типирование
итераций
моменты
Итера- Простота
- Сложность
итераций
ционная
управления
устранения
- Повторное
инкреитерациями
проблем,
тестирование
мен- Декомпозиция пропущенных на (после
тальная
проекта на
ранних стадиях доработки)
управляемые
развития
уже
итерации
проекта
проверенного
ранее
53.
53Сравнение моделей разработки ПО
Модель
Преимущества
Недостатки
Тестирование
- Максимальное
вовлечение
заказчика
- Много работы с
требованиями
Гибкая - Тесная
интеграция
тестирования и
разработки
- Минимизация
документации
- Сложность
реализации
для больших
проектов
- Сложность
построения
стабильных
процессов
-В
определённые
моменты
итераций и в
любой
необходимый
момент