3 мая 2021
24161
В статье использованы материалы книги «Foundations of Software Testing: ISTQB Certification» by Dorothy Graham, Erik van Veenendaal, Isabel Evans & Rex Black. О 7 принципах тестирования пишут часто, но обычно довольно сжато. Дороти Грэхем и соавторы в своей замечательной книге объясняют эти основополагающие принципы весьма детально.
В статье использованы материалы книги «Foundations of Software Testing: ISTQB Certification» by Dorothy Graham, Erik van Veenendaal, Isabel Evans & Rex Black.
О 7 принципах тестирования пишут часто, но обычно довольно сжато. Дороти Грэхем и соавторы в своей замечательной книге объясняют эти основополагающие принципы весьма детально.
Принцип 1. Тестирование показывает наличие дефектов
Тестирование может показать, что дефекты присутствуют, но не может доказать, что дефектов нет.
Доказать, что чего-то нет, в принципе затруднительно. Сколько бы белых лебедей мы ни видели, это еще не служит основанием утверждать, что «все лебеди белые». Но если мы увидим хотя бы одного черного лебедя, мы может сказать, что «не все лебеди белые».
Сколько бы успешных тестов вы не провели, вы не можете утверждать, что нет таких тестов, которые не нашли бы ошибку. Но если мы нашли хотя бы один дефект, мы уже можем утверждать, что в данном ПО присутствуют дефекты.
Впрочем, это отнюдь не означает, что тестирование бесполезно и не может повысить наш уровень уверенности в качестве ПО. Тестирование уменьшает вероятность необнаруженных дефектов, которые остаются в ПО, но всегда нужно помнить, что даже если дефекты не найдены, это еще не доказательство того, что их нет.
Принцип 2. Исчерпывающее тестирование невозможно
Этот принцип связан с вопросом: «сколько нужно тестировать?».
Какие вообще могут быть ответы на этот вопрос? Мы можем протестировать всё, ничего не тестировать или протестировать какую-то часть. Идеальным вариантом выглядит «протестировать всё», но стоит разобраться, должны ли мы и можем ли вообще это сделать.
Сколько тестов нужно выполнить, чтобы полностью протестировать поле ввода, принимающее одну цифру? Зависит от того, что мы понимаем под словом «полностью». Есть 10 возможных валидных значений, но, кроме того, надо еще убедиться, что невалидные значения правильно обрабатываются. 26 заглавных латинских букв, 26 строчных букв, не менее 6 знаков пунктуации и пробел… Уже 68, а это мы еще не вспомнили о кириллице, спецсимволах и тому подобном.
Если мы посмотрим на более реалистичный пример, то всё ещё хуже. На практике, системы обычно имеют более одного поля ввода и поля эти имеют разный размер. А еще есть различные окружения, на которых нужно выполнить тесты… Если мы возьмем для примера один скрин, на котором 15 полей ввода, каждое из которых принимает 5 значений, то чтобы протестировать все валидные комбинации ввода, нам понадобится 30 517 578 125 (5 в 15-й степени) тестов. Очень маловероятно, что это уложится во временные рамки вашего проекта.
Помните сказку о волшебном горшочке с кашей, который наварил ее столько, что залил целый город? Так вот, наш «горшочек» может варить очень-очень долго, почти бесконечно, и когда-то нам надо сказать: «Стоп! Горшочек, не вари!».
Используя технику классов эквивалентности, мы можем сократить число наших тестов, ведь тестирование нашего поля ввода, принимающего одну цифру, при помощи значений 2, 3, 4 не дает нам больше информации, чем если бы мы протестировали только со значением 3.
Объем тестирования в реальной жизни ограничен временными рамками и бюджетом, в то же время существует необходимость поставить техническое решение, которое отвечает требованиям заказчика. Заказчики и руководители проекта хотят возврата инвестиций (ROI) от времени, потраченного на тестирование (время – деньги). Например, предотвратить появление ошибок после релиза – исправлять их всегда дорого. Но полное тестирование они просто не могут себе позволить – даже если очень хочется…
Вместо попыток «протестировать всё» нам нужен некий подход к тестированию (стратегия), который обеспечит правильный объем тестирования для данного проекта, данных заказчиков (и других заинтересованных лиц) и данного продукта. При определении, какой объем тестирования достаточен, необходимо учитывать уровень риска, включая технические риски и риски, связанные с бизнесом, и такие ограничения проекта как время и бюджет. Оценка и управление рисками – одна из наиболее важных активностей в любом проекте. Это позволяет варьировать трудозатраты на тестирование, основываясь на уровне риска в различных областях.
Кроме того, тестирование должно обеспечивать необходимую информацию, чтобы заинтересованные лица могли принимать информированные решения о релизе продукта или передаче заказчикам.
Продолжение статьи.
Курсы по тестированию ПО.
О 7 принципах тестирования пишут часто, но обычно довольно сжато. Дороти Грэхем и соавторы в своей замечательной книге объясняют эти основополагающие принципы весьма детально.
Принцип 1. Тестирование показывает наличие дефектов
Тестирование может показать, что дефекты присутствуют, но не может доказать, что дефектов нет.
Доказать, что чего-то нет, в принципе затруднительно. Сколько бы белых лебедей мы ни видели, это еще не служит основанием утверждать, что «все лебеди белые». Но если мы увидим хотя бы одного черного лебедя, мы может сказать, что «не все лебеди белые».
Сколько бы успешных тестов вы не провели, вы не можете утверждать, что нет таких тестов, которые не нашли бы ошибку. Но если мы нашли хотя бы один дефект, мы уже можем утверждать, что в данном ПО присутствуют дефекты.
Впрочем, это отнюдь не означает, что тестирование бесполезно и не может повысить наш уровень уверенности в качестве ПО. Тестирование уменьшает вероятность необнаруженных дефектов, которые остаются в ПО, но всегда нужно помнить, что даже если дефекты не найдены, это еще не доказательство того, что их нет.
Принцип 2. Исчерпывающее тестирование невозможно
Этот принцип связан с вопросом: «сколько нужно тестировать?».
Какие вообще могут быть ответы на этот вопрос? Мы можем протестировать всё, ничего не тестировать или протестировать какую-то часть. Идеальным вариантом выглядит «протестировать всё», но стоит разобраться, должны ли мы и можем ли вообще это сделать.
Сколько тестов нужно выполнить, чтобы полностью протестировать поле ввода, принимающее одну цифру? Зависит от того, что мы понимаем под словом «полностью». Есть 10 возможных валидных значений, но, кроме того, надо еще убедиться, что невалидные значения правильно обрабатываются. 26 заглавных латинских букв, 26 строчных букв, не менее 6 знаков пунктуации и пробел… Уже 68, а это мы еще не вспомнили о кириллице, спецсимволах и тому подобном.
Если мы посмотрим на более реалистичный пример, то всё ещё хуже. На практике, системы обычно имеют более одного поля ввода и поля эти имеют разный размер. А еще есть различные окружения, на которых нужно выполнить тесты… Если мы возьмем для примера один скрин, на котором 15 полей ввода, каждое из которых принимает 5 значений, то чтобы протестировать все валидные комбинации ввода, нам понадобится 30 517 578 125 (5 в 15-й степени) тестов. Очень маловероятно, что это уложится во временные рамки вашего проекта.
Помните сказку о волшебном горшочке с кашей, который наварил ее столько, что залил целый город? Так вот, наш «горшочек» может варить очень-очень долго, почти бесконечно, и когда-то нам надо сказать: «Стоп! Горшочек, не вари!».
Используя технику классов эквивалентности, мы можем сократить число наших тестов, ведь тестирование нашего поля ввода, принимающего одну цифру, при помощи значений 2, 3, 4 не дает нам больше информации, чем если бы мы протестировали только со значением 3.
Объем тестирования в реальной жизни ограничен временными рамками и бюджетом, в то же время существует необходимость поставить техническое решение, которое отвечает требованиям заказчика. Заказчики и руководители проекта хотят возврата инвестиций (ROI) от времени, потраченного на тестирование (время – деньги). Например, предотвратить появление ошибок после релиза – исправлять их всегда дорого. Но полное тестирование они просто не могут себе позволить – даже если очень хочется…
Вместо попыток «протестировать всё» нам нужен некий подход к тестированию (стратегия), который обеспечит правильный объем тестирования для данного проекта, данных заказчиков (и других заинтересованных лиц) и данного продукта. При определении, какой объем тестирования достаточен, необходимо учитывать уровень риска, включая технические риски и риски, связанные с бизнесом, и такие ограничения проекта как время и бюджет. Оценка и управление рисками – одна из наиболее важных активностей в любом проекте. Это позволяет варьировать трудозатраты на тестирование, основываясь на уровне риска в различных областях.
Кроме того, тестирование должно обеспечивать необходимую информацию, чтобы заинтересованные лица могли принимать информированные решения о релизе продукта или передаче заказчикам.
Продолжение статьи.
Курсы по тестированию ПО.