Home

Источник: журнал BetterSoftware (October 2005)
Перевод: Артём Ваулин

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

Для многих начинающих тестировщиков, а также тест-менеджеров (да и для меня самого в какой-то момент времени) постановка процесса тестирования, внедрение множества стандартов с длинными и красивыми названиями, внедрение средств автоматизированного тестирования и т.д. становится самоцелью, основным видом деятельности, становится наукой ради науки, что может привести к плачевным последствиям как для программного продукта, так и для проекта в целом.

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

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

Правильно кто-то из великих сказал: «Каждому проекту своя методология!» Мы же начнем с малого — каждому проекту свой набор метрик, и у каждого следствия должна быть своя причина. Читайте статьи Алана Пейджа (Alan Page) и Ли Копеланда (Lee Copeland).

Измерения, которые нужны

Alan Page

Alan Page является тест-архитектором в Microsoft Engineering Excellence Group, где он работает с командами разработки компании для определения и распространения лучших практик в тестировании.

Несколько месяцев назад я присутствовал на статусном совещании среднего по размеру проекта по разработке ПО. Продукт приближался к пятому релизу и включал около пяти миллионов строк кода. Руководитель проекта, Ларри (Larry), был новым человеком в компании, но имел годичный опыт разработки ПО для корабельной отрасли. Рон (Ron), тест-менеджер, имел меньший опыт в данной отрасли, но уже участвовал в проектной группе в двух предыдущих релизах.

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

Список метрик был гигантский. Его команда измеряла два различных типа покрытия кода, семь различных представлений отчетов с тест-кейсами, более десяти различных метрик производительности, а также множество различных типов метрик ошибок. Команда отслеживала и заносила в отчет данные, собранные с помощью автоматизированных средств статического и динамического анализа. Метрики были представлены данными от поддержки продукта, с сайтов клиентов и внешних пользователей. Количество собранных данных было огромным. Рон «прогуливался» по таблице, выделяя статус каждого измерения. Он давал краткое разъяснение для каждой зеленой области, и объяснял как и когда каждая желтая и красная метрика должна достичь зеленого статуса. Все были ошеломлены количеством доступных данных, но большинство думало, что данных было достаточно для представления качества продукта.

В этот момент Ларри, руководитель проекта, спросил Рона о том, уверен ли он, что в определенном компоненте обеспечена необходимая надежность. Рон ответил, «Я не уверен. Мы не отслеживаем такие вещи».

«Хмм…», ответил Ларри. «Рынку действительно необходима надежность данных для этого компонента. Фактически, статистика надежности для этого компонента и соответствие компонента критериям производительности — две самых важных цели этого релиза. Кстати,» — продолжил Ларри — «есть ли у тебя данные по производительности этого компонента?»

Рон, который сейчас был слегка взволнован, заикался, «Большинство из этого — вещи, которые мы уже измерили. Другие вещи кажутся интересными для измерения. Нам необходимо измерять настолько много, насколько мы можем по ходу проекта.»

«Давайте поговорим об этом после совещания», сказал Ларри. «У меня есть несколько других подходов, над которыми Вам необходимо подумать.»

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

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

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

Система GQM состоит из трех шагов:

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

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

Например, считаем, что одна из целей вашего проекта — улучшение качества кода. Одним из вопросов для этой цели может быть «Каковы индикаторы качества кода?» Метрики, поддерживающие этот вопрос, включают количество ошибок, количество определенных типов ошибок, количество возвратов, результаты покрытия кода или отношение прошедших тестов к провалившимся. Не существует магических метрик и один и тот же набор метрик не будет поддерживать похожие цели для всех. При адаптации целеориентированных метрик маловероятно, что вам не придется определять метрики кроме тех, которые уже собираются.

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

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

Несколько ключевых моментов для запоминания того, как разработать вашу программу:

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

Читайте продолжение материала: Случай потерянного «IF»