Поддержка и тестирование программных модулей. Основы тестирования

1. МДК 01.02 «Поддержка и тестирование программных модулей»

1

2. ОСНОВЫ тестирования

2

3. Почему тестирование необходимо

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

4. Причины дефектов в программном обеспечении

Человек может сделать ошибку (просчет), которая
порождает дефект (недочет, помеху) в программном
коде или документе. Если код с дефектом выполнен, то
система может быть не в состоянии сделать то, что должна
делать (или сделать то, что от нее не ожидают), порождая
отказ.
Дефекты встречаются, потому что:
люди склонны ошибаться,
существует нехватка времени,
сложность кода,
сложность инфраструктуры, изменения технологий и
/или много системных взаимодействий.
4

5. Программная ошибка

Программная ошибка (жарг. баг) — означает
ошибку в программе или в системе, из-за которой
программа выдает неожиданное поведение и, как
следствие, неверный результат.
9 сентября 1947 года, когда компьютеры не
! помещались
в спальню, а программы делали на
бумаге, ученые Гарвардского университета,
тестировавшие вычислительную машину Mark II
Aiken Relay Calculator, нашли сгоревшего
мотылька, застрявшего между замкнутыми
контактами. Этот “bug” был заклеен скотчем в
технический журнал с подписью: «Первый
реальный случай обнаружения жучка».
Отныне, 9 сентября является всемирным днем
тестировщиков.
5

6. Роль тестирования в разработке программного обеспечения

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

7. Цели тестирования:

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

8. Пример тестирования:

Например, тестирование поля
«Возраст»
сервиса, пользователям которого должно быть от
18 до 65 лет (включительно).
8

9. Пример тестирования:

Для тестирования мы с вами будем использовать
инструмент — чек-лист, в который будем вносить все
проверки.
Чек-лист – это список, содержащий ряд
необходимых проверок во время тестирования
программного
продукта.
Отмечая
пункты
списка, команда или один тестировщик могут
узнать о текущем состоянии выполненной
работы и о качестве продукта.
Сначала необходимо протестировать, что поле
выполняют свою основную функцию: ввод от 18 до 65
лет. А также проверим среднее значение.
? Достаточно
трех проверок?
Чек - лист
Значение проверки
Результат
18
30
65
9

10. Пример тестирования:

Трех проверок, недостаточно. Вводить, что вздумается,
мы тоже не можем (время — деньги).
Воспользуемся популярной техникой тест-дизайна,
позволяющей быстро и качественно проверить что-либо:
Техника выделения классов эквивалентности и
граничных
значений
позволяет
уйти
от
дублирующих проверок. Следовательно, мы сократим
количество однотипных тестов.
Классы
эквивалентности
—
это
разбиение
функционала на наборы данных, которые ведут себя в
пределах этих наборов одинаково. Например, дети,
взрослые и пенсионеры - это все классы эквивалентности.
Анализ граничных значений — это метод, который
улучшает разделение классов эквивалентности. В нашем
случае, самые близкие значения — это 17 и 66. Добавим их10
в чек-лист:

11. Пример тестирования:

Чек - лист
Значение проверки
Результат
18
30
65
17
66
Еще необходимо проверить, что будет, если мы
введем некорректные значения:
ничего не вводить? (null - пустое значение)
введем отрицательное число?
введем 0?
введем трёхзначное число?
введем буквы на кириллице?
11
введем буквы на латинице?
введем символы пунктуации?

12. Пример тестирования:

Чек - лист
Значение
Результат
проверки
18
30
65
17
66
null
-1
0
100
баг
error
)
12

13. Пример тестирования:

Необходимо ввести в поле "Возраст" проверки из
чек-листа по порядку.
Поле
может срабатывать
на невалидные
(неправильные) данные корректно (PASS), что будет
багом.
И, наоборот, выдавать ошибку (FAIL), если ввести
валидные
(правильные)
данные.
Запишем
результаты проверок - Pass или Fail. В конце
необходимо определить количество багов у поля
"Возраст".
13

14. Пример тестирования:

