;
Виктория Слинявчук
7 принципов тестирования. Часть 3
01.05.2020 35217
Другие статьи автора
Пирамида автоматизации
Распространенные ошибки начинающих тестировщиков
Как научиться учиться. Часть 2
Как научиться учиться. Часть 1
7 принципов тестирования. Часть 1
7 принципов тестирования. Часть 2
Манифест Agile-тестировщика. Часть 1
Оружие математического поражения
Манифест Agile-тестировщика. Часть 2
Шерстяная Фуфайка на карте мира
Последние статьи в блоге
Как оценивать работу тестировщиков по науке
Учебный центр IBS получил сертификат ГОСТ Р ИСО 9001-2015
Совет по развитию сертификации ИТ-специалистов при АПКИТ аккредитовал «Платформу сертификации IBS»
Java-сертификация: IBS в сравнении с Oracle
Исследование IBS: число новых ИТ-решений в реестре ПО выросло в 2023 году более чем на треть
6 суперспособностей Fullstack-тестировщиков, которые напоминают навыки животных
5 мифов о системных аналитиках
Методология 12 факторов: как успешно разрабатывать облачные приложения
Баги, которые стали фичами
Шаблоны облачного проектирования
О 7 принципах тестирования пишут часто, но обычно довольно сжато. Дороти Грэхем и соавторы в своей замечательной книге объясняют эти основополагающие принципы весьма детально.
Принцип 5. Парадокс пестицидов
Если повторять те же тесты снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
Те скопления дефектов, о которых говорит 4-й принцип, имеют тенденцию перемещаться. Почему так происходит?
Эту аналогию ввел Борис Бейзер в 1983 г. Он привел пример обработки полей пестицидами. Поле обрабатывается неким пестицидом в первый раз, и значительная часть вредителей погибает, но некоторые все же выживают, потому что их организмы оказались устойчивы к действию яда. Если повторно обработать поле тем же пестицидом, то выжившие после первой обработки с большой вероятностью выживут и после второй. Повторное применение тех же тестов и тех же методик приводит к тому, что в продукте остаются именно те дефекты, против которых эти тесты и эти методики неэффективны.
Чтобы преодолеть «парадокс пестицидов», необходимо регулярно пересматривать существующие тест-кейсы и создавать новые, разнообразные тесты, которые будут выполняться на различных частях системы. Это позволит обнаружить больше дефектов.
Принцип 6. Тестирование зависит от контекста
Тестирование выполняется по-разному, в зависимости от контекста. Например, тестирование систем, критических с точки зрения безопасности, проводится иначе, чем тестирование сайта интернет-магазина.
Этот принцип тесно связан с понятием риска. Что такое риск? Риск – это потенциальная проблема. У риска есть вероятность (likelihood) – она всегда выше 0 и ниже 100% – и есть влияние (impact) – те негативные последствия, которых мы опасаемся. Анализируя риски, мы всегда взвешиваем эти два аспекта: вероятность и влияние. Например, когда мы переходим дорогу, есть некоторая вероятность, что нас собьет машина. Вероятность этого зависит от ряда факторов: насколько интенсивное движение на дороге, есть ли безопасный пешеходный переход, насколько хорошо мы видим, насколько быстро мы можем перейти дорогу. Воздействие зависит от скорости движения машины, от того, есть ли на нас какая-то защитная одежда, от нашего возраста и состояния здоровья и так далее. Исходя из этих факторов, человек выбирает наиболее оптимальную в данном случае стратегию перехода через дорогу.
То же можно сказать и о мире программного обеспечения: разные системы связаны с различными уровнями риска, влияние того или иного дефекта также сильно варьирует. Одни проблемы довольно тривиальны, другие могут дорого обойтись и привести к большим потерям денег, времени, деловой репутации, а в некоторых случаях даже привести к травмам и смерти.
Уровень риска влияет на выбор методологий, техник и типов тестирования.
Принцип 7. Заблуждение об отсутствии ошибок
Нахождение и исправление дефектов бесполезно, если построенная система неудобна для использования и не соответствует нуждам и ожиданиям пользователей.
Заказчики ПО – люди и организации, которые покупают и используют его, чтобы выполнять свои повседневные задачи – на самом деле совершенно не интересуются дефектами и их количеством, кроме тех случаев, когда они непосредственно сталкиваются с нестабильностью продукта. Им также неинтересно, насколько ПО соответствует формальным требованиям, которые были задокументированы. Пользователи ПО более заинтересованы в том, чтобы оно помогало им эффективно выполнять задачи. ПО должно отвечать их потребностям, и именно с этой точки зрения они его оценивают.
Даже если вы выполнили все тесты и ошибок не обнаружили, это еще не гарантия того, что ПО будет соответствовать нуждам и ожиданиям пользователей.
Иначе говоря, верификация != валидация.
Верификация – проверка ПО на соответствие требованиям. Валидация – проверка на предмет соответствия потребностям и ожиданиям, на соответствие заданным целям.
Часть тестовых активностей должна быть направлена на верификацию, часть – на валидацию.
Теоретически, если требования были собраны и проанализированы правильно и на этапе разработки архитектуры и кода не вкрались искажения, противоречия быть не должно. Но жизнь, увы, не идеальна.
Курсы по тестированию ПО.
Расскажи друзьям:
Как не пропустить самое интересное?
Подписывайтесь на наш ежемесячный дайджест!