Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Heisenbug 2021 Moscow
Большая техническая конференция для тестировщиков
5-7 октября 2021, онлайн

Что пишут в блогах (EN)

Разделы портала

Про инструменты

.
Эффект пестицида
09.12.2020 00:00

Автор: Ольга Назина

Если повторять одни и те же тесты снова и снова, в какой-то момент они перестанут выявлять новые ошибки.

Эту аналогию ввел Борис Бейзер в 1983 г в своей книге "Software Testing Techniques". Он привел пример обработки полей пестицидами. Поле обрабатывается неким пестицидом в первый раз, и значительная часть вредителей погибает.

 

Но некоторые всё же выживают, потому что их организмы оказались устойчивы к действию яда. Если повторно обработать поле тем же пестицидом, то выжившие после первой обработки с большой вероятностью выживут и после второй. 
 
 
 
Аналогично в тестировании. Повторное применение тех же тестов и тех же методик приводит к тому, что в продукте остаются именно те дефекты, против которых эти тесты и эти методики неэффективны.
Чтобы избежать эффекта пестицида, нужно каждый раз брать разные значения для тестов. Например, у нас есть такой чек-лист для тестирования имени при регистрации:
 

Проверка

Пример

Результат

Мужское

Иван

Успешная регистрация

Женское

Мария

Успешная регистрация

Унисекс

Саша

Успешная регистрация

Пустое

 

Ошибка: введите имя!

 
В первый раз берем пример, а потом используем что-то своё. Мужское имя? Иван, Александр, Ян, Анатолий...
 
Это помогает найти ошибки, о которых мы даже не думали! Например, система ругается на вполне нормальное имя «Иван», пропуская «Саша», «Антон» или даже «Фигня» (вполне реальная история с Иваном).
 
Или мы исходно предполагаем, что имя — это простая строка, поэтому ее не надо делить на «мужское / женское / ...». А потом выясняется, что система по имени ставит пол и всех считает мужчинами. Или ругается на женские имена, мол, «таких не бывает». Или что-то ещё.
 
То есть смена тестовых данных может помочь нам найти класс эквивалентности, о котором мы не подумали. Но на который натолкнулись случайно.
 

 
 
Так что если у нас есть в чек-листе пример — используем его. Для первого раза. А потом начинаем варьировать:
 
— Если нужно ввести число, то каждый раз пробуем разное. То 5, то 55, то вообще 888888.
 
— Если нужен реальный московский адрес, то каждый раз пробуем ввести новый. Или играем формой записи: «Москва, Турчанинов пер, 6», «город Москва, пер Турчанинов 6», «г. Москва, пер. Турчанинов, дом 6»...
 
— Если нужен email, тоже пробуем разные. С точкой внутри, с тире, начинается с заглавной буквы, с маленькой...
 
— Если нужно выбрать цвет в фильтре интернет-магазина, то один раз выбрали красный, потом зеленый, потом черный, потом фиолетовый...
 
Думаю, принцип вы поняли =)
 
 

 
 
Если вы нашли баг благодаря тому, что выбрали другое значение — нужно провести анализ. Из-за чего именно возникла ошибка? Чем «падающее» значение отличается от примера? Вполне возможно, что это отдельный класс эквивалентности, просто вы о нем не подумали раньше. 
 
В таком случае расширяем исходный чек-лист, добавляя новую строку для проверки. Например, в имя вводили Иван, Мария, Анна — все было нормально. А ввели двойное «Анна Мария», и система сломалась. Разработчик посчитал, что имя — это одно слово. Ага, понятно. Значит, теперь будем проверять:
  • Имя в одно слово (Иван, Мария, Антуаннетта)
  • Имя в несколько слов (Анна Мария, Анна-Мария, Жан Жак Руссо)
Иногда смотришь потом на новые проверки и думаешь:
 
— Как я раньше об этом не подумал? Разные же значения!
 
Но это не страшно. Лучше запомните на будущее, что есть и такая проверка. Главное — не упираться в один и тот же пример. Иногда взятое с потолка значение помогает найти баг и обнаружить отдельный класс эквивалентности!
 
 

 

 
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков