
Виктория Слинявчук
7 принципов тестирования. Часть 1
03.05.2021 20132
Другие статьи автора
Пирамида автоматизации
Распространенные ошибки начинающих тестировщиков
Как научиться учиться. Часть 2
Как научиться учиться. Часть 1
7 принципов тестирования. Часть 2
7 принципов тестирования. Часть 3
Манифест Agile-тестировщика. Часть 1
Оружие математического поражения
Манифест Agile-тестировщика. Часть 2
Шерстяная Фуфайка на карте мира
Последние статьи в блоге
Самый популярный язык программирования в 2023 году
Верните до 95% средств за обучение
Java-сертификация: "за" и "против”. Часть 2
Java-сертификация: "за" и "против”. Часть 1
Работа и развлечения в эпоху искусственного интеллекта
IBS Training Center при поддержке Фонда “Сколково” создал российскую систему сертификации для системных аналитиков
Запускаем сертификацию на знание системы Test IT
Особенности рынка найма, обучения и сертификации Java-разработчиков в 2023 году — запись выступления Владимира Гернера
Скидка 30% на сертификацию для Java-разработчиков!
Женщины, изменившие IT
О 7 принципах тестирования пишут часто, но обычно довольно сжато. Дороти Грэхем и соавторы в своей замечательной книге объясняют эти основополагающие принципы весьма детально.
Принцип 1. Тестирование показывает наличие дефектов
Тестирование может показать, что дефекты присутствуют, но не может доказать, что дефектов нет.
Доказать, что чего-то нет, в принципе затруднительно. Сколько бы белых лебедей мы ни видели, это еще не служит основанием утверждать, что «все лебеди белые». Но если мы увидим хотя бы одного черного лебедя, мы может сказать, что «не все лебеди белые».
Сколько бы успешных тестов вы не провели, вы не можете утверждать, что нет таких тестов, которые не нашли бы ошибку. Но если мы нашли хотя бы один дефект, мы уже можем утверждать, что в данном ПО присутствуют дефекты.
Впрочем, это отнюдь не означает, что тестирование бесполезно и не может повысить наш уровень уверенности в качестве ПО. Тестирование уменьшает вероятность необнаруженных дефектов, которые остаются в ПО, но всегда нужно помнить, что даже если дефекты не найдены, это еще не доказательство того, что их нет.

Принцип 2. Исчерпывающее тестирование невозможно
Этот принцип связан с вопросом: «сколько нужно тестировать?».
Какие вообще могут быть ответы на этот вопрос? Мы можем протестировать всё, ничего не тестировать или протестировать какую-то часть. Идеальным вариантом выглядит «протестировать всё», но стоит разобраться, должны ли мы и можем ли вообще это сделать.
Сколько тестов нужно выполнить, чтобы полностью протестировать поле ввода, принимающее одну цифру? Зависит от того, что мы понимаем под словом «полностью». Есть 10 возможных валидных значений, но, кроме того, надо еще убедиться, что невалидные значения правильно обрабатываются. 26 заглавных латинских букв, 26 строчных букв, не менее 6 знаков пунктуации и пробел… Уже 68, а это мы еще не вспомнили о кириллице, спецсимволах и тому подобном.
Если мы посмотрим на более реалистичный пример, то всё ещё хуже. На практике, системы обычно имеют более одного поля ввода и поля эти имеют разный размер. А еще есть различные окружения, на которых нужно выполнить тесты… Если мы возьмем для примера один скрин, на котором 15 полей ввода, каждое из которых принимает 5 значений, то чтобы протестировать все валидные комбинации ввода, нам понадобится 30 517 578 125 (5 в 15-й степени) тестов. Очень маловероятно, что это уложится во временные рамки вашего проекта.
Помните сказку о волшебном горшочке с кашей, который наварил ее столько, что залил целый город? Так вот, наш «горшочек» может варить очень-очень долго, почти бесконечно, и когда-то нам надо сказать: «Стоп! Горшочек, не вари!».

Используя технику классов эквивалентности, мы можем сократить число наших тестов, ведь тестирование нашего поля ввода, принимающего одну цифру, при помощи значений 2, 3, 4 не дает нам больше информации, чем если бы мы протестировали только со значением 3.
Объем тестирования в реальной жизни ограничен временными рамками и бюджетом, в то же время существует необходимость поставить техническое решение, которое отвечает требованиям заказчика. Заказчики и руководители проекта хотят возврата инвестиций (ROI) от времени, потраченного на тестирование (время – деньги). Например, предотвратить появление ошибок после релиза – исправлять их всегда дорого. Но полное тестирование они просто не могут себе позволить – даже если очень хочется…
Вместо попыток «протестировать всё» нам нужен некий подход к тестированию (стратегия), который обеспечит правильный объем тестирования для данного проекта, данных заказчиков (и других заинтересованных лиц) и данного продукта. При определении, какой объем тестирования достаточен, необходимо учитывать уровень риска, включая технические риски и риски, связанные с бизнесом, и такие ограничения проекта как время и бюджет. Оценка и управление рисками – одна из наиболее важных активностей в любом проекте. Это позволяет варьировать трудозатраты на тестирование, основываясь на уровне риска в различных областях.
Кроме того, тестирование должно обеспечивать необходимую информацию, чтобы заинтересованные лица могли принимать информированные решения о релизе продукта или передаче заказчикам.
Продолжение статьи.
Курсы по тестированию ПО.
Расскажи друзьям:
![]()
Guest
|
![]()
Guest
|
Как не пропустить самое интересное?
Подписывайтесь на наш ежемесячный дайджест!