суббота, 17 марта 2012 г.

Мотивация писать тесты


Достаточно часто я слышу вопросы от коллег на конференциях, сводящиеся к тому, как мотивировать разработчиков писать тесты к своему коду и, вообще, повысить их ответственность за результат.

Прежде всего, хочу сказать, что профессиональной разработкой программного обеспечения (читай "за деньги") я занимаюсь вот уже 11 лет, и так уж получилось, что все эти годы я работал без тестеров и привык отвечать за то, что я делаю сам. Посему, мне несколько дико слушать истории, в которых "разработчики" позволяют себе отдавать код, который они даже не проверили сами, по принципу "компилируется - значит работает".

Получается, что перед тем, как начинать говорить о том, как мотивировать разработчиков писать тесты, стоит убедить программистов относится к результатам своей работы более внимательно. Тесты станут уже следствием осознания своей ответственности за результат.

Многие руководители не понимают, зачем им что-то менять, если система и так работает. Для компании Agile методики несут в перспективе прежде всего сокращение затрат на разработку за счет сокращения части подразделений QA, занимающихся неблагодарным трудом ручного тестирования. Сейчас стоимость квалифицированного тестера на рынке не многим ниже стоимости разработчика. Даже если скорость разработчиков и упадет в полтора раза, затраты все равно сократятся. В реальных условиях средняя скорость, скорее всего, вырастет за счет исключения длительного периода ручного регрессионного тестирования в конце каждой итерации.
Также за счет укорачивания фазы QA и уменьшения времени на стабилизацию продукта удастся уменьшить длинну итерации, что позволит бизнесу быть более гибким, легче реагировать на изменения и планировать релизы. Совершенствуя эту модель, можно будет достичь нирваны в виде непрерывной поставки (Continuous Delivery).

Чтобы там не говорили, но умение писать легко тестируемый код, и умение создавать эти самые тесты не берется из воздуха, а ему придется учиться.  А следовательно, как минимум по-началу разработчикам придется выйти из своей зоны комфорта и поучиться чему-то новому. Увы, тяга к познанию и обучению зачастую падает с возрастом. К тому же, если у человека 10-летний опыт работы "по старинке", ему очень не просто объяснить, зачем ему все это надо.  Часто это становится причиной некого противостояния в коллективе: на одной стороне которого оказываются матерые разработчики и тестеры, а на другой те, кто пытается что-то изменить. Хуже когда в этом противостоянии на стороне "ретроградов" находится и начальство. Я самолично общался с директором одной аутсорсинговой компании, который придерживался мнения, что все эти новомодные штуки явление проходящее. 

При наличии же поддержки руководства, понимания им преимуществ, которые эта система дает, и его гибкости постепенно в коллективе образуются группы людей, которые хотят работать по-новому. Не стоит ожидать мгновенного результата. Вначале неизбежны шероховатости: провалы в скорости, чрезмерное увлечение метриками, попытки автоматизировать всё и вся и попытки написать очередной тестовый фреимворк. Со временем команды обретут опыт и чутье, и будут с радостью нести это знание другим. Не зря в сети активно циркулирует термин test infected, инфицированные этим вирусом люди заразят других. 

Внедрять автоматизацию тестирования лучше начинать с небольших новых проектов, которые ведут маленькие молодые команды. Это уменьшит потенциальные риски, и поможет легче оценить результат. Для начала внедрения автоматизации лучше те проекты, что имеют веб-интерфеис, и используют среды, для которых уже существует большое количество библиотек и средств для тестирования (например, .NET, Java, Python). Писать тесты для приложении на С\C++ может оказаться не самой легкой, хотя и решаемой задачей.

Наличие автоматических тестов вовсе не избавляет команду от необходимости эксплоритарного тестирования продукта. На мой взгляд для этого нет нужды в выделенных тестерах. Должна просто сложиться практика внутри команды, когда сами разработчики, их менеджеры и заинтересованные лица смотрят продукт, его новые возможности и волей-неволей проверяют продукт, сталкиваются с ним, то есть начинают "Есть корм своих собак" (с) Джоел Спольски. 

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

Порой многие считают, что их приложение самое критичное в мире. Возможно, есть и такие. Например, если вы пишите (или лучше сказать писали) софт для небезызвестного спутника "Фобос Грунт", для робота-хирурга или марсохода. Но большинство компании, на мой взгляд, несколько пероценивают критичность своих продуктов. Например, софт, работающий на вебе, очень толерантен к ошибкам. Гиганты веб-индустрии работают практически без тестеров, проверяя продукты на небольшом проценте пользователей и имея возможность легко откатить изменения. Многие продукты имеют встроенные средства обновления, которые тоже снижают критичность ошибок, т.к. обновление может быть доставлено пользователям даже без их ведома. В то же время пользователи вполне готовы тестировать софт на себе, часть из них даже очень радуется, если удалось найти ошибку.

Поэтому не стоит бояться трудностей, а стоит попробовать начать их решать. 

2 комментария:

Eduard Kibort комментирует...

Правильно написал. А что ты думаешь про мнение, что если тесты пишут разработчики, то это получается дороже? Насколько я понимаю, ты не согласен с этим.

Eduard Kibort комментирует...

Спасибо. Да не согласен. Прежде всего простейший поиск на hh.ru по словам "Software Developer" и "Test engineer" дают практически одинаковые вилки зарплат для Питера. Но при этом тестер пишущий тесты скорее всего будет иметь более низкую квалификацию как программист, а следовательно будет писать худший код, на поддержку которого будет тратить больше времени. К тому же девелоперы пишущие тесты будут находится в более выгодном положении, т.к. для написания тестов они могут вносить изменения в дизайн приложения позволяющие легче его тестировать.