Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Используй только то, что действительно необходимо
30.09.2008 10:03

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

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

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

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

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

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

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


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

Alan Page

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

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

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

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

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

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

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

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

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