1 мая 2020
35150
В статье использованы материалы книги «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 принципах тестирования пишут часто, но обычно довольно сжато. Дороти Грэхем и соавторы в своей замечательной книге объясняют эти основополагающие принципы весьма детально.
Принцип 5. Парадокс пестицидов
Если повторять те же тесты снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
Те скопления дефектов, о которых говорит 4-й принцип, имеют тенденцию перемещаться. Почему так происходит?
Эту аналогию ввел Борис Бейзер в 1983 г. Он привел пример обработки полей пестицидами. Поле обрабатывается неким пестицидом в первый раз, и значительная часть вредителей погибает, но некоторые все же выживают, потому что их организмы оказались устойчивы к действию яда. Если повторно обработать поле тем же пестицидом, то выжившие после первой обработки с большой вероятностью выживут и после второй. Повторное применение тех же тестов и тех же методик приводит к тому, что в продукте остаются именно те дефекты, против которых эти тесты и эти методики неэффективны.
Чтобы преодолеть «парадокс пестицидов», необходимо регулярно пересматривать существующие тест-кейсы и создавать новые, разнообразные тесты, которые будут выполняться на различных частях системы. Это позволит обнаружить больше дефектов.
Принцип 6. Тестирование зависит от контекста
Тестирование выполняется по-разному, в зависимости от контекста. Например, тестирование систем, критических с точки зрения безопасности, проводится иначе, чем тестирование сайта интернет-магазина.
Этот принцип тесно связан с понятием риска. Что такое риск? Риск – это потенциальная проблема. У риска есть вероятность (likelihood) – она всегда выше 0 и ниже 100% – и есть влияние (impact) – те негативные последствия, которых мы опасаемся. Анализируя риски, мы всегда взвешиваем эти два аспекта: вероятность и влияние. Например, когда мы переходим дорогу, есть некоторая вероятность, что нас собьет машина. Вероятность этого зависит от ряда факторов: насколько интенсивное движение на дороге, есть ли безопасный пешеходный переход, насколько хорошо мы видим, насколько быстро мы можем перейти дорогу. Воздействие зависит от скорости движения машины, от того, есть ли на нас какая-то защитная одежда, от нашего возраста и состояния здоровья и так далее. Исходя из этих факторов, человек выбирает наиболее оптимальную в данном случае стратегию перехода через дорогу.
То же можно сказать и о мире программного обеспечения: разные системы связаны с различными уровнями риска, влияние того или иного дефекта также сильно варьирует. Одни проблемы довольно тривиальны, другие могут дорого обойтись и привести к большим потерям денег, времени, деловой репутации, а в некоторых случаях даже привести к травмам и смерти.
Уровень риска влияет на выбор методологий, техник и типов тестирования.
Принцип 7. Заблуждение об отсутствии ошибок
Нахождение и исправление дефектов бесполезно, если построенная система неудобна для использования и не соответствует нуждам и ожиданиям пользователей.
Заказчики ПО – люди и организации, которые покупают и используют его, чтобы выполнять свои повседневные задачи – на самом деле совершенно не интересуются дефектами и их количеством, кроме тех случаев, когда они непосредственно сталкиваются с нестабильностью продукта. Им также неинтересно, насколько ПО соответствует формальным требованиям, которые были задокументированы. Пользователи ПО более заинтересованы в том, чтобы оно помогало им эффективно выполнять задачи. ПО должно отвечать их потребностям, и именно с этой точки зрения они его оценивают.
Даже если вы выполнили все тесты и ошибок не обнаружили, это еще не гарантия того, что ПО будет соответствовать нуждам и ожиданиям пользователей.
Иначе говоря, верификация != валидация.
Верификация – проверка ПО на соответствие требованиям. Валидация – проверка на предмет соответствия потребностям и ожиданиям, на соответствие заданным целям.
Часть тестовых активностей должна быть направлена на верификацию, часть – на валидацию.
Теоретически, если требования были собраны и проанализированы правильно и на этапе разработки архитектуры и кода не вкрались искажения, противоречия быть не должно. Но жизнь, увы, не идеальна.
Предыдущие статьи:
Курсы по тестированию ПО.
О 7 принципах тестирования пишут часто, но обычно довольно сжато. Дороти Грэхем и соавторы в своей замечательной книге объясняют эти основополагающие принципы весьма детально.
Принцип 5. Парадокс пестицидов
Если повторять те же тесты снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
Те скопления дефектов, о которых говорит 4-й принцип, имеют тенденцию перемещаться. Почему так происходит?
Эту аналогию ввел Борис Бейзер в 1983 г. Он привел пример обработки полей пестицидами. Поле обрабатывается неким пестицидом в первый раз, и значительная часть вредителей погибает, но некоторые все же выживают, потому что их организмы оказались устойчивы к действию яда. Если повторно обработать поле тем же пестицидом, то выжившие после первой обработки с большой вероятностью выживут и после второй. Повторное применение тех же тестов и тех же методик приводит к тому, что в продукте остаются именно те дефекты, против которых эти тесты и эти методики неэффективны.
Чтобы преодолеть «парадокс пестицидов», необходимо регулярно пересматривать существующие тест-кейсы и создавать новые, разнообразные тесты, которые будут выполняться на различных частях системы. Это позволит обнаружить больше дефектов.
Принцип 6. Тестирование зависит от контекста
Тестирование выполняется по-разному, в зависимости от контекста. Например, тестирование систем, критических с точки зрения безопасности, проводится иначе, чем тестирование сайта интернет-магазина.
Этот принцип тесно связан с понятием риска. Что такое риск? Риск – это потенциальная проблема. У риска есть вероятность (likelihood) – она всегда выше 0 и ниже 100% – и есть влияние (impact) – те негативные последствия, которых мы опасаемся. Анализируя риски, мы всегда взвешиваем эти два аспекта: вероятность и влияние. Например, когда мы переходим дорогу, есть некоторая вероятность, что нас собьет машина. Вероятность этого зависит от ряда факторов: насколько интенсивное движение на дороге, есть ли безопасный пешеходный переход, насколько хорошо мы видим, насколько быстро мы можем перейти дорогу. Воздействие зависит от скорости движения машины, от того, есть ли на нас какая-то защитная одежда, от нашего возраста и состояния здоровья и так далее. Исходя из этих факторов, человек выбирает наиболее оптимальную в данном случае стратегию перехода через дорогу.
То же можно сказать и о мире программного обеспечения: разные системы связаны с различными уровнями риска, влияние того или иного дефекта также сильно варьирует. Одни проблемы довольно тривиальны, другие могут дорого обойтись и привести к большим потерям денег, времени, деловой репутации, а в некоторых случаях даже привести к травмам и смерти.
Уровень риска влияет на выбор методологий, техник и типов тестирования.
Принцип 7. Заблуждение об отсутствии ошибок
Нахождение и исправление дефектов бесполезно, если построенная система неудобна для использования и не соответствует нуждам и ожиданиям пользователей.
Заказчики ПО – люди и организации, которые покупают и используют его, чтобы выполнять свои повседневные задачи – на самом деле совершенно не интересуются дефектами и их количеством, кроме тех случаев, когда они непосредственно сталкиваются с нестабильностью продукта. Им также неинтересно, насколько ПО соответствует формальным требованиям, которые были задокументированы. Пользователи ПО более заинтересованы в том, чтобы оно помогало им эффективно выполнять задачи. ПО должно отвечать их потребностям, и именно с этой точки зрения они его оценивают.
Даже если вы выполнили все тесты и ошибок не обнаружили, это еще не гарантия того, что ПО будет соответствовать нуждам и ожиданиям пользователей.
Иначе говоря, верификация != валидация.
Верификация – проверка ПО на соответствие требованиям. Валидация – проверка на предмет соответствия потребностям и ожиданиям, на соответствие заданным целям.
Часть тестовых активностей должна быть направлена на верификацию, часть – на валидацию.
Теоретически, если требования были собраны и проанализированы правильно и на этапе разработки архитектуры и кода не вкрались искажения, противоречия быть не должно. Но жизнь, увы, не идеальна.
Курсы по тестированию ПО.