Чек - лист
Значение
Результат
проверки
Pass
18
30
Pass
65
Pass
Fail
17
Pass
66
Pass
null
-1
Fail
Fail
0
Pass
100
Fail
баг
Fail
error
Pass
)
? Какие тесты
показали
наличие
ошибки?
14

15. Тестирование и Качество

Обеспечение качества
(QA)
Контроль качества
(QC)
Тестирование
15

16. Testing (тестирование)

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

17. QC (Quality Control, контроль качества)

Второй уровень, включает в себя тестирование и
контроль за соответствием заранее согласованному
уровню качества продукта и готовность к выпуску
продукта в продакшн.
Основная
задача
контроля
качества
—
предоставить объективную картину того, что
происходит с качеством продукта на разных этапах
разработки. Управление качеством (Quality control)
— часть менеджмента качества, направленная на
выполнение требований к качеству.
Вернемся к интернет-магазину. QC даст
отмашку на релиз, если не заполнена страница
благодарностей, на которую можно перейти из
футера сайта. Или, например, не даст добро, если
страница благодарностей заполнена, а каталог 17
пустой.

18. QA (Quality Assurance, обеспечение качества)

Основная задача — выстроить систему, которая
будет работать на качество продукта, чтобы при
тестировании
количество
дефектов
было
минимальным.
В зависимости от специфики проекта сюда
может входить тестирование документации, ревью
кода на соответствие стандартам, внедрение какихто методик по работе с качеством.
Обеспечение качества (Quality Assurance) —
часть менеджмента качества, направленная на
создание уверенности, что требования к качеству
будут выполнены.
18

19. ПРИНЦИПЫ и направления деятельности процесса тестирования

19

20. Принципы тестирования

1. Тестирование не может доказать отсутствие багов (только
их наличие);
Тестирование может показать, что дефекты присутствуют,
но не может доказать, что их нет.
Тестирование снижает вероятность наличия дефектов,
находящихся в программном обеспечении, но, даже если
дефекты не были обнаружены, это не доказывает его
корректности.
2. Исчерпывающее тестирование невозможно по
определению;
Полное тестирование с использованием всех комбинаций
вводов и предусловий физически невыполнимо, за
исключением тривиальных случаев. Вместо
исчерпывающего тестирования должны использоваться
анализ рисков и расстановка приоритетов, чтобы более
точно сфокусировать усилия по тестированию.
20

21. Принципы тестирования

3. Раннее тестирование позволяет сэкономить ресурсы;
Чтобы найти дефекты как можно раньше, действия по
тестированию должны быть начаты как можно раньше в
жизненном цикле разработки программного обеспечения
или системы, и должны быть сфокусированы на
определенных целях.
4. Парадокс пестицидов;
Если одни и те же тесты будут прогоняться много раз, в
конечном счете этот набор тестовых сценариев больше не
будет находить новых дефектов. Чтобы преодолеть этот
“парадокс пестицида”, тестовые сценарии должны
регулярно рецензироваться и корректироваться, новые
тесты должны быть разносторонними, чтобы охватить все
компоненты программного обеспечения, или системы, и
найти как можно больше дефектов.
21

22. Принципы тестирования

5. Кластеризация багов;
Усилия тестирования должны быть сосредоточены
пропорционально ожидаемой, а позже реальной плотности
дефектов по модулям. Как правило, большая часть
дефектов, обнаруженных при тестировании или повлекших
за собой основное количество сбоев системы, содержится в
небольшом количестве модулей.
6. Тестирование зависит от контекста;
Тестирование выполняется по-разному в зависимости от
контекста. Например, программное обеспечение, в котором
критически важна безопасность, тестируется иначе, чем
сайт электронной коммерции.
7. Заблуждение об отсутствии ошибок.
Обнаружение и исправление дефектов не помогут, если
созданная система не подходит пользователю и не
удовлетворяет его ожиданиям и потребностям.
22

23. Процесс тестирования

