Научить разработчиков тестировать. Реально ли? Нужно ли?

Очередные мысли (с вольными переводом) на тему тестирования разработчиками. Навеяно статьей Joel Montvelisky, который считает, что отправить разработчика тестировать - это отправить лису охранять курятник.

Фото отсюда

Но если напрячься, то можно научить разработчиков несложным, но эффективным техниками тестирования. Возможно, это может помочь вашему проекту.

Для этого потребуется несколько шагов.

Шаг 1 "Понять и простить" 

Нужно понять, что у разработчиков есть свои слабости:

• родительская забота о своем коде
• сфокусированность на успешном сценарии, вместо поиска проблем
• склонность смотреть на сложную проблему, как на набор небольших, простых и изолированных
• разработчик реже думает о пользователе
• меньше знаний общих проблем и узких мест продукта

Хмм, действительно часто наблюдаю и заботу, и узкий взгляд на проблему. Да, есть товарищи, которые, что называется кровью заплатили за этот самый опыт. И теперь реже наступают на грабли. Но забывать о слабостях все равно не нужно. С другой стороны: может "успешный сценарий" и есть те самые 20% функционала используемые 80% пользователей?

Шаг 2 - учим планировать тестирование.

Многие разработчики считают, что тестирование не требует планирования. На самом деле, это не так. Если мы говорим о тестировании разработчиками, то здесь есть некоторые правила при планировании:

• Если тестировать, то чужой код (см. про бережное отношение к своему коду выше)
• Обсуждайте набор тестов с тестировщиками
• Расширяйте сценарии после анализа окружения, конфигурации, набора данных, с которые будут задействованы в сценариях.
• Тестируйте эвристически: принцип SFDEPOT

SFDEPOT нам дает:

S(tructure) - из чего состоит продукт

F(unction) - что продукт делает

D(ata) - с чем он работает

P(latform) - от чего зависит

O(perations) - как он будет использован

T(ime) - когда он будет использован

Шаг 3 Что делать, когда запускаются тесты :)

1. Записывайте новые идеи того, что нужно проверить, "баги" в которые воткнулись и которые нужно зарепортить (звучит как совет КО, имхо лучше сразу чинить. Вы же разработчик ;) С другой стороны, правильно отмеченные проблемы помогут вам на рестроспективах)
2. Не забывайте про работу с граничными значениями (большие/маленькие файлы, специфичные даты, максимальные/минимальные числовые значения и тп)
3. Размышляйте о негативных сценариях (например пропадание электричества и тп)
4. Старайтесь смотреть шире. При проверке конкретной функциональности, смотрите вокруг: что происходит с продуктом и его окружением.
5. Боритесь с селективной слепотой (слепотой по невниманию - Inattentional Blindness). Этот ролик поясняет в чем суть. Вы увлекаетесь одним предметом и не замечаете того, что происходит вокруг.

Шаг 4 Что делать, когда (как вам кажется) вы закончили тестировать
Даже когда вам кажется, что вы закончили, вы не должны успокаиваться. Подумайте где и что вы бы могли проверить.
Вот несколько практик

• Делайте перерывы, займитесь другими делами. А потом проанализируйте заново что вы проверяли и что нашли. Обычно помогает освежить мозги.
• Расскажите вашим коллегам о том, что и как вы проверяли. Самое удивительное, что в процессе этого, к вам в голову будут приходить новые идеи.
• Посоветуйтесь со спецами (наверняка у вас есть крутаны-тестировщики). Они обязательно придумают вам еще 100500 сценариев, которые вы забыли проверить. :)

А на самом деле, кто в итоге будет тестировать: разработчики, тестировщики или совместно - не важно. Главное чтобы: "пацан наШкодил - пацан исправил" :) А кто эту шкоду нашел, какая разница? 

Но ведь пацаны пишут все правильно и без ошибок, не так ли? ;)

Почему? Потому что используют TDD.
Uncle Bob (aka Robert C. Martin) недавно замутил очередную бурю по этому вопросу. Две интересные статьи всколыхнули прогрессивную общественность The Start-Up Trap и The Pragmatics of TDD. Читаем и задумываемся.

Так нужно ли учить разработчиков тестировать? Наверно нужно. Постоянно появляются статьи про то, что тестировщикам нужно уметь программировать (см. статью про хорошего тестировщика). Так почему же разработчики не должны понимать базовые принципы тестирования. Это позволит команде говорить на одном языке.