Глава 3. Планирование испытаний 77
Оценка превосходит фактическую стоимость в 4 раза
Оценка превосходит фактическую стоимость в 2 раза
Фактическая
стоимость
Оценка превосходит фактическую стоимость в 1/2 раза
Оценка превосходит фактическую стоимость в 1/4 раза
Начало проекта Завершение проекта
Рис. 3.4. Точность оценки. По материалам [40]
Определение задач
Простейший способ получения списка задач предусматривает просмотр документов, в которых сформулированы требования, и выписывание всех выполняемых работ, чтобы затем проверить функции, определенные этими требованиями. Как только список будет определен, составляющим его задачам присваиваются приоритеты. В качестве руководящих принципов в отношении приоритетов функций должны ис
пользоваться документы, содержащие формулировки требований. В то же время мо
гут возникать и дополнительные соображения, оказывающие влияние на выбор при
оритета. Например, некоторые из программных кодов, реализующих ту или иную функцию, при переходе на новую версию программного продукта могут претерпевать лишь незначительные изменения, тогда как другие функции в новой версии появля
ются впервые. По-видимому, новому программному коду имеет смысл посвятить повышен
ное внимание, нежели модифицированному коду. Кроме того, придется уделить больше времени на проверку проектных решений и структуры, а также на отладку нового кода.
В дополнение к обычному просмотру требований необходимо учесть задачи, ко
торые не имеют прямого отношения к документам с требованиями, но то же время делают тестирование возможным. Например, неплохо было бы включить в указан
ный выше список такие задачи:
• Составление плана проведения испытаний
• Пересмотр плана проведения испытаний
• Разработка тестовых случаев
• Отладка тестовых случаев
• Проверка исправления дефектов
• Определение тестов и показателей программного продукта и процесса их сбо
ра и использования
Начальная стадия планирования завершена
78 Часть I. Процесс быстрого тестирования • Статическое тестирование: проверка и пересмотр проектов программных средств и кодов
• Реализация выбранной стратегии автоматизации тестирования в разумных пределах
• Пересмотр пользовательской документации
• Приобретение оборудования, необходимого для реализации данного проекта, как составная часть стратегии создания универсальной испытательной лабора
тории
• Прием на работу специалистов по различным профилям тестирования необхо
димой квалификации
• Освоение специалистами по тестированию новых технологий и новых инстру
ментальных средств
• Прогон тестов и отчеты по результатам тестирования
• Проведение проверок готовности
• Оценка выполнения проекта.
После построения исходного списка полезно его просмотреть вместе с группой тестирования и мысленно пройти через полный цикл разработки жизненного цикла, определяя необходимые компоненты и задачи, которые должны выполняться для нужд группы тестирования. По всем признакам список задач является динамическим документом, претерпевающим изменения на стадии планирования и, скорее всего, на протяжении всего жизненного цикла тестирования по мере роста понимания того, что должно быть сделано.
Список задач имеет еще одно название — список WBS (Work Breakdown Structure — декомпозиция работ). Декомпозиция работ часто менее формальна, чем описанный выше список задач, с другой стороны, она может выглядеть как иерархически упоря
доченный список видов деятельности, в которых каждой задаче присваивается "деск
риптор" или идентификатор. Дескриптор позволяет отслеживать задачу на протяже
нии всего жизненного цикла разработки и предоставляет возможность связывать измерения трудозатрат или расходов с различными задачами. Благодаря этому можно снимать наборы показателей, характеризующих фактические затраты на протяжении всего проекта. Разумеется, больше формальностей и больше отчетности означают большие накладные расходы в смысле времени и стоимости, поэтому следует найти разумный компромисс между уровнем детализации планирования и организацией проекта. Обычно компромисс в таких случаях достигается за счет использования ин
струментальных средств организации проектов, подобных, например, Microsoft Pro
ject, во время планирования и отслеживания трудозатрат на тестирование. Отдавая предпочтение тому или иному инструментальному средству, следует убедиться, что его вход и выход
совместимы с инструментальными средствами, которые применяют другие группы.
Для целей быстрого тестирования список задач должен быть точным и содержать все крупные задачи, особенно те, которые требуют времени на подготовку, напри
мер, приобретение необходимого оборудования, прием на работу квалифицирован
ного персонала или его обучение, а также проектирование тестов. Игнорирование этапа подготовки к выполнению крупной задачи перед тестированием может привес-
80
Часть I. Процесс быстрого тестирования
Например, нет никаких оснований полагать. что каждый игполнигепь посвятит поручен-
ной плановой задаче в 40 и более часов в неделю на протяжении всего срока разработки
проекта. В таком случае не останется времени на совещания, подготовку и обмен ин
формацией. Н а х о д и м о располагать временем на отладочные тесты, на решение ме
дицинских проолгм и даже проблем личного харакгера.
Последняя позиция списка требует дополнительных пояснений. Прежде чем дополни
тельно подключать людеи с целью сокращения сроков решения той или иной задачи
следует определить какую задачу можно разделить на подзадачи [40]. Например'
движущиеся автомобилем может управлять только один человек, поэтому Задача
управления автомобилем не допускает разбиения на подзадачи. Для задач, которые
расходов.
Ь Н Э П О А З а д а ч и
'
н
*°°*одимо «следовать две составляющих накладных
расходов, подготовку исполнителей, дополнительно привлеченных к решению задачи и
обмен информацией между исполнителями, которые одновременно работают над од
ной и той же задачей. Процесс подготовки исполнителей не допускает разбиения на час
ти, так что трудозатраты на подготовку большего числа исполнителей возрастают в ли-
неинои зависимости от количества привлеченных исполнителей.
Возможные пути обмена информацией между исполнителями показаны на рис 3 5 Если
над задачей работает один исполнитель, то накладные расходы, обусловленные необхо
димостью обмена информацией, отсутствуют. Если дополнительно привлекается один
исполнитель, то между двумя исполнителями добавляется двунаправленный компонент
обмена информацией. Если к решению задачи привлекается третий исполнитель трудо
затраты на обмен информацией возрастают втрое по сравнению со случаем участия
двух исполнителей. Трудозатоаты. связанные с обменом исполнителями информацией
не подчиняются линейной зависимости от количества привлеченных исполнителей но
возрастают в соответствии по формуле п(п-1)/2 [40].
В общем случае, две наиболее распространенных ошибки, связанные с привлечением
дополнительных
р а б
°
Т Н И К О В
для цокращения сроков сдачи проекта, заключаются в при
пренебрежении разделения на подзадачи и
ч
:
е
У
н Г б Х е \ Г н Г о Т е
е
н о к
П
:
О С О б Ы
"
Р
е
О
Д
< перечисленных выше трудностей и полу-
• Начинать следует с однозначно определенных "зафиксированных" требований.
• Основывать предположения и планы снижения рисков на результатах аналогичных
проектов. выполненных ранее "
• Использовать реалистичные оценки ожидаемой экономии времени от привлечения к
решению конкретных задач дополнительного персонала.
Врезка 3.2.
Ниже даются описания ряда распространенных технологий оценивания трудоза
трат в порядке возрастания их сложности. Однако следует иметь в виду, что более сложные технологии не обязательно дают более точные оценки. Любая технология оценивания зависит от квалификации и опыта использующего ее работника и для того, чтобы получить представление о точности той или иной технологии необходи
мо проверить ее на статистических данных.
Глава 3. Планирование испытаний 81
Рис. 3.5. Обмен информацией между исполнителями
1. Учет ограничений, накладываемых финансовой сметой или графиком вы
полнения работ. Возможны случаи, когда свобода выбора необходимого чис
ла исполнителей отсутствует или когда заданы жесткие сроки разработки проекта. В этих условиях оценка трудозатрат также нужна, однако ее резуль
таты будут другими. Например, может быть установлен жесткий срок прове
дения испытаний, однако при этом остается возможность выбора количества исполнителей этого задания. В этом случае следует рассмотреть возможность выполнения только задач с наивысшим приоритетом и одновременного вы
полнения максимально возможного числа задач. Однако в подобных ситуаци
ях важно так определить ограничения и риски, связанные с тестированием, чтобы они соответствовали оценке трудозатрат.
2. Аналогия с предыдущими проектами. Если разрабатываемый программный продукт является очередной версией из последовательности итеративных версий или имеет много общего с некоторым завершенным программных продуктом, то в ряде случаев можно воспользоваться статистическими дан
ным ранее разработанного проекта. При этом важно, чтобы были известны фактические издержки на разработку старого проекта, а условия разработки старого проекта должны максимально соответствовать условиям разработки нового проекта. Например, над обоими проектами должно работать одно и то же число исполнителей либо исполнители должны обладать одной и той же квалификацией.
3. Экспертная оценка. Количество исполнителей или сроки, необходимые для выполнения требуемых задач, подсчитывают один или большее число экспер
тов. Этот метод может выглядеть очень просто, когда эксперт записывает свою оценку на листике бумаги, или же очень сложно, когда требуется консен
сус всех принимающих в нем участие (примером может послужить технология
Wideband Delphi). Краткое описание технологии Wideband Delphi приводит
ся во врезке 3.3.
82 Часть I. Процесс быстрого тестирования Методы декомпозиции. Если программный продукт достаточно крупный и сложный, по всей вероятности, получение оценок трудозатрат на разработку и тестирования этого продукта, потребует больших затрат времени и усилий
Вполне вероятно также, что в данной ситуации будет назначен руководитель проекта, ответственный за соблюдение финансовой сметы и графика выпол
нения работ всего проекта, а от группы тестирования потребуется предостав
лять руководителю проекта исходные данные в специальном формате. Руко
водитель проекта может поручить каждой группе специалистов дать собст
венную оценку затрат с применением одной из описанных выше технологий.
С другой стороны, руководитель может воспользоваться более унифициро
ванным подходом, в рамках которого программный продукт
разбивается на блоки либо по количеству строк кода, либо по функциональным баллам, а затем к блокам применяется некоторый оценочный алгоритм. Если используется именно такой подход, то группе тестирования целесообразно получить собст
венную независимую оценку, скажем, экспертную, и убедиться в том, что при
менение алгоритмического подхода имеет смысл.
Модели эмпирического оценивания. Существует множество моделей оцени
вания, которые могут использоваться для вычисления затрат на разработку проекта по созданию программного продукта. В основу этих моделей положе
но количество строк программного кода (LOC - number of lines) или функ
циональные баллы (FP - functional points), причем для одних и тех же исход
ных данных эти модели дают разные результаты. Ключевым условием внедре
ния любой из моделей является калибровка модели относительно локальных условий за счет ее применения на завершенных проектах и настройка ее на фактические данные так, чтобы она выдавала предсказуемые результаты. В главе 12 можно найти подробную информацию о широко распространенной технологии оценивания СОСОМО.
ПОДГОТОВКА ОЦЕНКИ ЗАТРАТ НА ТЕСТИРОВАНИЕ Действия, которые рекомендуется выполнять при проведении оценочных работ пере
делены ниже Рассматриваемая процедура, представляющая собой версию процесса
W.deband Delphi Estimation Process, должна осуществляться на раннем этапе процесса планирования. Этобудет гарантировать, что вас окажется достаточно времени на выпол
нение каждого действия.
Подготовка. Подготовьте формуляры для входных данных, предназначенные для сбора и документирования оценок. Подготовьте краткий пояснительный материал,
объясняющий исполнителям, как проводить соответствующие работы и что от них ожидать,
Вступительное совещание. Созовите вступительное совещание для консультаций по про
цессу оценивания и распределите новые обязанности между членами рабочих групп чтобы они смогли разобраться с этими обязанностями и при необходимости объяснять их во время рабочих совещаний. Покидая это совещание, члены групп исполнителей должны иметь в своем распоряжении списки элементов, подлежащих оценке, и пони
мать, как оценка выполняется. Хорошо подумайте, прежде чем пропускать это дейст
вие - оно ставит исполнителей в равные условия и препятствует возникновению ошибок из-за нечеткого понимания самого процесса либо оцениваемых элементов.
Надомная работа. Исполнители делают индивидуальные оценки. Предоставьте участни
кам время, достаточное для ознакомления с новыми функциями очередной версии про
граммного продукта.
Глава 3. Планирование испытаний 83 В то же время, крайне нежелательно, чтобы кто-то из исполнителей размышлял дольше других и не мог обмениваться данными с другими. Убедитесь в том, что члены исполни
тельных групп понимают, что оценивают количество часов (или дней), необходимых для решения той или иной задачи при условии, что ресурсы для решения этой задачи у ж е имеются. Кроме того, убедитесь, что исполнители знают, как пользоваться единицами измерения (человеко-часы, человеко-дни).
Рабочее совещание. Созовите рабочее совещание для проверки и пересмотра оценок.
Председатель совещания производит сбор оценок и заносит их в специальный сводный формуляр оценок. Сводные оценки возвращаются группе исполнителей для обсуждения и пересмотра. Группа проводит обсуждение оценок, причем каждый член группы мо
жет иметь на этот счет собственное мнение, после чего пересмотренная оценка воз
вращается председателю совещания. Процесс может продолжаться до тех пор, пока никто из участников не захочет менять свои оценки, либо оценки окажутся в пределах разумного компромисса, либо время, отпущенное на рабочее совещание, истечет. Со
вещание такого рода не может длиться дольше двух часов — если оно длится дольше, то его результаты окажутся размытыми. Во время рабочего совещания могут возникать новые проблемы, которые нельзя решить в ходе совещания. Назначьте ответственных за их решение.
Решение проблем. Если после рабочего совещания остаются нерешенные проблемы, примите меры по их решению либо созовите еще одно рабочее совещание, либо, если они затрагивают интересы не очень многих исполнителей, обсудите новую информацию с подгруппами, которые осведомлены в соответствующих вопросах. Скорректируйте оценки на базе новой информации.
Получение общей оценки. Изучите сводный формуляр оценок и отыщите для каждой задачи минимальную и максимальную оценки затрат. Возможно, на основе собственно
го опыта или статистических данных по другим проектам удастся отбросить резко отли
чающиеся значения как нереалистичные. Сложите максимальные и минимальные оценки для получения оценки трудозатрат в масштабах всего проекта. В этом случае получают
ся два результата: оптимистическая, или "агрессивная", оценка (минимальное значение) и пессимистическая, или "умеренная", оценка трудозатрат (максимальное значение).
Задокументируйте все предложения, которые были сделаны в процессе получения окончательной оценки.
Преобразование оценки в график работ. Теперь, когда имеется оценка требуемых тру
дозатрат,
настала очередь ответа на вопрос, на который вы обязаны ответить. Когда бу
дет закончена работа? Одно из эмпирических правил ([33], с. 183) выглядит так:
Продолжительность графика работ в месяцах — 3,0 * человеко-часы
1/3
Разумеется, имеет смысл получить более точные сроки, нежели те, что вычисляются по этой незамысловатой формуле.
Врезка 3.3. Определение продолжительности задачи и построение графика работ
После того, как задачи определены, а трудозатраты на каждую задачу подсчитаны, потребуется определить время решения каждой задачи и исследовать первый разрез графика работ. Время, необходимое для выполнения задачи, называемое также про
должительностью, зависит от количества исполнителей, могущих трудиться над ней.
Если есть возможность привлечь к выполнению той или иной задачи более одного исполнителя, убедитесь сначала, что эта задача допускает разбиение на подзадачи — другими словами, выполнением этой задачи могут одновременно заниматься более одного исполнителя. Некоторые работы, подобные жарке бифштекса, не будут вы-
84 Часть I. Процесс быстрого тестирования полнены быстрее, если к ним вместо одного привлекаются несколько человек. Более подробный анализ этого вопроса можно найти во врезке 3.2.
После назначения на каждую задачу конкретных исполнителей следовало бы выяс
нить, какие задачи могут выполняться одновременно, а какие — только в определенной последовательности. Одним из факторов, которые должны исследоваться при составле
нии плана выполнения задач, является использование одного и того же оборудования. В вашем распоряжении может оказаться достаточно исполнителей, готовых выполнять работы одновременно, но вы должны также принять во внимание, насколько доступным будет оборудование. При наличии достаточного количества единиц совместно исполь
зуемого оборудования, возможно, придется построить график использования этого обо
рудования или базу данных обслуживания, которая будет контролировать работу испол
нителей, степень использования оборудования и время тестирования. Вопрос создания баз данных обслуживания подробно рассматривается в [33].
Задачи, выделенные ресурсы (время и оборудование) и продолжительность вы
полнения можно графически отобразить на гистограмме, пример которой показан на рис. 3.6. Такая гистограмма может использоваться для отображения ключевых этапов проекта, связанных со "знаменательными"
событиями в жизни проекта, как то: нача
ло тестирования, конец тестирования или дата поставки программного продукта. На рис. 3.6 эти этапы помечены значком +. На диаграмме, представленной на рис 3.6, приводятся только названия задач и связанные с ними даты. На более подробной гистограмме могут быть показаны ресурсы, выделенные для задачи, тексты, указы
вающие начальные и конечные даты, а также другая информация, имеющая отноше
ние к управлению выполнением проекта.
Рис. 3.6. Пример гистограммы 
Скачать 4.53 Mb.