Основной процесс тестирования состоит из
следующих направлений деятельности:
1. Планирование и управление тестированием
Планирование тестирования – это действия,
направленные на определение целей тестирования и
описание задач тестирования для достижения этих
целей.
Управление тестированием – это постоянное
сопоставление текущего положения дел с планом и
отчетность о состоянии дел, включая отклонения от
плана. Это позволяет предпринять меры, необходимые
для достижения целей проекта.
23

24. Процесс тестирования

2. Анализ и проектирование тестов
Анализ и проектирование тестов - это
деятельность, во время которой общие цели
тестирования материализуются в тестовые условия и
тестовые сценарии.
3. Реализация и выполнение тестов
Реализация и выполнение тестов – это
деятельность, где процедуры тестирования или
автоматизированные сценарии задаются
последовательностью тестовых сценариев, а также
собирается любая информация, необходимая для
выполнения тестов, разворачивается окружающая
среда, и запускаются тесты.
24

25. Процесс тестирования

4. Оценка критериев выхода и отчетность
Оценка критериев выхода - это деятельность, где
выполнение тестов оценивается согласно определенным
целям. Она должна быть выполнена для каждого уровня
тестирования.
Для оценки критериев выхода поставлены следующие
основные задачи:
• Сверка протокола тестирования в сравнении с
критериями выхода, определенными в плане тестирования
• Анализ необходимости использования дополнительных
тестов или изменения критериев выхода
• Написание итогового отчета о тестировании для
заинтересованных лиц
25

26. Процесс тестирования

5. Действия по завершению тестирования
Действия по завершению тестирования собирают
данные о завершенных испытаниях для объединения
опыта, тестового обеспечения, фактов и цифр.
Действия по завершению тестирования происходят
на тех этапах проекта, когда система программного
обеспечения выпущена, тестирование завершено (или
прервано), этап был завершен, или релиз по
сопровождению был закончен.
26

27. ВИДЫ тестирования

27

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

По критерию
запуска программы
тестирование
делится на:
Статическое
Динамическое
Статическое
тестирование (Static
Testing) — тип
тестирования, при котором
код программы не
исполняется во время
проведения тестов.
• Динамическое тестирова
ние (Dynamic Testing) —
тестирование, при котором
выполняется код
программы и проверяется
поведение приложения во 28
время работы.

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

При Ручном тестировании
(Manual
Testing) тестировщик
выполняет тесты, не
используя каких-либо
средств автоматизации;
• Автоматизированное
тестирование (Automation
Testing) предполагает
использование
специального
программного обеспечения
(помимо тестируемого) для
контроля выполнения
29
тестов и сравнения
ожидаемого фактического
По степени
автоматизации
тестирование
делится на:
Ручное
Автоматизированное

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

По ожидаемому
поведению
тестирование
разделяется на:
Позитивное
тестирование
Позитивное тестирование
(Positive Testing) —
тестирование с применением
сценариев, которые
соответствуют ожидаемому
поведению приложения.
Негативное тестирование
Негативное
тестирование
(Negative Testing) —
тестирование с применением
сценариев, которые
соответствуют внештатному
поведению приложения.
30

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

Функциональное
тестирование (Functional
Testing) включает в себя
тесты, оценивающие функции
приложения.
Нефункциональное
тестирование (Nonfunctional Testing) оценивает
характеристики систем и
программного обеспечения,
такие как надежность,
производительность, удобство
31
использования,
эффективность работы или
его безопасность.
Тестирование делится
на:
Функциональное
тестирование
Нефункциональное тестирование

32. Виды функционального тестирования:

•Дымовое
тестирование
•Дымовое тестирование
(Smoke Testing) - включает в
себя минимальный набор тестов
на самые очевидные ошибки.
Например, регистрация нового
пользователя, создание нового
заказа, выставление счета
клиенту, получение оплаты.
32

33. Виды функционального тестирования:

•Санитарное
тестирование
•Санитарное тестирование
(Sanity Testing) — проводится
после незначительных изменений
в функционале, коде или починке
багов.
Например: программисты
устранили дефект на странице
создания нового заказа.
Обычно выполняется вручную.
33

