К основному контенту

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

Очередные мысли (с вольными переводом) на тему тестирования разработчиками. Навеяно статьей 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. Читаем и задумываемся.

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

Комментарии

Популярные сообщения из этого блога

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то ...

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе...