Home

Автор: Майкл Болтон
Перевод: Дмитрий Дудников по заказу Software-Testing.RU
Оригинал: http://www.developsense.com/articles/2009-07-ThreeKindsOfMeasurement.pdf

Люди часто цитируют лорда Кельвина: «Если вы можете измерить то, о чем говорите, и выразить это в цифрах – значит, вы что-то об этом предмете знаете. Но если вы не можете выразить это количественно, ваши знания крайне ограничены и неудовлетворительны. Может это начальный этап, но это не уровень подлинного научного знания, каков бы ни был предмет исследования» [1]. Однако немногие обращают внимание на предложение, которое предшествует этому высказыванию: «в естественных науках важнейший первый шаг в направлении изучения любого предмета – это нахождение принципов численного выражения и осуществимых способов измерения величин, связанных с ним». Это пропущенное предложение ставит перед нами несколько вопросов: «Применимы ли в области разработки и тестирования компьютерных программ принципы измерения, подобные тем, что мы используем в физике? Если нет, то какие виды измерений нам следует использовать? Как нам извлечь пользу из этих измерений?».

Джеральд (Джерри) М. Вайнберг предлагает мыслить в терминах трех широких категорий [2]. По его мнению, измерения первого порядка необходимы нам для того, чтобы начать действовать: «они в точности соответствуют задаче что-то сделать». Измерения первого порядка являются, как правило, качественными (не количественными), быстрыми и недорогими; в большинстве случаев они не требуют механизмов или устройств, позволяющих расширить границы наблюдаемого или улучшить результаты наблюдений. В недавней беседе Джерри сказал мне, что измерения первого порядка «являются экономными или даже максимально дешевыми и могут быть использованы без особого труда. Они могут дать вам массу важной информации, которая может вести к другой информации, а в идеале – к немедленным действиям, если они необходимы» [3].

Когда мы ведем машину, мы большую часть времени производим измерения первого порядка. Мы смотрим в окно, слушаем звук двигателя и чувствуем ускорение и торможение. Мы производим наблюдения и сравнения, не утомляя себя количественными вычислениями. «Дорога сухая. Облачно. Справа есть движение, а у машины впереди загорелись стоп-сигналы». Измерения первого порядка дают ответы на вопросы «что происходит вокруг меня?» и «что мне нужно сделать сейчас?». В этой ситуации, если вам кажется, что вы едете слишком быстро, то вероятнее всего так оно и есть. В этом случае измерений первого порядка достаточно, чтобы дать информацию для немедленного действия: начать торможение.

Поскольку измерения первого порядка основываются на непрерывно поступающих ощущениях, а не на аккуратных экспериментах и контролируемом потоке входных данных, разумное использование предполагает рассмотрение возможных интерпретаций значений и важности того, что мы наблюдаем. Предположим, вам кажется, что вы едете быстро, но не слишком. И вдруг вы замечаете впереди красно-синие мигающие огни. Дополнительные данные говорят вам, что вы не уверены в соблюдении дозволенной скорости. Ситуация и измерение первого порядка приводят к реакции в виде следующего вопроса: «Что еще мне необходимо выяснить? Куда нужно посмотреть?». В этот момент вы переходите к измерению второго порядка и смотрите на спидометр.

«Измерения второго порядка», - говорит Джерри, «это измерения, которое инженеры используют для настройки относительно стабильных систем, делая их дешевле, сильнее, легче, надежнее, быстрее или медленнее, в зависимости от того, что требуется». Измерения второго порядка отвечают на вопросы «что на самом деле происходит?» и «как это меняется?», тяготея к количественным оценкам, более точным моделям, и являясь в общем случае более трудоемкими, чем измерения первого порядка. Зачастую они производятся с использованием внешних инструментов, позволяющих дополнить или уточнить входные данные, полученные органами чувств. В частности метрики – математические функции, соотносящие посредством определенной модели объекты или события с числами – это измерения второго порядка.

Возвращаясь к примеру с машиной, можно сказать, что измерения второго порядка – это информация, которую вы получаете, глядя на приборную панель. Вы видите, что ваша скорость – шестьдесят пять километров в час, при том, что ограничение – пятьдесят. Ваше количественное измерение второго порядка говорит вам, что вы превысили установленный предел. Чувство испуга, вызванное появлением машины ДПС в совокупности с результатами измерения второго порядка, подсказывает вам замедлиться.