34. Виды функционального тестирования:

•Регрессионно
е тестирование
•Регрессионное тестирование
(Regression Testing) — тестирование
приложения, направленное на
обнаружение ошибок в уже проверенных
участках программ (или исходных кодах).
В регрессионное включаются те области,
которые часто меняются в ходе разработки,
где высока вероятность ошибки.
Полная автоматизация — лучшая
практика в этом типе тестирования.
34

35. Виды функционального тестирования:

•Повторное
тестирование
•Повторное тестирование
(Retesting) — проводится после
устранения дефекта в части
функционала с целью подтверждения
исправления ошибки.
При повторном тестировании
используются те же самые тест-кейсы,
которые выявили дефект — с
использованием тех же данных, на
том же окружении, но с различным
набором входных данных.
35

36. Виды нефункционального тестирования:

•Тестирование графического
интерфейса (User interface testing) —
проверка соответствия интерфейса ПО
требованиям дизайна.
Тестирование удобства пользования
(Usability Testing) — определение
удобства использования приложения.
Тестирование Доступности
(Accessibility Testing) — проверка
доступности приложения для людей с
ограниченными возможностями
36

37. Виды нефункционального тестирования:

•Тестирование производительности
(Performance Testing) — тестирование
скорости работы приложения под определённой
нагрузкой.
Нагрузочное тестирование (Load testing) —
данный тип тестирования позволяет оценить
поведение системы при нормальных условиях и
возрастающей нагрузке.
Стресс-тестирование (Stress testing) —
используется для определения устойчивости
системы или модуля при пороговых значениях
рабочей нагрузки или за ее пределом.
37

38. Виды нефункционального тестирования:

•Объемное тестирование (Volume testing) —
тестирование позволяет оценить производительность
системы при увеличении объемов данных как самого
приложения, так и его базы данных.
Тестирование надежности (Reliability
Testing) — проверка работоспособности приложения
при длительном тестировании с ожидаемым уровнем
нагрузки.
Тестирование безопасности (Security
Testing) — оценка уязвимости приложения к
различным атакам.
38

39. Виды нефункционального тестирования:

•Тестирование Установки (Installation
Testing) — проверка успешной инсталляции,
настройки, обновления и удаления.
Тестирование совместимости (Compatibility
Testing) — проверка корректной работы
приложения в определенном окружении,
например, устройстве, операционной системе
Тестирование на отказ и восстановление
(Recovery Testing) — проверка насколько
хорошо приложение может оправиться от аварий
и сбоев оборудования.
39

40. Виды нефункционального тестирования:

•Тестирование локализации (Localization
Testing, l10n) — тестирования
локализованной версии приложения:
проверка правильности перевода интерфейса
пользователя, системных сообщений и
ошибок, документации.
Тестирование интернационализации
(Internationalization Testing, i18n) —
Насколько продукт может адаптироваться
при выходе на другие рынки. Например,
возможность поддержки вертикального текста
Азиатских стран, чтение справа налево в
арабских странах.
40

41. Методологии разработки ПО

41

42.

Жизненный цикл ПО (SDLC)
Жизненный цикл ПО (SDLC) – это период
времени, который начинается с возникновения идеи
продукта до прекращения его использования — вывода
из эксплуатации.
42

43.

Жизненный цикл ПО (SDLC)
Жизненный цикл программного обеспечения состоит из
последовательных этапов:
Анализ требований. На этом этапе составляется
ТЗ(Техническое задание – это документ,
содержащий информацию для постановки задач на
разработку), обозначаются сроки по каждой задаче и
план работ. Здесь также нужно учитывать все
возможные риски.
Дизайн системы. Разрабатывается прототип,
дизайн-макет, платформа для программирования.
Все члены команды должны быть расписаны по
ролям, а также необходимо указать их обязанности;
43

44.

Жизненный цикл ПО (SDLC)
Разработка. Команда пишет код продукта, согласно
требованиям технического задания;
Тестирование. Проверка продукта, когда код
написан. Если все благополучно, работу можно
считать практически законченной;
Техническая поддержка. После релиза продукта,
команда разработки поддерживает работу проекта на
стабильном уровне, собирая обратную связь от
пользователей и устраняя баги, если они возникают.
44

