Модели разработки ПО
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 25/301
Рисунок 2.1.f — Итерационный подход в рамках гибкой модели и scrum
Главным недостатком гибкой модели считается сложность её применения к
крупным проектам, а также частое ошибочное внедрение её подходов, вызванное
недопониманием фундаментальных принципов модели.
Тем не менее можно утверждать, что всё больше и больше проектов начи-
нают использовать гибкую модель разработки.
Очень подробное и элегантное изложение принципов применения гибкой
модели разработки ПО можно найти в статье «The Agile System Develop-
ment Life Cycle
»
38
.
Вкратце
можно выразить суть моделей разработки ПО таблицей 2.1.a.
Таблица 2.1.a — Сравнение моделей разработки ПО
Модель
Преимущества
Недостатки
Тестирование
Водопадная
•
У каждой стадии
есть чёткий прове-
ряемый результат.
•
В каждый момент
времени команда
выполняет один
вид работы.
•
Хорошо
работает
для небольших за-
дач.
•
Полная неспособ-
ность адаптировать
проект к измене-
ниям в требова-
ниях.
•
Крайне позднее со-
здание работаю-
щего продукта.
•
С
середины про-
екта.
V-
образная
•
У каждой стадии
есть чёткий прове-
ряемый результат.
•
Внимание тестиро-
ванию уделяется с
первой же стадии.
•
Хорошо работает
для проектов со
стабильными тре-
бованиями.
•
Недостаточная гиб-
кость и адаптируе-
мость.
•
Отсутствует
раннее
прототипирование.
•
Сложность устра-
нения проблем,
пропущенных на
ранних стадиях
развития проекта.
•
На переходах
между стадиями.
38
«The Agile System Development Life Cycle» [
http://www.ambysoft.com/essays/agileLifecycle.html
]
«Бэклог»
проекта
«Бэклог»
спринта
Спринт (до 4-х
недель)
Результат
Итерация
(
сутки)
Модели разработки ПО
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 26/301
Итерационная инкре-
ментальная
•
Достаточно раннее
прототипирование.
•
Простота управле-
ния итерациями.
•
Декомпозиция про-
екта на управляе-
мые итерации.
•
Недостаточная гиб-
кость внутри итера-
ций.
•
Сложность устра-
нения проблем,
пропущенных на
ранних стадиях
развития проекта.
•
В определённые
моменты итераций.
•
Повторное тестиро-
вание (после дора-
ботки) уже прове-
ренного ранее.
Спиральная
•
Глубокий анализ
рисков.
•
Подходит для круп-
ных проектов.
•
Достаточно раннее
прототипирование.
•
Высокие накладные
расходы.
•
Сложность приме-
нения для неболь-
ших проектов.
•
Высокая зависи-
мость успеха от ка-
чества анализа
рисков.
Гибкая
•
Максимальное во-
влечение
заказ-
чика.
•
Много работы с
требованиями.
•
Тесная интеграция
тестирования и
разработки.
•
Минимизация доку-
ментации.
•
Сложность реали-
зации для
больших
проектов.
•
Сложность постро-
ения стабильных
процессов.
•
В определённые
моменты итераций
и
в любой необхо-
димый момент
.
Ещё два кратких и информативных сравнения моделей жизненного цикла
ПО можно найти в статьях «Project Lifecycle Models: How They Differ and
When to Use Them
»
39
и «Блок-схема выбора
оптимальной методологии
разработки ПО»
40
.
А общий обзор всех моделей в контексте тестирования
ПО представлен в статье «What are the Software Development Models?»
41
.
Задание 2.1.a:
представьте, что на собеседовании вас попросили назвать
основные модели разработки ПО, перечислить их преимущества и недо-
статки с точки зрения тестирования. Не ждите собеседования, ответьте на
этот вопрос сейчас, а ответ запишите.
39
«Project Lifecycle Models: How They Differ and When to Use Them» [
http://www.business-esolutions.com/islm.htm
]
40
«Блок-схема выбора оптимальной методологии разработки ПО» [
http://megamozg.ru/post/23022/
]
41
«What are the Software Development Models?» [
http://istqbexamcertification.com/what-are-the-software-development-models/
]
Жизненный цикл тестирования
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 27/301
2.1.2.
Жизненный цикл тестирования
Следуя общей логике итеративности, превалирующей во всех современных
моделях разработки ПО, жизненный цикл тестирования также выражается замкну-
той последовательностью действий (рисунок 2.1.g).
Важно понимать, что длина такой итерации (и, соответственно, степень по-
дробности каждой стадии) может варьироваться в широчайшем диапазоне — от
единиц часов до десятков месяцев. Как правило, если речь идёт о длительном про-
межутке времени, он разбивается на множество относительно коротких итераций,
но сам при этом «тяготеет» к той или иной стадии в каждый момент времени (напри-
мер, в начале проекта больше планирования, в конце — больше отчётности).
Также ещё раз подчеркнём, что приведённая схема — не догма, и вы легко
можете найти альтернативы (например, здесь
42
и здесь
43
), но общая суть и ключе-
вые принципы остаются неизменными. Их и рассмотрим.
Рисунок 2.1.g — Жизненный цикл тестирования
Стадия 1
(общее планирование и анализ требований) объективно необхо-
дима как минимум для того, чтобы иметь ответ на такие вопросы, как: что нам пред-
стоит тестировать; как много будет работы; какие есть сложности; всё ли необхо-
димое у нас есть и т.п. Как правило, получить ответы на эти вопросы невозможно
без анализа требований, т.к. именно требования являются первичным источником
ответов.
Стадия 2
(уточнение критериев приёмки) позволяет
сформулировать или
уточнить метрики и признаки возможности или необходимости начала тестирова-
ния (entry criteria
44
)
, приостановки (suspension criteria
45
)
и возобновления (resumption
42
«Software Testing Life Cycle» [
http://softwaretestingfundamentals.com/software-testing-life-cycle/
]
43
«Software Testing Life Cycle» [
http://www.softwaretestingmentor.com/software-testing-life-cycle/
]
44
Entry criteria.
The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. test phase.
The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort
needed to remove the failed entry criteria. [ISTQB Glossary]
45
Достарыңызбен бөлісу: