Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 6. Вопросы объединения процессов тестирования... 149 работу группы, что затрачиваемые на его устранение усилия приводят к существен ному снижению производительности группы в целом. По-видимому, такие исполни тели совершают некоторые ошибки, о которых речь шла выше. Скорее всего, они не обладают качествами, которые нужны специалисту по тестированию, дабы успешно справляться со своими обязанностями. Принцип продвижения по служебной лестнице играет важную роль в тестирова нии программного обеспечения. Человек, которого принимают на работу в группу тестирования, должен знать, какая служебная карьера его ожидает. Все большее чис ло компаний и специалистов рассматривают тестирование как вполне подходящую перспективу для служебного продвижения, в рамках которого отрываются возмож ности совершенствования в технических областях и приобретается опыт руководя щей работы. Тестирование программного обеспечения — это удачное место для изу чения производства программных продуктов на системном уровне. Поскольку оно затрагивает все аспекты продукции компании, оно может служить хорошей старто вой позицией для дальнейшей карьеры разработчика, а также специалиста по сопро вождению продукта на площадках заказчика, по технической поддержке пользовате лей или по техническому маркетингу. Совершенствование процесса тестирования Эффективный и отлаженный процесс тестирования нельзя получить в одночасье. Требуются месяцы, и даже годы планирования и напряженной работы, чтобы создать хорошо функционирующую организацию, способную выполнять работы по тестиро ванию. П р и любой попытке усовершенствовать установившийся процесс тестирова ния с самого его основания нужно принять во внимание следующие моменты: • Тестирование не может быть изолированным процессом. Тестирование про граммного обеспечения может быть эффективным только том случае, если оно интегрировано в жизненный цикл разработки программного обеспечения. Это означает, что попытки усовершенствовать сам процесс дадут мало пользы, по скольку совершенствование процесса тестирования должно выполняться в рамках более масштабных и всеобъемлющих работ. • Эффективный процесс тестирования может быть создан только за счет его по строения по стадиям. Существует несколько функциональных стадий или уров ней любого процесса разработки. Эти уровни могут быть представлены моде лями развития, к которым относятся: модель СММ (Capability Maturity Model — модель развития функциональных возможностей) программного обеспечения, разработанная институтом технологии программного обеспечения SEI (Soft ware Engineering Institute), модель ТММ (Test Maturity Model — модель развития тестовых возможностей), разработанная Иллинойским технологическим ин ститутом, и модель ТММ (Test Process Improvement — модель совершенствова ния процесса тестирования). Переход с одного уровня модели развития на дру гой должен происходить у п о р я д о ч е н и е Ни одна организация не может перей ти с нижнего уровня развития сразу на верхний за счет адаптации всего лишь нескольких процедур или инструментальных средств; продвижение должно происходить постепенно, уровень за уровнем, и без каких-либо пропусков. 150 Часть I. Процесс быстрого тестирования • Успешное совершенствование процесса затрагивает людей, которые с ним свя заны. Организация процесса того или иного процесса — это далеко не академи ческое или техническое мероприятие; она требует от персонала внести опре деленные коррективы в свои рабочие обязанности и заставляет руководство пересмотреть свои взгляды на то, что можно ожидать от подчиненных. Для то го чтобы любая инициатива, касающаяся улучшения процесса, оказалась ус пешной, в ее реализацию должны вносить посильный вклад все службы компа нии, от высшего руководства до исполнителей, занимающихся прогоном тес тов в испытательной лаборатории. Как только процесс будет определен, пер сонал, которому надлежит его использовать, должен пройти специальную под готовку, дабы достичь необходимого уровня согласованности и производи тельности. П е р в ы й пункт, утверждающий, что процесс тестирования не является независи мым, очевиден на протяжении всего жизненного цикла разработки. В качестве' при мера взаимной функциональной зависимости рассмотрим процесс выявления и фор мулирования технических требований. Как уже говорилось в предыдущих главах, тестирование должно начинаться с проверки формулировок требований. Формули рование требований представляет собой широкую межфункциональную деятель ность, в которой принимают участие представители руководства высшего уровня, групп маркетинга, разработчиков, производителей и поддержки на стороне заказчи ка. Представители других групп, кроме группы маркетинга, могут не принимать уча стие в прямом обмене данными с заказчиком; в то же время совершенно ясно, что сформулированные требования оказывают влияние на работу всей группы разработ ки программного продукта. Вторая особенность, связанная с тем, что эффективный процесс может строиться только постепенно, от стадии к стадии, рассматривается ниже, в контексте модели развития функциональных возможностей. Мы не будем исследовать все уровни и ключевые области процесса тестирования сквозь призму модели СММ, тем не менее, сосредоточимся на тех областях СММ, которые имеют отношение к принципам про цессам тестирования, которые рассматриваются в данной книге. Упомянутые выше модели развития подробно рассматриваются в [19], [41], [38] и [29]. Третий пункт показывает, каким путем достигается совершенствование процесса тестирования. Исследованию этих вопросов посвящена завершающая часть данной главы. Модель развития функциональных возможностей программного обеспечения СММ И н с т и т у т т е х н о л о г и й п р о г р а м м н о г о о б е с п е ч е н и я SEI (Software E n g i n e e r i n g Institute) — это проектно-исследовательская организация, основанная в 1984 году Ми нистерством обороны США и финансируемая федеральным правительством США. Она поддерживается университетом Карнеги-Меллон. Информацию, касающуюся института SEI и модели СММ, можно получить на Web-сайте института SEI по адресу: www. sei.cmu. edu. Модель развития функциональных возможностей является основой, которая мо жет использоваться для получения оценки, в какой степени заданная организация Глава 6. Вопросы объединения процессов тестирования... 151 способна изготовлять программное обеспечение. Она классифицирует процесс раз работки программного обеспечения по пяти уровням развития: начальный, повто ряемый, определяемый, управляемый и оптимизирующий. Краткие характеристики каждого из этих уровней приводятся в таблице 6.1. Характеристики, перечисленные в таблице 6.1, описывают ключевые свойства уровней 1-5. Уровень детализации, предложенный в таблице 6.1, намеренно выбран низким. Подобный выбор обусловлен необходимостью дать общее представление об организациях, находящихся на каждом из пяти уровней. Например, организация, расположенная на уровне 1 модели СММ, т.е. на начальном уровне, разрабатывает программное обеспечение с использованием неопределенных и непланируемых про цессов. Скорее всего, эта организация не способна соблюдать сроки разработки, об наруживать и устранять все дефекты программного продукта перед его выпуском и укладываться в рамки сметной стоимости. Организации, достигшие уровня 2 модели СММ, вложили существенные средства в совершенствование реализуемых ими про цессов, и во время планирования, оценки и составления календарных планов руково дствуются четкими принципами управления ходом проектирования, тем самым дос тигая поставленных целей. Можно вполне рассчитывать на то, что организации вто рого уровня, по сравнению с организациями первого уровня, лучше справляются с задачами соблюдения срока разработки, обнаружения и исправления дефектов, рав но как и более точно управляют окончательной стоимостью проекта. По сравнению с хаосом, присутствующим на уровне 1, уровень 3 привносит суще ственные улучшения. На уровне 3, т.е. на определяемом уровне, тестирующая органи зация, скорее всего, реализует большую часть методов, обсуждаемых в данной книге, а именно: управление требованиями, достоверные оценки, составление графиков работ, управление конфигурациями, а также инспекции и пересмотры. Согласно мо дели СММ, определяемый уровень представляет собой высокий уровень эффектив ности организации, однако управление процессом осуществляется скорее на основе качественных, а не количественных оценок. На этом уровне все еще не установлены надежные системы измерений, пригодные для оценки качества программного про дукта или эффективности процесса. Два последних уровня модели СММ предусматривают плановые и текущие изме рения качества продукта и эффективности процесса. Основные различия между уровнями 4 и 5 заключаются в том, что основное внимание на уровне 5 уделяется не качеству программного продукта, а эффективности процессов. Продвижение к уров ню 5 означает, что организация собрала достаточное количество данных, позволяю щих ей воспользоваться средствами настройки своих процессов на достижение оп тимальной эффективности. Одним из ключевых свойств уровней 4 и 5 является при менение метрик тестирования. Использование упомянутых метрик подробно обсуж дается в главе 11. В дополнение к описанию пяти уровней функционального развития организаций, занимающихся разработкой программного обеспечения, модель СММ определяет 18 областей обработки, распределенных по всем пяти уровням. Области КРА (Key Proc ess Areas— ключевые области обработки) для заданного уровня функционального развития суть полностью действующие процессы, которые в любой момент времени должны находиться в полной функциональной готовности. О н и направлены на то, чтобы организация могла претендовать на соответствующий уровень. 152 Часть I. Процесс быстрого тестирования Таблица 6.1. Характеристики модели развития функциональных возможностей Уровень Наименование развития уровня Характеристики Уровень 1 Начальный В большинстве случаев процесс не определен и не рассчитан на серийное производство. Как правило, отсутствуют форма лизованные процедуры, планы проектов, а сметы не состав ляются. Если все же такие процедуры существуют, то отсутст вует такой механизм управления, который обеспечил бы их использование. В критических ситуациях формальные проце дуры не используются. Контроль внесения изменений практи чески отсутствует. Кодирование и тестирование выполняются без определенного плана. Проекты, пересмотры и анализ ре зультатов тестирования считаются непозволительной роско шью. Руководство организации имеет смутное представление о проблемах. Уровень 2 Повторяемый Разработка ведется в соответствии с планом. Установлена система управления проектом, обеспечивающая поддержку планирования и отслеживания. Организована группа обеспе чения качества, дающая гарантию руководству, что работа ведется в рамках заданного процесса и в соответствии с пла ном. Для программного обеспечения проводится контроль внесения изменений. Сметные требования и требования со блюдения графиков работ поддерживаются до тех пор, пока не внедряются новые инструментальные средства и новые мето ды, и если не предпринимаются крупные изменения внутри самой организации. Уровень 3 Определяемый В процессы, реализуемые на уровне 2, вносятся дополнитель ные усовершенствования. Организуется группа поддержки процесса, которая сопровождает совершенствование текущего процесса. Определен жизненный цикл разработки, который приводится к конкретным нуждам организации и к текущему проекту. Постоянно применяется семейство методов проекти рования, в числе которых методы формального проектирова ния и методы тестирования. Организация, поднявшаяся до этого уровня, приобретает фундамент, обеспечивающий серь езное и долгосрочное развитие. Однако каким бы ни был эф фективным этот уровень, он остается качественным уровнем. На этом уровне существует мало средств для количественной оценки того, что делается, и насколько эффективным оказы вается процесс. Уровень 4 Управляемый В дополнение к усовершенствованиям, внесенным на преды дущем уровне, реализуется целый ряд измерений с целью предоставления возможности выдать количественную оценку стоимости и достоинств главного процесса. Устанавливается и поддерживается база данных процесса. Отслеживается про движение в направлении достижения целей качества для кон кретных программных продуктов, причем соответствующие сведения направляются руководству. Основное внимание на этом, впрочем, как и на всех предыдущих уровнях, уделяется качеству продукта. Глава 6. Вопросы объединения процессов тестирования... 153 Уровень развития Наименование уровня Характеристики Окончание табл. 6.1 Уровень 5 Оптимизирую- На этом уровне происходит смещение акцентов. Основное щий внимание теперь уделяется не качеству программного продук та, но оптимизации процесса. На этом уровне становятся дос тупными данные, которые можно использовать для настройки самого процесса, т.е. можно не принимать во внимание огра ничения, накладываемые одним или двумя какими-либо проек тами. На оптимизирующем уровне организация получает в свое распоряжение средства, позволяющие выявлять и ис правлять наиболее слабые элементы процесса. Например, названиями областей КРА для уровня 2 [38] являются: • Управление требованиями • Планирование проекта программного обеспечения • Контроль и отслеживание разработки проекта программного обеспечения • Управление договорами с субподрядчиками на разработку программного обес печения • Обеспечение качества программного обеспечения • Управление конфигурацией программного обеспечения. Подробное описание областей КРА мы оставляем на публикации, посвященные моделям СММ. В то же время может оказаться полезным концептуальное отображе ние областей КРА уровня 2 на процессы тестирования, описание которых было дано в предыдущих главах настоящей книги. Попытка такого отображения предпринима ется в следующем разделе. Как модель СММ соотносится с быстрым тестированием Путь от уровня 1 к уровню 2 в соответствии с моделью СММ лежит через реализацию областей КРА, список которых можно найти в предыдущем разделе. Первым рас сматривается процесс управления требованиями. Роль, которую играет группа тестиро вания в управлении техническими требованиями, была главной темой главы 2. В этой главе отмечалось, что группа тестирования должна получить доступ к точным специ фикациям требований на ранних этапах разработки программного продукта, чтобы иметь основу для составления плана проведения испытаний и для проектирования тестов. Были приведены аргументы в пользу участия группы тестирования в процессе формулирования технических требований за счет выполнения статического тести рования требований на предмет полноты, непротиворечивости, осуществимости и контролепригодности. Кроме того, была также обоснована необходимость использо вания матрицы прослеживаесмости требований с целью отображения каждого тре бования на тесты, отдельные компоненты проекта и на программные коды. В главе 8 приводится описание процесса JAR, представляющего собой методоло гию выявления требований, которая в полной мере интегрирует статическое тести рование и процесс формулирования требований. Интегрирование статического тес тирования с определением и прослеживанием требований на этапах планирования 154 Часть I. Процесс быстрого тестирования испытаний и разработки тестовых случаев — это базовые принципы, которыми сле дует руководствоваться при определении роли группы тестирования в управлении требованиями. Вторая область КРА, согласно модели СММ принадлежащая уровню 2, — это пла нирование проекта. Применительно к организациям, занимающимся тестированием, эта область охватывает оценку трудозатрат, разработку графиков работ и планов проведения испытаний. Составление плана проведения испытаний и оценка трудоза трат достаточно подробно рассматривались в главе 3, а вот дополнительная инфор мация по технологиям оценки трудозатрат содержится в главе 12. Пример плана про ведения испытаний представлен в главе 14. В результате обсуждения вопросов, свя занных с планированием испытаний, был сделан вывод, что к основным видам дея тельности, которые составляют процесс планирования испытаний, относятся: • Определение стратегии тестирования • Определение состава испытательного комплекса (программные и аппаратные средства) • Оценка трудозатрат (трудовые ресурсы и графики работ) • Оценка рисков срыва графиков работ и подготовка плана смягчение последст вий от овеществления рисков • Подготовка и пересмотр документов, содержащих план проведения испы таний. В то время как очередность, в которой организация рассматривает области КРА, зависит от локальных условий, есть все основания сначала решать вопросы управле ния требованиями, а после этого переходить к планированию проекта. Причина очень проста — в основе этого плана лежат требования. По мере изменения требова ний, план должен модифицироваться, дабы соответствовать произведенным изме нениям. Третьей областью КРА в модели СММ является контроль и отслеживание разработки проекта программного обеспечения. Для группы тестирования это означает, что инфор мация о ходе тестирования и ожидаемом качестве продукта в том виде, в каком она представлена в сообщениях о дефектах, должна в любой момент быть доступной ру ководству. Эти вопросы рассматривались в главе 5 при обсуждении отчета о ходе ра бот по тестированию и отчета об обнаруженных дефектах. Если быть точным, то но вейшая информация доводится до сведения заинтересованных лиц на еженедельных (а в критических ситуациях, ежедневных) совещаниях. Если эта информация пере сылается на внутренний Web-сайт, то действия группы тестирования должны соот ветствовать предназначению этой области КРА. Поскольку для отслеживания проек та должен существовать план, вполне очевидно, что эта область КРА зависит от кор ректного выполнения КРА, предусмотренного планированием проекта. Область КРА, именуемая управлением договорами с субподрядчиками на разработку про граммного обеспечения, до сих пор еще не рассматривалась. Тем не менее, она может иметь очень важное значение для групп тестирования, которые используют услуги субподрядчиков во время выполнения различных видов тестовых работ: при состав лении планов проведения испытаний, при разработке тестов и/или при прогоне тестов. Нередки случаи, когда одна или большее число географически удаленных групп заключают договор на выполнение определенной части работ по тестирова- |