45.

Подходы к разработке софта
В разработке любого софта есть два подхода:
итеративный и непрерывный. Они отличаются
методами работы и сложностью организации.
При использовании итеративного подхода
заказчики или пользователи видят результат только в
самом конце этапа, а до этого пользуются старой
версией.
Непрерывный подход позволяет пользователям
каждый день получать новую версию, которую уже
можно использовать.
Непрерывный подход является самым популярным,
на сегодняшний день. Его описывает концепция
CI/CD (Continuous Integration, Continuous Delivery —
непрерывная интеграция и доставка) — это
45
автоматизация тестирования и доставки новых
модулей ПО конечным пользователям.

46.

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

47.

Подходы к разработке софта
СI/CD – это современная аналогия конвейерного
производства. Их объединяет четкое распределение
труда, непрерывный поток работы и параллельное
выполнение сразу нескольких задач.
CI/CD чаще всего зависит от тестировщиков и
девопсов (инженеров, которые следят, чтобы код
собирался быстро и не было отказов):
Тестировщики следят за тем, что новые изменения не
повлияли на качество продукта;
Девопсы автоматизируют процесс доставки ПО.
47

48.

Основные фазы тестирования
Pre-Alpha: прототип, в котором всё ещё
присутствует много ошибок и наверняка неполный
функционал. Необходим для ознакомления с
будущими возможностями программ.
Alpha: является ранней версией программного
продукта, тестирование которой проводится внутри
фирмы-разработчика.
Beta: практически готовый продукт, который
разработан в первую очередь для тестирования
конечными пользователями.
Release Candidate (RC): возможные ошибки в
каждой из фичей уже устранены и разработчики
выпускают версию на которой проводится
регрессионное тестирование.
48
Release: финальная версия программы, которая
готова к использованию.

49.

Тестовые среды
Среда разработки (Development Env) – за
данную среду отвечают разработчики, вней они
пишут код, проводят отладку, исправляют ошибки
Среда тестирования (Test Env) – среда, в
которой работают тестировщики (проверяют
функционал, проводят smoke и регрессионные
тесты).
Интеграционная среда (Integration Env) –
среда, в которой проводят тестирование
взаимодействующих друг с другом модулей, систем,
продуктов.
49

50.

Тестовые среды
Предпрод (Preprod Env) – среда, которая
максимально приближена к продакшену. Здесь
проводится заключительное тестирование
функционала.
Продакшн среда (Production Env) – среда, в
которой работают пользователи.
50

51. МОДЕЛИ РАЗРАБОТКИ

51

52.

Каскадная (водопадная (Waterfall))
52

53.

Каскадная (водопадная (Waterfall))
Базовым принципом является
последовательный порядок выполнения
задач. Это значит, что мы можем переходить к
следующему шагу разработки или тестирования
только после того, как предыдущий был успешно
завершен.
Каскадная модель будет давать отличный
результат только в проектах с четко и заранее
определенными требованиями и способами их
реализации. Нет возможности сделать шаг назад,
тестирование начинается только после того, как
разработка завершена или почти завершена.
53

54.

Каскадная (водопадная (Waterfall))
Когда использовать каскадную методологию?
Только тогда, когда требования известны, понятны
и зафиксированы. Противоречивых требований не
имеется.
Нет проблем с доступностью программистов нужной
квалификации.
В относительно небольших проектах.
54

55.

«V-Model (Модель верификации и
валидации)»
V-Model
основана
на
прямой
последовательности шагов, тестирование в
данном случае планируется параллельно с
соответствующей стадией разработки.
Согласно этой методологии тестирования ПО,
процесс начинается, как только определены
требования и становится возможным начать
статическое тестирование, т.е. верификацию и
обзор, что позволяет избежать возможных дефектов
ПО на поздних стадиях.
Соответствующий план тестирования создается
для каждого уровня разработки ПО, что определяет
ожидаемые результаты, а также критерии входа и 55
выхода для данного продукта.

