|
Персональные инструменты |
![]() |
||
|
![]() |
![]() Аналитик и Тестировщик в одном лице - путь к качеству (Максим Цепков, SQA Days-10)Материал из CustisWiki(перенаправлено с «Тестировщики: тестирование - не главное? (Максим Цепков, SQA Days-10)»)
Аналитик и Тестировщик в одном лице – путь к качеству Доклад Максима Цепкова на 10-й конференции SQA Days 2-3.12.2011 Презентация на slideshare Статья опубликована на software-testing.ru, обсуждение на форуме СодержаниеКраткие тезисыРассматривается различное содержание ролей в традиционной водопадной и современной Agile методологиях разработки ПО. Для сравнения использованы диаграммы на основе V-модели (http://ru.wikipedia.org/wiki/V-Model): по нисходящей ветви идет конструирование и создание программного артефакта, а по восходящей – его тестирование и внедрение. Для «водопада» характерно разделение ролей по стадиям жизненного цикла: аналитики выполняют сбор требований и конструирование, затем разработчики реализуют программный продукт и передают его тестировщикам и внедренцам. При этом обсуждают требования одни, а проверяют и внедряют готовый продукт — другие, что представляет проблему из-за искажений и потерь при передаче информации. Agile стремится к кросс-функциональности внутри команды. На практике обычно сохраняются две роли – аналитика-тестировщика и разработчика. Аналитик общается с заказчиком и формулирует задание на разработку, и он же проводит тестирование и внедрение. Такой процесс позволяет избежать потери информации и повышает качество продукта, а также обеспечивает большую скорость и гибкость разработки. Схемы на базе V-модели, использованные в докладе, могут применяться для визуализации разделения ролей в реальных проектах разработки и их динамики в ходе проекта. Статья по докладуОт водопада к AgileРис.1. Водопадная модель, из википедии В ходе разработки ПО распределение ролей участников естественным образом должно соответствовать организации процесса разработки. Традиционная организация разработки опиралась на водопадную модель (Рис.1). В последнее десятилетие водопадная модель сдает свои позиции и сменяется гибкими (Agile) методологиями разработки. Это происходит не только на уровне IT-сообщества: в современных редакциях стандартов, таких как PMBOK 4 версии, 2008 и SWEBOK 3 версии, 2004, сделаны оговорки, что структура самого документа повторяет стадии водопадной модели лишь по совпадению и явно упоминаются альтернативные Agile-подходы. Agile-методологии создают предпосылки для изменения состава ролей в команде разработки, декларируя кросс-функциональность. Однако полностью кросс-функциональные команды встречаются довольно редко. Обычно разделение сохраняется, либо в виде разных ролей внутри команды, либо в виде отдельных функциональных команд. Даже при сохранении ролей в рамках одной команды, границы между ролями могут быть проведены по-другому, нежели в водопадной модели. V-модельРис.2. V-модель, из википедии Для иллюстрации используем V-модель процесса разработки (Рис.2), которая была позаимствована из системной инженерии. По нисходящей ветви мы абстрагируемся от внешнего мира, производя конструирование и создание программного артефакта, а по восходящей — вносим созданный артефакт во внешний мир, выполняя его тестирование и внедрение. V-модель интересна тем, что дает достаточно общий взгляд на процесс как таковой, не сосредотачиваясь на его отдельных стадиях. Поэтому она удобна для сравнения различных моделей разработки. Классические ролиВ водопадной модели для каждой стадии жизненного цикла программного продукта предусмотрена своя роль: бизнес-аналитики собирают требования и описывают предметную область, системные аналитики выполняют конструирование системы, затем разработчики реализуют программный продукт и передают его тестировщикам и внедренцам, а далее - службе поддержки. Такое разделение ролей представлено на Рис.3. Основной недостаток такого процесса состоит в том, что требования с заказчиком обсуждают одни специалисты, а проверяют и внедряют готовый продукт — другие. В ходе передачи информация искажается и теряется, и, как показывает опыт, никакие спецификации не позволяют этого исключить. В результате заказчик зачастую получает продукт, не соответствующий его ожиданиям. Ошибки, допущенные на этапе постановки, занимают наибольшую долю среди причин провалов или задержек выпуска программных продуктов, поэтому их устранение является крайне важным. АльтернативаAgile-методологии появились и развивались в ответ на проблемы традиционных методологий. Чтобы снижать риски, связанные с постановками, в них предусмотрено два механизма. Во-первых, быстрая обратная связь через демонстрации и общение с заказчиком. Во-вторых, стремление к кросс-функциональности внутри команды. Однако в реальности полная кросс-функциональность достигается редко из-за широкого спектра разнородных деятельностей, входящих в процесс создания ПО. Поэтому на практике обычно сохраняются две роли – аналитика-тестировщика и разработчика. Новая роль аналитика-тестировщика объединяет обязанности аналитика, тестировщика и внедренца из классического разделения ролей, что изображено на Рис.4. Аналитика-тестировщика традиционно называют аналитиком, хотя столь же успешно его можно было бы назвать и тестировщиком. Более того, если существенная часть аналитической работы находится на стороне заказчика, то последнее точнее отражает его функции. В итоге мы получаем структуру, в которой аналитик играет роль «внутреннего заказчика»: общается с внешним заказчиком и формулирует задание на разработку, передает его разработчику и затем принимает от того готовый продукт, проводит тестирование и внедрение, сдавая конечный продукт внешнему заказчику. Преимуществом этой конструкции является гораздо бОльшая ответственность аналитика за качество подготовки и передачи задания для разработки, а также и за конечный результат в целом, поскольку именно ему надо будет защищать его перед заказчиком. Отметим, что такое разделение ролей может использоваться в различных процессах разработки. В частности, о таком разделении рассказывал Пауль Тернер на Req-Labs. Однако, именно в кросс-функциональной Agile-команде, использующей современную методику разработки и проектирования DDD с единым языком, обеспечивающим коммуникацию, оно особенно эффективно. Такой распределение обязанностей позволяет избежать потери информации и повышает качество продукта, а также обеспечивает большую скорость и гибкость разработки. В компании CUSTIS мы применяем именно такое разделение ролей в команде. У нас нет чистых аналитиков и чистых тестировщиков, эти роли совмещены. При этом внутри команды их обычно несколько, также как и несколько разработчиков, и мы стараемся обеспечить кросс-функциональность в пределах каждой роли. Правда, у этой модели, если рассматривать ее в чистом виде, есть и недостаток – достаточно большая нагрузка на аналитиков, которые обычно представляют собой дефицитный ресурс. Выход мы видим в том, чтобы готовить таких кросс-функциональных аналитиков непосредственно в проектах: в начале проекта менее опытные аналитики начинают преимущественно с задач тестирования, а по мере роста квалификации все больше берут на себя и аналитическую составляющую работы. Визуализация ролей на V-моделиСхемы на базе V-модели, использованные в статье, могут применяться для визуализации разделения ролей в реальных проектах. С их помощью можно представлять более сложные схемы с большим числом ролей, учитывая, в числе прочего, различную квалификацию сотрудников, а также наблюдать за динамикой изменения обязанностей в ходе проекта и оценивать рост опыта сотрудников. Визуализация предмета рассуждений всегда способствует взаимопониманию, и V-диаграммы с ролями оказались для этого удобным инструментом. Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации. |
![]() |
![]() |
![]() |