Тестирование ПО и его связь с жизненным циклом ПО

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.

32
Waterfall
Следуя каскадной модели, разработчик
переходит от одной стадии к другой строго
последовательно.
1. Сначала полностью завершается этап
«определение требований», в результате
чего получается список требований к ПО.
2. После происходит переход к
проектированию, в ходе которого
создаются документы, подробно
описывающие для программистов способ
и план реализации указанных требований.

33.

33
Waterfall
3.
4.
5.
6.
После проектирования программисты
выполняют реализацию полученного проекта.
На следующей стадии процесса происходит
интеграция отдельных компонентов,
разрабатываемых различными командами
программистов.
Далее производится тестирование и отладка
продукта; на этой стадии устраняются все
недочёты, появившиеся на предыдущих
стадиях разработки.
После этого ПО внедряется и обеспечивается
его поддержка — внесение новой
функциональности и устранение ошибок.

34.

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

35.

35
Waterfall
Недостатки:
участие
пользователей
ПО либо не
предусмотрено,
либо косвенно на
стадии сбора
требований
тестирование
появляется лишь
с середины
развития проекта

36.

36
Каскадные методологии: V-model
Каждая последующая фаза начинается по
завершению получения результативных данных
предыдущей фазы.
Выделены
взаимосвязи,
существующие
между фазами
проектирования
(до кодирования)
и фазами
тестирования

37.

37
V-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.

45
Agile-манифест
Люди и взаимодействие
важнее процессов и
инструментов
Работающий продукт
важнее исчерпывающей
документации
Сотрудничество с
заказчиком важнее
согласования условий
контракта
Готовность к изменениям
важнее следования
первоначальному плану

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
Сравнение моделей разработки ПО
Модель
Преимущества
Недостатки
Тестирование
- Максимальное
вовлечение
заказчика
- Много работы с
требованиями
Гибкая - Тесная
интеграция
тестирования и
разработки
- Минимизация
документации
- Сложность
реализации
для больших
проектов
- Сложность
построения
стабильных
процессов
-В
определённые
моменты
итераций и в
любой
необходимый
момент