56.

«V-Model (Модель верификации и
валидации)»
Верификация (verification) — это процесс
оценки системы, чтобы понять, удовлетворяют ли
результаты текущего этапа разработки условиям и
требованиям, которые были сформулированы в его
начале.
Валидация (validation) - это определение
итогового результата, соответствия, разрабатываемого
ПО ожиданиям и потребностям пользователя, его
требованиям к системе
Особенностью модели можно считать то, что она
направлена на тщательную проверку и тестирование
продукта, находящегося уже на первоначальных
стадиях проектирования.
56

57.

«V-Model»
Валидация
Верификация
57
Код

58.

Основные этапы методологии «V-Model»
Этап
определения требований. Приемочное
тестирование относится к этому этапу. Его основная
задача состоит в оценке готовности системы к
финальному использованию.
Этап высокоуровневого проектирования, или
High-Level Design (HDL). Этот этап относится к
системному тестированию и включает оценку
соблюдения
требований
к
интегрированным
системам.
Фаза
детального дизайна (Detailed Design)
параллельна фазе интеграционного тестирования, во
время которой происходит проверка взаимодействий
между различными компонентами системы.
Этап юнит-тестирования. Очень важно убедиться в
58
том, что поведение отдельных частей и компонентов
ПО
корректно
и
соответствует
требованиям.

59.

Инкрементная модель
Данная методология может быть описана, как
мультикаскадная модель тестирования ПО.
Рабочий процесс разделяется на некоторое
количество циклов, каждый из которых также
делится на модули. Каждая итерация добавляет
определенный функционал к ПО.
Инкремент состоит из трех циклов:
дизайн и разработка;
тестирование;
реализация.
59

60.

Инкрементная модель
В этой модели возможна одновременная
разработка разных версий продукта.
Например, первая версия может проходить
этап тестирования в то время, как вторая версия
находится на стадии разработки. Третья версия в то
же самое время может проходить этап дизайна. Этот
процесс может продолжаться до самого завершения
проекта
60

61.

61

62.

Спиральная модель
Спиральная модель — это методология тестирования
ПО, которая основана на инкрементном подходе и
прототипировании. Она состоит из четырех этапов:
Планирование;
Анализ рисков;
Разработка;
Оценка;
Сразу после того, как первый цикл завершен, начинается
второй. Тестирование ПО начинается еще на этапе
планирования и длится до стадии оценки.
62

63.

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

64.

64

65.

Методология Agile (SCRUM, KANBAN)
Методология гибкой (Agile) разработки и
тестирование ПО может быть описана как набор
подходов, ориентированных на использование
интерактивной разработки, динамического
формирования требований и обеспечения их
осуществления как результата постоянного
взаимодействия внутри самоорганизующейся рабочей
группы.
Большинство гибких методологий разработки ПО
нацелены на минимизацию рисков посредством
разработки в рамках коротких итераций. Одним из
главных принципов этой гибкой стратегии является
возможность быстрого реагирования на возможные
изменения, нежели стремление положиться на
65
долгосрочное планирование.

66.

Методология Agile (SCRUM, KANBAN)
66

67.

Методология Agile (SCRUM, KANBAN)
«SCRUM» - это процессный фреймворк,
предназначенный для быстрой разработки и поставки
сложных продуктов клиентам с максимально
возможной ценностью.
Процесс разработки разбивается на отдельные этапы,
результатом каждого из которых является готовый
продукт.
В конце каждого этапа (в терминологии Scrum —
спринта) готовый продукт предоставляется заказчику.
Полученный от заказчика отзыв позволяет выявить
возможные проблемы или пересмотреть некоторые
аспекты первоначального плана.
67

68.

Методология Agile (SCRUM, KANBAN)
68

69.

Жизненный цикл Scrum-проекта
69

70.

