Тестирование программного обеспечения. Базовый курс. 3-е издание



Pdf көрінісі
бет37/307
Дата03.07.2023
өлшемі5,03 Mb.
#179304
1   ...   33   34   35   36   37   38   39   40   ...   307
Байланысты:
Software Testing - Base Course (Svyatoslav Kulikov) - 3rd edition - RU

 
Стр: 33/301 
2.2.2. 
Важность требований 
Требования являются отправной точкой для определения того, что проектная 
команда будет проектировать, реализовывать и тестировать. Элементарная логика 
говорит нам, что если в требованиях что-то «не то», то и реализовано будет «не 
то», т.е. колоссальная работа множества людей будет выполнена впустую. Эту 
мысль иллюстрирует рисунок 2.2.a. 
Брайан Хэнкс, описывая важность требований
52
, подчёркивает, что они: 

Позволяют понять, что и с соблюдением каких условий система должна де-
лать. 

Предоставляют возможность оценить масштаб изменений и управлять изме-
нениями. 

Являются основой для формирования плана проекта (в том числе плана те-
стирования). 

Помогают предотвращать или разрешать конфликтные ситуации. 

Упрощают расстановку приоритетов в наборе задач. 

Позволяют объективно оценить степень прогресса в разработке проекта. 
Вне зависимости от того, какая модель разработки ПО используется на про-
екте, чем позже будет обнаружена проблема, тем сложнее и дороже будет её ре-
шение. А в самом начале («водопада», «спуска по букве v», «итерации», «витка 
спирали») идёт планирование и работа с требованиями. 
Если проблема в требованиях будет выяснена на этой стадии, её решение 
может свестись к исправлению пары слов в тексте, в то время как недоработка
вызванная пропущенной проблемой в требованиях и обнаруженная на стадии экс-
плуатации, может даже полностью уничтожить проект. 
 
Рисунок 2.2.a — Стоимость исправления ошибки в зависимости от момента её об-
наружения 
Если графики вас не убеждают, попробуем проиллюстрировать ту же мысль 
на простом примере. Допустим, вы с друзьями составляете список покупок перед 
поездкой в гипермаркет. Вы поедете покупать, а друзья ждут вас дома. Сколько 
52
«Requirements in the Real World», Brian F. Hanks, February 28, 2002. 
Общее 
планирование
Пользовательские 
требования
Системные 
требования
Техническая 
архитектура
Детализированный 
дизайн
Разработка и 
отладка
Интеграция и 
модульные тесты
Инсталляционное 
тестирование
Системное 
тестирование
Приёмочное 
тестирование
Итоговая 
отчётность
0
20
500
1000
Эксплуатация
Время, 
затраченное 
на проект
Стоимость 
исправления 
ошибки


Важность требований
Тестирование программного обеспечения. Базовый курс. 
© EPAM Systems, 2015–2023
 
Стр: 34/301 
«стоит» дописать, вычеркнуть или изменить пару пунктов, пока вы только-только 
составляете список? Нисколько. Если мысль о несовершенстве списка настигла вас 
по пути в гипермаркет, уже придётся звонить (дёшево, но не бесплатно). Если вы 
поняли, что в списке «что-то не то» в очереди на кассу, придётся возвращаться в 
торговый зал и тратить время. Если проблема выяснилась по пути домой или даже 
дома, придётся вернуться в гипермаркет. И, наконец, клинический случай: в списке 
изначально было что-то уж совсем неправильное (например, «100 кг конфет — и 
всё»), поездка совершена, все деньги потрачены, конфеты привезены и только тут 
выясняется, что «ну мы же пошутили». 


Достарыңызбен бөлісу:
1   ...   33   34   35   36   37   38   39   40   ...   307




©engime.org 2024
әкімшілігінің қараңыз

    Басты бет