Тестирование программного обеспечения. Базовый курс. 3-е издание
жүктеу/скачать 5,03 Mb. Pdf көрінісі
|
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 кг конфет — и всё»), поездка совершена, все деньги потрачены, конфеты привезены и только тут выясняется, что «ну мы же пошутили». жүктеу/скачать 5,03 Mb. Достарыңызбен бөлісу:
|