Home

Автор: Гринкевич Сергей

Статья написана по мотивам доклада, сделанного автором на конференции “Российские Интернет технологии 2007″ (РИТ2007) в апреле 2007 года в Москве.

Оригинальная публикация

Краткое описание:

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

В чем заключается экономическое обоснование необходимости тестирования программ?
Какой набор тестовых активностей минимально достаточен?
Что нужно делать, чтобы управлять процессом и, следовательно, бюджетом проекта?

Эти и другие вопросы я постараюсь осветить в своей статье.

Тезисы доклада:

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

Но что делать тем, кому не нужны международные сертификаты? Существует ли некое оптимальное соотношение цены/качества в тестировании программного обеспечения? Как создать службу контроля качества «с нуля»? Вопросы, вопросы, вопросы…

Этап 1. Установка процесса

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

Чтобы определить, существует ли у вас процесс тестирования в полном объеме предлагаю выполнить небольшой тест - тест Гринкевича. Всего шесть вопросов.

1. Есть ли у вас тестировщики (роль в проекте)?
2. Есть ли у вас сформулированная стратегия тестирования?
3. Используется ли система учета дефектов?
4. Есть ли у вас изолированное тестовое окружение?
5. Применяется ли процедура передачи новой версии программы в тестирование?
6. Есть ли у вас процедура оценки готовности программы?

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

Если вы ответили утвердительно на все приведенные вопросы, поздравляю вас! Ваши инвестиции, как минимум, оправданы и не пропадут зря. У вас есть базовый процесс, который может быть усовершенствован или “взращен” до любого уровня международного стандарта CMMI.

Этап 2. Оптимизация процесса

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

Этап 3. Управление процессом

Когда речь идет об управлении автомобилем, то процесс управления понятен и очевиден. Термин «управление» подразумевает, что вы, когда захотите, можете тронуться с места, остановиться, обогнать или перестроиться в другой ряд. И вы в любой момент времени можете точно определить, что именно происходит с вашим автомобилем. Датчики машины информируют вас о скорости движения машины, а дорожные знаки - об ограничениях. Любое несоблюдение правил дорожного движения может закончиться аварией или встречей с милицией. Другими словами, если вы не соблюдаете правила и/или не соблюдаете процесс, то риск наступления негативный последствий возрастает. Чем злостнее нарушение, тем риск выше.

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

Именно в определении и минимизации рисков заключается ключевая роль тестирования. Очевидно, что протестировать программу на 100% невозможно. Это доказано математически. Следовательно, осуществляя тестирование приходится оперировать ограниченными ресурсами (человеческими, финансовыми, временными). Чтобы делать это эффективно, необходимо строить обоснованные планы, намечать оптимальные показатели и добиваться максимального приближения к этим показателям в процессе создания программы.

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

Однако, здесь кроется множество подводных камней. С одной стороны, есть соблазн свести все измерения к простым показателям. Например, количество найденных дефектов. Кто больше нашел, тот и круче. Значит ему бонус. В реальности все значительно сложнее. Рекордсмену по нахождению дефектов может быть попался неопытный разработчик, который два дня как со студенческой скамьи.

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

Обсудить в форуме