Повышение отдачи от тестировщиков на ранних этапах
Один из методов, который становится всё популярнее в мире разработки ПО, - это непрерывная поставка. Однако до того, как реализовать непрерывную поставку, вам нужно сначала внедрить непрерывную интеграцию (НИ). Кто-то говорит, что НИ нужна лишь разработчикам, но они ошибаются. В контексте скрама все являются частью команды разработки, и тестировщики также играют свои важные роли в НИ. И всё-таки тестировщики часто забывают или не знают, каким образом они вписываются в жизненный цикл НИ. Эта статья описывает способы, которые помогут вам увеличить ценность жизненного цикла разработки, работаете вы в Agile, DevOps или в традиционном контексте. Резиновый утёнокЯ слышал, как тестеры говорят: «Я же не кодер и вообще не технарь.» Может, это и так, но это не значит, что они не могут помочь процессу. Итак, с чего начать, если вы попали в команду, практикующую непрерывную интеграцию? Ключ в коммуникации, особенно если вы работаете в Agile-среде. Поэтому начать нужно с разговора с разработчиками и со знакомства с ними. Разговор напрямую бизнес-ценности не несет, но открывает простор для диалога о том, что делают разработчики. Когда в вашей команде много разработчиков, скорее всего, они используют парное программирование, ревью кода, а в идеале и то, и другое. Обе задачи нацелены на то, чтобы выдерживать определенный уровень качества кода. Однако основной фокус в них на технических аспектах качества, таких, как стандарты кодинга, «мертвый» код, бесконечные циклы, взаимоблокировки, а не на том, что создано именно то, что надо. На одном из проектов я работал в маленькой команде из трех человек, занятых анализом, кодингом и тестированием соответственно. В начале проекта мне передали новый релиз, готовый к тестированию. Но я понятия не имел ни о техническом качестве кода, ни об ожидаемом поведении ПО, поэтому мы запланировали фазу тестирования до того, как передать код на приемку бизнесу. Мы в то время не практиковали Agile и временами создавали не совсем то, о чем нас просил бизнес. Чтобы избежать переделок, мы решили ввести «сессии с резиновым утенком», чтобы проверить, то ли мы сделали, даже еще до того, как я начал тестировать. Название «резиновый утенок» - это отсылка к истории из книги «Прагматичный программист», в которой программист носил с собой резинового утенка и отлаживал код, заставляя себя объяснять утенку код, строчка за строчкой. Наш аналитик писал такие детальные ТЗ, что я мог использовать их для тестирования, не расписывая лишних сценариев. Каждый день разработчик объяснял мне код в терминах «для чайников», и я использовал ТЗ в качестве чеклиста для этих сессий. Это позволяло мне давать немедленный фидбэк разработчику, который добавлял элементы в свой бэклог. Поначалу эти сессии не были запланированной частью разработки или тестирования, но через несколько недель мы увидели, что качество нашей работы существенно возросло. Мы решили сделать такие сессии регулярной, планируемой частью нашего жизненного цикла разработки. Сессии были ограничены одним часом раз в день, что оставляло разработчику достаточно времени на программирование, а мне - достаточно времени, чтобы подготовиться к сессии и выполнять другую свою работу. Работая вместе с программистамиУ меня есть некоторый опыт в программировании (Visual Basic, Python, Delphi и JavaScript), но мы у себя использовали C# и для разработки, и для юнит-тестов. Во время «сессий с резиновым утенком» мы разбирали код, и я ознакомился с синтаксисом C#. Частью каждой сессии был разбор юнит-тестов, чтобы удостовериться, что мы тестируем то, что надо. Через пару недель я уже мог читать юнит-тесты без объяснений и добавил себе в план анализ юнит-тестов в качестве одной из регулярных задач. У тестировщика есть много техник, помогающих проверить, правильные ли вещи проверяются в юнит-тестах. Если вы знакомы с синтаксисом, который используется в юнит-тестах, вы можете легко выделить эти части и проанализировать их. Это позволяет вам давать фидбэк разработчику, когда вы вместе анализируете ТЗ. После нескольких аналитических сессий («с резиновым утенком» и с рассмотрением юнит-тестов) и поставок, я стал проверять изменения в коде еще до того, как начинал собственно тестирование. Я проверял, что изменилось, и сопоставлял с тем, что должно было быть реализовано. На основании этого анализа я определял, можно ли начать тест, или лучше пройтись по всем изменениям кода вместе с разработчиком. Основное внимание данной статьи уделено работе совместно с разработчиками в надежде повысить качество на более ранних стадиях жизненного цикла. Но это означает также, что для этого у нас должны быть правильные исходные данные от наших аналитиков и бизнеса. Подробный разбор технического задания с аналитиком, который его писал - это вариация такой же сессии «с резиновым утенком», как и в случае с разработчиком. В дополнение к этим сессиям вы должны заполучить дополнительные бизнес-сценарии, которые также станут почвой для сессий «с резиновым утенком». Когда эти сценарии будут внедрены в юнит-тесты, они создадут раннее видение с точки зрения бизнеса, так что не забывайте информировать аналитиков и бизнес об итогах этих тестов на протяжении жизненного цикла разработки. Повышение ценности на более ранних этапах жизненного циклаУ вас, тестировщика, есть свой взгляд, отличный от разработчиков и аналитиков, на то, что должно быть разработано и правильно ли оно разработано. Довольно часто мы ждем, когда будет написан код, и потом начинаем запланированные тесты, но во многих случаях в первой сборке наблюдаются аномалии, которые можно было выявить и предотвратить на этапе сессий «с резиновым утенком». Парное программирование и анализ кода помогают повысить техническое качество кода, но обычно проверка, соответствует ли код поставленным задачам, производится на более поздних этапах жизненного цикла. В нашей команде после нескольких релизов нагрузка существенно возросла, и мы добавили нескольких разработчиков. Анализ кода стал частью цикла разработки, но эта проверка в основном касалась того, полон ли код и соответствует ли он стандартам. Используя сценарии, предоставленные аналитиком и бизнесом, я смог сменить фокус со способа разработки кода на то, правильное ли поведение отражает этот код. Я так же передал эти бизнес-сценарии, переведенные в вид читаемых тест-скриптов, разработчикам, чтобы они могли создать на их основе юнит-тесты. Таким образом мы еще до развертывания в тестовой среде знали, что юнит-тесты прошли успешно, и нам не приходилось делать лишнюю работу перед сборкой. Таким образом, есть четыре конкретных процесса, которые тестировщики могут задействовать, чтобы, сотрудничая с остальной командой, повышать ценность в жизненном цикле разработки:
Повышение ценности жизненному циклу разработки применимо не только для сред, где внедрена непрерывная интеграция. Работа в тесном сотрудничестве со всей командой - это ключ к более раннему повышению качества. То, что вы можете сделать как тестировщик при непрерывной интеграции и поставке, начинается с повышения ценности жизненного цикла разработки.
Оригинал: http://www.stickyminds.com/print/article[...]-add-value-earlier-development-lifecycle Об авторе: Антуан - опытный консультант по тестированию, работающий в Polteq в Нидерландах. Ему нравится работать в Agile-среде, и он сосредоточен на том, чтобы помочь тестировщикам достичь максимальной отдачи в Agile-командах. Кроме того, он питает сильный интерес к новшествам в технологии, вследствие чего он всегда на передовой в своей сфере. Перевод: Александра Родсет |
Еще интересные статьи на эту тему:
|