Жизненный цикл Scrum-проекта
Шаг 1. Создание бэклога продукта
Бэклог
продукта
(Product
backlog)
представляет собой упорядоченный по степени
важности список требований, предъявляемых к
разрабатываемому продукту.
Элементы
этого
списка
называются
Пользовательскими историями (User story
(описание
функциональной
возможности
ПО
простыми словами, составленное с точки зрения
пользователя)).
70

71.

Жизненный цикл Scrum-проекта
Шаг 1. Создание бэклога продукта
Каждой истории соответствует уникальный ID.
Описание каждой истории должно включать в себя
набор обязательных полей, необходимых для
дальнейшей работы над проектом:
Важность (Importance). Степень важности
задачи, по мнению владельца продукта.
Описывается произвольным числом.
Предварительная оценка (Initial estimate)
объема работ. Измеряется в story point’ах.
Как продемонстрировать (How to demo). Описание
способа демонстрации завершенной задачи.
71

72.

Жизненный цикл Scrum-проекта
Шаг 2. Планирование спринта и создание
Бэклога спринта
На
этапе
планирования
определяется
длительность спринта.
Короткий спринт позволяет чаще выпускать
работающие версии продукта, а, следовательно,
чаще получать отзывы от клиента и вовремя
выявлять возможные ошибки.
С
другой
стороны,
длинные
спринты
позволяют посвятить решению проблемы больше
времени. Оптимальная длина спринта выбирается
как нечто среднее между этими двумя решениями и
составляет обычно около 2-ух недель.
72

73.

Жизненный цикл Scrum-проекта
Шаг 2. Планирование спринта и создание
Бэклога спринта
На этом этапе важно взаимодействие владельца
продукта и скрам-команды. Владелец продукта
определяет приоритет той или иной задачи, а
задача скрам-команды состоит в определении
необходимых трудозатрат.
Во время планирования спринта команда
выбирает самые приоритетные пользовательские
истории из бэклога продукта и решает, каким
образом будут решаться поставленные задачи.
73

74.

Жизненный цикл Scrum-проекта
Шаг 3. Работа над спринтом. Scrum meetings
После того, как определены актуальные для
данного
спринта
пользовательские
истории,
начинается процесс разработки.
Важной отличительной особенностью Scrum
являются
ежедневные
совещания
(Scrum
meetings), целью которых является дать команде
полную и достоверную информацию о том, на каком
этапе находится процесс разработки. Во время
совещания
каждый
участник
скрам-команды
сообщает о том, какая задача им выполнена, какая
будет выполняться и какие у него возникли
трудности во время работы.
74

75.

Жизненный цикл Scrum-проекта
Шаг 4. Тестирование и демонстрация
продукта
Поскольку в идеале результатом каждого
спринта является продукт, готовый к работе, важное
место в Scrum занимает процесс тестирования.
Финал каждого спринта — демонстрация
готового продукта.
Скрам-команда составляет ревью, в котором
описывает цели спринта, поставленные задачи и то,
как они были решены. Владелец продукта,
заказчики и пользователи на основе ревью и
демонстрации принимают решение о том, что
должно быть изменено в дальнейшем процессе 75
разработки.

76.

Жизненный цикл Scrum-проекта
Шаг
5.
Ретроспектива.
Планирование
следующего спринта
На основе отзыва о продукте, полученного после
демонстрации, проводится ретроспектива.
Ее основная цель — определить, как можно
улучшить процесс разработки на следующем
спринте, чтобы избежать возникших проблем и
работать более эффективно.
После того, как пути улучшения качества работы
были определены, команда может приступать к
планированию следующего спринта.
76

77.

Методология Agile (SCRUM, KANBAN)
«KANBAN» стал символом визуализации рабочего
процесса (карточки на стенде).
Также может быть использовано программное
обеспечение, предназначенное для такого рода задач.
Примером такого ПО может служить, например,
Atlassian JIRA.
KANBAN метод, демонстрирующий, что
происходит в процессе работы, увеличивающий
предсказуемость процедур, благодаря чему рабочий
процесс становится прозрачным и равномерным.
Kanban также можно использовать, чтобы достичь
большей согласованности действий, а это означает
более быстрое достижение стратегических целей.
77

78.

78