Что же представляют из себя измерения третьего порядка? Как говорит Джерри, «это разновидность точных численных измерений, помогающих физикам изучать законы природы. Они помогают ответить на вопрос «что происходит?» самым всеобъемлющим образом. Однако измерения третьего порядка могут быть точными только в том случае, если они относятся к очень простым системам (таким, как два взаимодействующих тела) или очень простым моделям сложных систем (в которых мы пренебрегаем большим числом размерностей системы, и тщательно анализируем очень небольшое количество показателей). Наверное, более всего измерения третьего порядка зависят от возможности устранения человеческого фактора – изменчивости, субъективизма и тенденциозности. Как отмечается в важной работе Кема Канера (Cem Kaner) и Уолтера П. Бонда (Walter P. Bond) [4], использование метрик и измерений высоких порядков зависит от конструктивной достоверности[1] - критической строгости в оценке моделей и функций, образующих основу для измерения.

В курсе «Быстрое тестирование» (Rapid Testing) мы определяем контрольную метрику как любую метрику, которая позволяет принять решение. Одни команды разработчиков используют следующий стандартный критерий: продукт готов к выпуску, если количество ошибок в нем ниже заданного порогового значения. Другие считают программу достаточно протестированной, если выполнен один положительный и один отрицательный тест на каждое «требование» (в смысле «на каждую запись в документе с описанием требований»). В то же время есть такие, которые считают команду тестирования «успешной», если процент отклоненных сообщений об ошибках достаточно низок.

Другая разновидность – наводящая метрика, это метрика, которая продуцирует новые вопросы: «У нас есть три открытых ошибки с высокой критичностью - в чем дело? Джим и Марк отстают на два дня от плана – нужна ли им помощь? Руководитель проекта откладывает много сообщений об ошибках – может быть эти проблемы несущественны, или нам требуется дополнительное обучение, поскольку мы не понимаем продукт?».

Один из моих недавних клиентов оценивал качество своих продуктов и удовлетворенность заказчика посредством набора из пяти показателей второго порядка. В каждом из показателей он сводил месяцы работы и гигабайты данных в одно число. «Хорошие» значения заслуживали похвалы, за «плохие» можно было получить выговор, поэтому на затяжных совещаниях менеджеры занимались тем, что пытались объяснить изменения, произошедшие с последнего месяца – особенно, если дела пошли хуже. В этой компании графики зачастую срывались, а выпуски продукта задерживались. А когда я задал тестировщикам простой вопрос: «Что вас тормозит?», я получил массу информации. Они рассказали мне про неработающие и полные ошибок сборки, неадекватные тестовые среды, излишне подробные тестовые сценарии, устаревающие к тому моменту, когда продукт готов к тестированию, и про недостаток информации о реальных потребностях заказчика. Также они рассказали о том, что они тратят уйму времени на сбор данных, которые совершенно не используются в дальнейшем для ускорения разработки или тестирования, а также сообщили десятки способов подтасовки этих данных.

Другой клиент, использующий годичный цикл разработки продукта, сосредотачивался на таких вопросах как «что произошло на этой неделе?», «что нам удалось сделать?», «с какими проблемами мы столкнулись?». Менеджеры использовали личные контакты – прямое наблюдение или беседы с людьми – в качестве основного способа оценки статуса проекта. Они собирали довольно много численных показателей, однако использовали их в качестве индикаторов для уточнения первоначальных оценок и постановки новых вопросов первого порядка. Команда делала грубые долгосрочные оценки и более точные краткосрочные, разделяла двухнедельные циклы на двухдневные (или даже еще более короткие) задачи с понятными результатами, достижение которых свидетельствует о выполнении задачи. Если задачи не выполнялись в запланированное время, никого не наказывали, наоборот, каждый задумывался над тем, чего он не заметил раньше, что он узнал, и что могло бы помочь в следующий раз сделать более точную оценку. Члены команды не собирали показатели, которые не были интересны и важны им прямо сейчас. Они были заинтересованы в понимании ситуации и улучшении качества работы, а не в том, чтобы выставить себя в более выгодном свете за счет достижения хороших показателей. Результаты каждой игры и всего сезона были для них важнее, чем таблицы с личным зачетом. И они постоянно выпускали высококачественные продукты вовремя.

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

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

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

Ссылки:

[1] Thomson, William (Lord Kelvin). “Electrical Units of Measurement.” Popular Lectures and Addresses I (London, 1981-94).

[2] Weinberg, Gerald M. Quality Software Management, Vol. 2: First-Order Measurement. Dorset House Publishing, New York, 1993.

[3] Weinberg, Gerald M. Personal correspon­dence with the author, May 18, 2009.

[4] Kaner, Cem and Walter P. Bond. “Software Engineering Metrics: What Do They Measure and How Do We Know.” 10th International Software Metrics Symposium. Chicago, IL, 2004. www.kaner.com/pdfs/metrics2004.pdf

[5] Weinberg, Gerald M. Quality Software Management, Vol. 1: Systems Thinking. Dorset House Publishing, New York, 1991

[1] Степень соответствия структуры системы ее конечным целям