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

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


Фото отсюда

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

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

Комментарии

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

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

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

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода.

Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT.

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля.
Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)
Здесь приведу лишь те вещи, которые мне запали в мозг
Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"
Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

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

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

Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.