Эффект пестицида

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

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

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

Аналогично в тестировании. Повторное применение тех же тестов и тех же методик приводит к тому, что в продукте остаются именно те дефекты, против которых эти тесты и эти методики неэффективны.

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

Проверка	Пример	Результат
Мужское	Иван	Успешная регистрация
Женское	Мария	Успешная регистрация
Унисекс	Саша	Успешная регистрация
…	…	…
Пустое		Ошибка: введите имя!

В первый раз берем пример, а потом используем что-то своё. Мужское имя? Иван, Александр, Ян, Анатолий...

Это помогает найти ошибки, о которых мы даже не думали! Например, система ругается на вполне нормальное имя «Иван», пропуская «Саша», «Антон» или даже «Фигня» (вполне реальная история с Иваном).

Или мы исходно предполагаем, что имя — это простая строка, поэтому ее не надо делить на «мужское / женское / ...». А потом выясняется, что система по имени ставит пол и всех считает мужчинами. Или ругается на женские имена, мол, «таких не бывает». Или что-то ещё.

То есть смена тестовых данных может помочь нам найти класс эквивалентности, о котором мы не подумали. Но на который натолкнулись случайно.

 

Так что если у нас есть в чек-листе пример — используем его. Для первого раза. А потом начинаем варьировать:

— Если нужно ввести число, то каждый раз пробуем разное. То 5, то 55, то вообще 888888.

— Если нужен реальный московский адрес, то каждый раз пробуем ввести новый. Или играем формой записи: «Москва, Турчанинов пер, 6», «город Москва, пер Турчанинов 6», «г. Москва, пер. Турчанинов, дом 6»...

— Если нужен email, тоже пробуем разные. С точкой внутри, с тире, начинается с заглавной буквы, с маленькой...

— Если нужно выбрать цвет в фильтре интернет-магазина, то один раз выбрали красный, потом зеленый, потом черный, потом фиолетовый...

Думаю, принцип вы поняли =)

Если вы нашли баг благодаря тому, что выбрали другое значение — нужно провести анализ. Из-за чего именно возникла ошибка? Чем «падающее» значение отличается от примера? Вполне возможно, что это отдельный класс эквивалентности, просто вы о нем не подумали раньше. 

В таком случае расширяем исходный чек-лист, добавляя новую строку для проверки. Например, в имя вводили Иван, Мария, Анна — все было нормально. А ввели двойное «Анна Мария», и система сломалась. Разработчик посчитал, что имя — это одно слово. Ага, понятно. Значит, теперь будем проверять:

• Имя в одно слово (Иван, Мария, Антуаннетта)
• Имя в несколько слов (Анна Мария, Анна-Мария, Жан Жак Руссо)

Иногда смотришь потом на новые проверки и думаешь:

— Как я раньше об этом не подумал? Разные же значения!

Но это не страшно. Лучше запомните на будущее, что есть и такая проверка. Главное — не упираться в один и тот же пример. Иногда взятое с потолка значение помогает найти баг и обнаружить отдельный класс эквивалентности!

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