Home

Автор: Катрина Клоки (Katrina Clokie)

Оригинал статьи: http://katrinatester.blogspot.ru/2016/07/test-infected-developers.html

Перевод: Ольга Алифанова

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

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

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

Код тестов стал лучше

Раньше тест-код был чем-то вроде темных глубин подсознания. Все знали, что он есть, но большинство избегало встреч с ним один на один. Особенно сопротивлялись наши разработчики – по-моему, они просто не хотели связываться с кодом, полным всякого мусора вроде плохих практик и спорных решений. Когда разработчики таки подключались к работе над нашим кодом, обычно это выливалось в раздражение, а не в удовольствие от работы.

Тест-команда проделала большую работу, улучшив качество кода автотестов. В начале года мы занялись глобальным рефакторингом автотестов в одном из наших проектов, и добились возможности запускать тесты параллельно, что сократило время на их прогон более чем вдвое. В другом проекте мы запустили абсолютно новый набор тестов, при создании которых заранее утвердили стандарты кода.

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

Более того, теперь все изменения тест-кода проходят через ревью, аналогичное ревью кода приложения. Чтобы упростить обсуждение, мы используем запросы на включение. Мы выдвигаем к нашему коду требования – для нас это не просто «всего лишь тест-код». Мы хотим, чтобы наши автотесты было так же легко поддерживать, как и наше приложение.

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

Неидеальный тестовый фреймворк

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

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

Что касается самих тестов – некоторые сценарии очень сложно автоматизировать, особенно в наших приложениях, сильно завязанных на JavaScript – там нам зачастую приходится ждать обновлений различных аспектов интерфейса, выполняя какую-либо последовательность действий. Разработчики, пишущие вспомогательные методы, облегчающие тестирование таких областей, зачастую куда лучше понимают наши тесты и чаще подключаются к работе над ними.

Мне кажется, что основа совместной с разработчиками работы над автотестами – это создание интересных задач с внятной целью, решая которые, разработчики будут чувствовать, что сделали что-то нужное и полезное. Иногда это будет разовая работа, а иногда – только старт глубокого погружения в тестирование.

Внедрение в разработку

Каждый раз, когда разработчик вносит изменения в код наших приложений, он создает запрос на слияние кода с мастер-веткой релиза. Наши инструменты настроены так, что код, идущий в мастер-ветку, должен пройти через все наши автотесты, при любом изменении кода.

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

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

Расписание сборки билдов помогло исключить "болевые точки" кода автотестов и подключило более широкую аудиторию к процессу поиска и исправления первопричин появления подобных проблем. На данный момент большинство наших разработчиков хотя бы раз столкнулось с проблемой падения сборки, и лично проводило дебаг пары-тройки тестов, чтобы устранить проблему. Разработчики активно отслеживают результаты тестов и анализируют падения – и, как следствие, намного лучше знакомы с кодом наших тестов.

Заключение

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

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

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

Обсудить в форуме