Отсутствие дефектов — не самоцель
Представьте, что вы купили кому-то апельсин. Идеальный. Самый лучший в
мире. Достойный стать эталоном апельсинов на все времена. Но тот, кому вы по-
купали этот апельсин, разочарован — он ведь просил грейпфрут.
Так и программный продукт должен не только быть избавлен от дефектов
настолько, насколько это возможно, но и удовлетворять требованиям заказчика и
конечных пользователей — в противном случае он станет непригодным для исполь-
зования.
Стоит отметить, что нередко нарушение данного принципа заключается в не-
достаточной проработке и реализации нефункциональных требований
{41}
к про-
дукту, что влечёт за собой справедливую критику со стороны конечных пользовате-
лей и общее падение популярности продукта.
Если объединить этот принцип с предыдущим, получается: именно понима-
ние контекста продукта и потребностей пользователей позволяет тестировщикам
выбрать наилучшую стратегию и добиться наилучшего результата.
Несмотря на то, что данные принципы тестирования сами по себе не явля-
ются магической гарантией успеха, их понимание должно позволить вам лучше вос-
принять и усвоить представленный далее материал.
Тестирование документации и требований
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 32/301
2.2.
Тестирование документации и требований
2.2.1.
Что такое «требование»
Как мы только что рассмотрели в главе, посвящённой жизненному циклу те-
стирования, всё так или иначе начинается с документации и требований.
Требование
(requirement
50
)
— описание того, какие функции и с соблюде-
нием каких условий должно выполнять приложение в процессе решения
полезной для пользователя задачи.
Небольшое «историческое отступление»: если поискать определения тре-
бований в литературе 10-20-30-летней давности, то можно заметить, что
изначально о пользователях, их задачах и полезных для них свойствах
приложения в определении требования не было сказано. Пользователь
выступал некоей абстрактной фигурой, не имеющей отношения к прило-
жению. В настоящее время такой подход недопустим, т.к. он не только
приводит к коммерческому провалу продукта на рынке, но и многократно
повышает затраты на разработку и тестирование.
Хорошим кратким предисловием ко всему тому, что будет рассмотрено в
данной главе, можно считать небольшую статью «What is documentation
testing in software testing
»
51
.
50
Requirement.
A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed
by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. [ISTQB
glossary]
51
«What is documentation testing in software testing». [
http://istqbexamcertification.com/what-is-documentation-testing/
]
Важность требований
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Достарыңызбен бөлісу: |