Раздел 2: основные знания и умения
2.1.
Процессы тестирования и разработки ПО
2.1.1.
Модели разработки ПО
Чтобы лучше разобраться в том, как тестирование соотносится с программи- рованием и иными видами проектной деятельности, для начала рассмотрим самые основы — модели разработки (lifecycle model
16
)
ПО (как часть жизненного цикла
(software lifecycle
17
)
ПО). При этом сразу подчеркнём, что разработка ПО является лишь частью жизненного цикла ПО, и здесь мы говорим именно о разработке.
Материал данной главы относится скорее к дисциплине «управление проек- тами», потому здесь рассмотрен крайне сжато: пожалуйста, не воспринимайте его как исчерпывающее руководство — здесь едва ли рассмотрена и сотая доля про- цента соответствующей предметной области.
Модель разработки ПО (Software Development Model, SDM) — структура, систематизирующая различные виды проектной деятельности, их взаимо- действие и последовательность в процессе разработки ПО. Выбор той или иной модели зависит от масштаба и сложности проекта, предметной области, доступных ресурсов и множества других факторов.
Выбор модели разработки ПО серьёзно влияет на процесс тестирования, определяя выбор стратегии, расписание, необходимые ресурсы и т.д.
Моделей разработки ПО много, но в общем случае классическими можно считать водопадную, v-образную, итерационную инкрементальную, спиральную и гибкую.
Перечень моделей разработки ПО (с кратким описанием), рекомендуе- мых к изучению тестировщиками, можно найти в статье «What are the
Software Development Models?
»
18
Знать и понимать модели разработки ПО нужно затем, чтобы уже с первых дней работы осознавать, что происходит вокруг, что, зачем и почему вы делаете.
Многие начинающие тестировщики отмечают, что ощущение бессмысленности происходящего посещает их, даже если текущие задания интересны. Чем полнее вы будете представлять картину происходящего на проекте, тем яснее вам будет виден ваш собственный вклад в общее дело и смысл того, чем вы занимаетесь.
Ещё одна важная вещь, которую следует понимать, состоит в том, что ника- кая модель не является догмой или универсальным решением. Нет идеальной мо- дели. Есть та, которая хуже или лучше подходит для конкретного проекта, конкрет- ной команды, конкретных условий.
Частая ошибка! Единственное, от чего стоит предостеречь уже сейчас, так это от фривольной трактовки модели и перекраивания её «на свой вкус» без кристально чёткого понимания, что и зачем вы делаете. О том, что бывает при нарушении логики модели, прекрасно сказал в своём слайдка- сте «Scrum Tailoring»
19
Максим Дорофеев.
16
Lifecycle model. A partitioning of the life of a product or project into phases. [ISTQB Glossary]
17
Software lifecycle. The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The software lifecycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase. Note these phases may overlap or be performed iteratively. [ISTQB Glossary]
18
«What are the Software Development Models?» [
http://istqbexamcertification.com/what-are-the-software-development-models/
]
19
«Scrum Tailoring», Максим Дорофеев [
http://cartmendum.livejournal.com/10862.html
]
Модели разработки ПО
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2022
Стр: 19/298
Водопадная модель (waterfall model
20
) сейчас представляет скорее истори- ческий интерес, т.к. в современных проектах практически неприменима. Она пред- полагает однократное выполнение каждой из фаз проекта, которые, в свою оче- редь, строго следуют друг за другом (рисунок 2.1.a). Очень упрощённо можно ска- зать, что в рамках этой модели в любой момент времени команде «видна» лишь предыдущая и следующая фаза. В реальной же разработке ПО приходится «видеть весь проект целиком» и возвращаться к предыдущим фазам, чтобы исправить недоработки или что-то уточнить.
Рисунок 2.1.a — Водопадная модель разработки ПО
К недостаткам водопадной модели принято относить тот факт, что участие пользователей ПО в ней либо не предусмотрено вообще, либо предусмотрено лишь косвенно на стадии однократного сбора требований. С точки зрения же тести- рования эта модель плоха тем, что тестирование в явном виде появляется здесь лишь с середины развития проекта, достигая своего максимума в самом конце.
20
In a
waterfall model, each phase must be completed fully before the next phase can begin. This type of model is basically used for the project which is small and there are no uncertain requirements. At the end of each phase, a review takes place to deter- mine if the project is on the right path and whether or not to continue or discard the project. [
http://istqbexamcertifica- tion.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/
]
Общее планирование
Тестирование в явном виде
появляется лишь с середины развития проекта, достигая своего максимума в самом конце.
Пользовательские требования
Системные требования
Техническая архитектура
Детализированный дизайн
Разработка и отладка
Интеграция и модульные тесты
Инсталляционное тестирование
Системное тестирование
Приёмочное тестирование
Итоговая отчётность
Модели разработки ПО
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2022
Стр: 20/298
Тем не менее водопадная модель часто интуитивно применяется при выпол- нении относительно простых задач, а её недостатки послужили прекрасным отправ- ным пунктом для создания новых моделей. Также эта модель в несколько усовер- шенствованном виде используется на крупных проектах, в которых требования очень стабильны и могут быть хорошо сформулированы в начале проекта (аэро- космическая область, медицинское ПО и т.д.).
Относительно краткое и притом хорошее описание водопадной модели можно найти в статье «What is Waterfall model advantages, disadvantages and when to use it?
»
21
Великолепное описание истории развития и заката водопадной модели было создано Максимом Дорофеевым в виде слайдкаста «The Rise And
Fall Of Waterfall
», который можно посмотреть
22
в его ЖЖ.
V-образная модель (V-model
23
) является логическим развитием водопад- ной. Можно заметить (рисунок 2.1.b), что в общем случае как водопадная, так и v- образная модели жизненного цикла ПО могут содержать один и тот же набор ста- дий, но принципиальное отличие заключается в том, как эта информация исполь- зуется в процессе реализации проекта.
Очень упрощённо можно сказать, что при использовании v-образной модели на каждой стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей стадии «на подъёме». Тестирование здесь появляется уже на са- мых ранних стадиях развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить
множество потенциальных проблем до того, как они станут проблемами реальными.
Рисунок 2.1.b — V-образная модель разработки ПО
21
«What is Waterfall model advantages, disadvantages and when to use it?» [
http://istqbexamcertification.com/what-is-waterfall- model-advantages-disadvantages-and-when-to-use-it/
]
22
ЖЖ Максима Дорофеева. [
http://cartmendum.livejournal.com/44064.html
]
23
V-model. A framework to describe the software development lifecycle activities from requirements specification to maintenance.
The V-model illustrates how testing activities can be integrated into each phase of the software development lifecycle. [ISTQB
Glossary]
Общее планирование
Пользовательские требования
Системные требования
Техническая архитектура
Детализированный дизайн
Разработка и отладка
Интеграция и модульные тесты
Инсталляционное тестирование
Системное тестирование
Приёмочное тестирование
Итоговая отчётность
Тестирование появляется с самого начала проекта.
Модели разработки ПО
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2022
Стр: 21/298
Краткое описание v-образной модели можно найти в статье «What is V- model advantages, disadvantages and when to use it?
»
24
Пояснение по ис- пользованию v-образной модели в тестировании можно найти в статье
«Using V Models for Testing»
25
Итерационная инкрементальная модель (iterative model
26
, incremental model
27
) является фундаментальной основой современного подхода к разработке
ПО. Как следует из названия модели, ей свойственна определённая двойствен- ность (а ISTQB-глоссарий даже не приводит единого определения, разбивая его на отдельные части):
• с точки зрения жизненного цикла модель является итерационной, т.к. под- разумевает многократное повторение одних и тех же стадий;
• с точки зрения развития продукта (приращения его полезных функций) мо- дель является инкрементальной.
Ключевой особенностью данной модели является разбиение проекта на от- носительно небольшие промежутки (итерации), каждый из которых в общем случае может включать в себя все классические стадии, присущие водопадной и v- образной моделям (рисунок 2.1.c). Итогом итерации является приращение (инкре- мент) функциональности продукта, выраженное в промежуточном билде (build
28
).
Рисунок 2.1.c — Итерационная инкрементальная модель разработки ПО
24
«What is V-model advantages, disadvantages and when to use it?» [
http://istqbexamcertification.com/what-is-v-model-advantages- disadvantages-and-when-to-use-it/
]
25
«Using V Models for Testing», Donald Firesmith [
https://insights.sei.cmu.edu/sei_blog/2013/11/using-v-models-for-testing.html
]
26
Iterative development model. A development lifecycle where a project is broken into a usually large number of iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows from iteration to iteration to become the final product. [ISTQB Glossary]
27
Incremental development model. A development lifecycle where a project is broken into a series of increments, each of which delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered in priority order in the appropriate increment. In some (but not all) versions of this lifecycle model, each subproject follows a 'mini V-model' with its own design, coding and testing phases. [ISTQB Glossary]
28
Build. A development activity whereby a complete system is compiled and linked, so that a consistent system is available including all latest changes. [
На основе определения термина «daily build» из ISTQB Glossary]
Общее планирование
Планирование + требования
Архитектура и дизайн
Разработка и отладка
Интеграция и модульные тесты
Установка билда
Тестирование
Оценка результатов
Итоговая отчётность
Отчётность
Модели разработки ПО
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2022
Стр: 22/298
Длина итераций может меняться в зависимости от множества факторов, од- нако сам принцип многократного повторения позволяет гарантировать, что и тести- рование, и демонстрация продукта конечному заказчику (с получением обратной связи) будет активно применяться с самого начала и на протяжении всего времени разработки проекта.
Во многих случаях допускается распараллеливание отдельных стадий внутри итерации и
активная доработка с целью устранения недостатков, обнару- женных на любой из (предыдущих) стадий.
Итерационная инкрементальная модель очень хорошо зарекомендовала себя на объёмных и сложных проектах, выполняемых большими командами на про- тяжении длительных сроков. Однако к основным недостаткам этой модели часто относят высокие накладные расходы, вызванные высокой «бюрократизированно- стью» и общей громоздкостью модели.
Относительно краткие и очень хорошие описания итерационной инкре- ментальной модели можно найти в статьях «What is Iterative model ad- vantages, disadvantages and when to use it?
»
29
и «What is Incremental model advantages, disadvantages and when to use it?
»
30
Спиральная модель (spiral model
31
) представляет собой частный случай итерационной инкрементальной модели, в котором особое внимание уделяется управлению рисками, в особенности влияющими на организацию процесса разра- ботки проекта и контрольные точки.
Схематично суть спиральной модели представлена на рисунке 2.1.d. Обра- тите внимание на то, что здесь явно выделены четыре ключевые фазы:
• проработка целей, альтернатив и ограничений;
• анализ рисков и прототипирование;
• разработка (промежуточной версии) продукта;
• планирование следующего цикла.
С точки зрения тестирования и управления качеством повышенное внимание рискам является ощутимым преимуществом при использовании спиральной мо- дели для разработки концептуальных проектов, в которых требования естествен- ным образом являются сложными и нестабильными (могут многократно меняться по ходу выполнения проекта).
Автор модели Barry Boehm в своих публикациях
32
,
33
подробно раскрывает эти вопросы и приводит множество рассуждений и рекомендаций о том, как применять спиральную модель с максимальным эффектом.
Относительно краткие и очень хорошие описания спиральной модели можно найти в статьях «What is Spiral model - advantages, disadvantages and when to use it?
»
34
и «Spiral Model»
35 29
«What is Iterative model advantages, disadvantages and when to use it?» [
http://istqbexamcertification.com/what-is-iterative- model-advantages-disadvantages-and-when-to-use-it/
]
30
«What is Incremental model advantages, disadvantages and when to use it?» [
http://istqbexamcertification.com/what-is-incremen- tal-model-advantages-disadvantages-and-when-to-use-it/
]
31
Spiral model. A software lifecycle model which supposes incremental development, using the waterfall model for each step, with the aim of managing risk. In the spiral model, developers define and implement features in order of decreasing priority.
[
https://www.geeksforgeeks.org/software-engineering-spiral-model/
]
32
«A Spiral Model of Software Development and Enhancement», Barry Boehm [
http://www-scf.usc.edu/csci201/lectures/Lec- ture11/boehm1988.pdf
]
33
«Spiral Development: Experience, Principles, and Refinements», Barry Boehm. [
http://www.sei.cmu.edu/reports/00sr008.pdf
]
34
«What is Spiral model- advantages, disadvantages and when to use it?» [
http://istqbexamcertification.com/what-is-spiral-model- advantages-disadvantages-and-when-to-use-it/
]
35
«Spiral Model» [
https://searchsoftwarequality.techtarget.com/definition/spiral-model
]
Модели разработки ПО
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2022
Стр: 23/298
Рисунок 2.1.d — Спиральная модель разработки ПО
Гибкая модель (agile model
36
) представляет собой совокупность различных подходов к разработке ПО и базируется на т.н. «agile-манифесте»
37
:
• Люди и взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Готовность к изменениям важнее следования первоначальному плану.
Данная тема является настолько большой, что
ссылок на статьи недоста- точно, а потому стоит почитать эти книги:
• «Agile Testing» (Lisa Crispin, Janet Gregory).
• «Essential Scrum» (Kenneth S. Rubin).
36
Agile software development. A group of software development methodologies based on EITP iterative incremental development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. [ISTQB Glos- sary]
37
«Agile-манифест» [
http://agilemanifesto.org/iso/ru/manifesto.html
]
Проработка целей, альтернатив и ограничений
Проектных
Продуктных
Жизненного цикла проекта
Процесса разработки проекта
Эксплуа- тации продукта
Анализ рисков и прототипирование
Разработка
(
промежуточной версии) продукта
Планирование следующего цикла
Проекта и продукта
Жизненного цикла
Разработки, интеграции и тестирования
Внедрения и сопровождения
Общей концепции
Уточнённых требований
Архитектуры
Дизайна
Детализация
Кодирование
Интеграция
Тестирование
Детализация
Кодирование
Интеграция
Тестирование
Оценка промежуточных результатов
Н
а ра ст ани е об щ
ей ц
ен но ст и пр од ук та
Модели разработки ПО
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2022
Стр: 24/298
Как несложно догадаться, положенные в основу гибкой модели подходы яв- ляются логическим развитием и продолжением всего того, что было за десятилетия создано и опробовано в водопадной, v-образной, итерационной инкрементальной, спиральной и иных моделях. Причём здесь впервые был достигнут ощутимый ре- зультат в снижении бюрократической составляющей и максимальной адаптации процесса разработки ПО к мгновенным изменениям рынка и требований заказчика.
Рисунок 2.1.e — Суть гибкой модели разработки ПО
Очень упрощённо (почти на грани допустимого) можно сказать, что гибкая модель представляет собой облегчённую с точки зрения документации смесь ите- рационной инкрементальной и спиральной моделей (рисунки 2.1.c и 2.1.d); при этом следует помнить об «agile-манифесте» и всех вытекающих из него преимуществах и недостатках.
Ценности
СТРАТЕГИЯ
ВЫПУСК
ИТЕРАЦИЯ
ЕЖЕДНЕВНО
НЕПРЕРЫВНО
TDD
Билд
Рефакторинг
Интеграция
Сотрудничество
Билд
«Стендап» собрание
Тестирование
Планирование
Оценка
Ретроспектива
«Бэклог»
План выпуска
Оценка
Видение
Цели
Соглашения
Бюджет
Адаптивность
Прозрачность
Простота
Единство
Наглядность
Осталось сделать
Производительность
Сделано
Тесты
Модели разработки ПО
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2022
Стр: 25/298
Рисунок 2.1.f — Итерационный подход в рамках гибкой модели и scrum
Главным недостатком гибкой модели считается сложность её применения к крупным проектам, а также частое ошибочное внедрение её подходов, вызванное недопониманием фундаментальных принципов модели.
Тем не
менее можно утверждать, что всё больше и больше проектов начи- нают использовать гибкую модель разработки.
Очень подробное и элегантное изложение принципов применения гибкой модели разработки ПО можно найти в статье «The Agile System Develop- ment Life Cycle
»
38
Скачать 5.07 Mb.