Update: slideshare глючит, podfm со слайдкастом умер, запись в mp3 (качество не айс). Вот мое из свеженького на эту тему, чуть короче и буквами.
Слайды этого доклада можно посмотреть тут.
Состоялась вторая встреча DataArt IT talk SPb. Я там выступал с докладом "Можно ли обойтись без тестировщиков?"
Как получилось судить не мне, надеюсь, что участникам было интересно. Аудитория была процентов на 90 - как раз тестировщики :), говорить им о том, что они возможно не нужны было "забавно".
Слайды этого доклада можно посмотреть тут.
Состоялась вторая встреча DataArt IT talk SPb. Я там выступал с докладом "Можно ли обойтись без тестировщиков?"
Как получилось судить не мне, надеюсь, что участникам было интересно. Аудитория была процентов на 90 - как раз тестировщики :), говорить им о том, что они возможно не нужны было "забавно".
PS Это выступление было первым, надо еще тренироваться :) Мое "а-а-а-а-а" и "э-э-э-э" напрягает :( Ну и вопросы надо повторять, тороплюсь ответить.
Спасибо Вам за выступление. Кажется, оно вдохновило меня и моего коллегу на подвиги :)
ОтветитьУдалитьХотела задать вопрос: для проектов какого масштаба Вы считаете возможным обходиться без выделенных специалистов по тестированию и какие требования к организации процесса разработки считаете в данном случае обязательными.
Спасибо за отзыв. Очень надеялся, что кого-нибудь зацепит :) По масштабам - если Ваш проект делает команда от 1 до 10 человек, то это Вам подойдет. Но это не значит, что 11-й должен быть уже тестировщик(и) :). Вообще сложно говорить о масштабах. Ваша команда может работать над компонентом большой системы, и этот компонент и есть Ваш проект. Думаю там Вы вольны сами выбирать, как Вы будете его реализовывать. Хотя конечно Фобосы запускать без тестировщиков не нужно :)
ОтветитьУдалитьПо организации процесса: во-первых должны быть автотесты, без них это все теряет смысл. Применение Agile практик (без фанатизма) тоже если необязательно, то крайне желательно. Отлично если есть возможность описать user stories, супер если Ваш заказчик помогает Вам в этом. Описанные истории - это половина успеха. Вообще думаю это тема отдельного поста, спасибо за идею - обязательно подумаю, сформулирую и напишу.
Спасибо за ответ :) Было бы очень интересно почитать.
ОтветитьУдалитьМаксим, большое вам спасибо за доклад. Я был в числе тех 10% программистов, и я как раз коллега Алены, которого вы действительно вдохновили. Собственно на что вдохновили? На деятельность по повышению качества собственного кода через использование всякого рода тестирования, ну и на попытки помочь тестировщикам, чтобы не увольнять их :). Уж не знаю на сколько хватит энтузиазма, так как это будет инициатива снизу а не управленческая.
ОтветитьУдалитьВы говорили что в вашем проекте используется юнит-тестирование. Вы пишите тесты к готовому коду или все же TDD практикуете? Если TDD, интересно как изменилось количество времени на разработку/сопровождение фич вначале/потом?
Могли бы вы обобщить и привести список книг и может быть других источников, которые были наиболее полезны при для внедрения практик юнит, модульных, функциональных тестов, использования автотестов.
Еще хотелось бы предложить вам тему "Можно ли обойтись без документации" :)
Речь идет о различной документации в части разработки (проектирования архитектуры, отдельных модулей, классов и их взаимодействия etc).
Спасибо еще раз, ждем новых докладов :)
Спасибо за отзыв. Про книжки понял - сделаем. Насчет "документации" - можно обойтись без такого рода документации, хорошо написанные тесты и будут Вашей документацией. У нас кроме историй ничего и не было, и нет. Если такую документацию вести, ее постоянно надо поддерживать up-to-date, иначе время потраченное изначально вы можете заложить себе в убыток (=потраченное зря). Подробнее в отдельном посте (спасибо за наводку).
ОтветитьУдалитьTDD - отличный вопрос. У нас сейчас его нет и это ПЛОХО (см. мой пост про "10 причин..."). На прошлом проекте частично было. Будем и здесь стараться его внедрять. Коротко насчет времени: времени сначала тратиться чуть больше (поглощение теории, поиск инструментов, внедрение, просветление мозгов :), потом меньше - вы не тратите время на написание и тестирование того, что не нужно. Попытка писать тесты на уже написанный код плохо работает с модульным тестированием, так как код может быть написан "не для тестов". Кроме этого, такая практика (+ если это еще усугубляется ситуацией, когда тесты пишет другой разработчик, а не автор) это попытка догнать уходящий поезд - он постоянно уезжает.
Я пытался практиковать TDD в своем проекте, заметил что на разработку фичи уходит сначала до 30% - 40% времени больше, с опытом это превращается в 10% - 20%. Но эффект от наличия тестов заметен - я просто более уверен в своем коде, его качество выше, ну и спать спокойнее стал :) Но все было хорошо до поры до времени: однажды произошли изменения и 80% тестов перестали компилиться а время на их рефакторинг потребовалось для новых фич. Ну и пожалуй главная проблема это их запуск - нет инфраструктуры для их автоматического запуска, грустно как-то перед любым чекином запускать их вручную.
УдалитьВ итоге стало ясно что начальству по большому счету не важно есть ли тесты, вот не понятно как бы ему донести плюсы TDD, необходимость выделять ресурсы на написания тестов, на использование автотестов. Видимо это риторический вопрос...
Да, если начальство этого не понимает, то все сложнее. Но все в ваших руках, "вода камень точит". Проблема с переписыванием тестов существует, может помочь улучшение качества тестов (есть в книжках) и попытка начать писать тесты на фичи по историям (с минимальным обращением непосредственно к коду). Если Ваш проект это позволяет. Тогда локальные изменения в коде, будут реже затрагивать тесты. Конечно к модульным тестам это не относится.
УдалитьПроблемы при рефакторинге тестов чаще всего закладываются на этапе написания этих тестов. Требования к коду тестов должны быть не ниже, а в ряде случаев даже выше чем к коду самого продукта. Факторы которые ведут к долгому переписыванию тестов достаточно простые - 1. большие объекты с нечеткой ответственностью выполняющие множество задач приводят к тому, что в тестах приходится тратить огромное количество сил для приведения подопытной системы в нужное состояние (огромные mock'и). 2. дупликации в тестах – ведет к необходимости вносить одно изменение в десятки тестов 3. неверное использование или неиспользование принципов IoC ведущее к невозможности или чрезмерной сложности подмены зависимостей в тестируемой системе. 4. Тестирование через не public интерфейсы и тестирование через behavior тесты приводит к тому что мелкий рефакторинг внутренностей класса вызывает необходимости правки тестов.
УдалитьНа счет же высказывания Дмитрия "грустно как-то перед любым чекином запускать их вручную" категорически не соглашусь, юниттесты ДОЛЖНЫ запускаться именно на машине разработчика и проходить ооочень быстро. Долгими могут быть функциональные\интеграционные и приемочные тесты, которые уже должны выполняться на выделенных машинах в приближенном к боевому окружении.