Снижение вероятности возникновения дефектов

Тема испытаний и тестирования во всех моделях СМК зани­мает особое место, и написано на эту тему уже очень много.

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

Самым понятным действием для обеспечения качества ИТ-проекта, конечно, является увеличение степени покрытия тес­товыми сценариями функциональности внедряемой системы до 100 %.

Как этого достигнуть? Немного вспомним теорию [11]. Со­обществом тестировщиков и практической работой выделены основные типы тестов (рис. 2.10).

Современные руководства, такие как MSF [5], выделяют сле­дующие рекомендации к разработке тестов:

• все необходимые тесты должны быть готовы к моменту реа­лизации той или иной части программы, при этом обычно один тест соответствует одному требованию;

• совокупность ранее созданных тестов должна (при неизменных требованиях) выполняться на любой версии про­граммы;

• если в требования вносятся изменения, то тесты должны ме­няться максимально оперативно.

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

И это очень важно как раз для качества проекта в целом из-за снижения трудозатрат на переделки.

Конкретный пример. Разрабатывается приложение над БД, формочки уже готовы, можно начинать делать тесты, но бизнес-логика реализована не полностью, БД не готова.

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

Вообще процесс исправления ошибок имеет рефлекторный ха­рактер — уничтожение выявленной ошибки частенько приводит I к появлению новых и даже более серьезных проблем. И если

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

Как свидетельствует печальная статистика [11], каждое исправ­ление ошибки имеет 15 % вероятности породить новую ошибку. Поэтому надо взять за правило — чем раньше спроектирован тест, тем больше надежда на успех.

И лучше всего спроектировать тест еще на этапе логического построения системы. Но скажем честно: программисты ненави­дят тестирование.

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

Поэтому на практике критерием успешности тестирования слу­жит достижение точки конвергенции (Bug Convergence) — когда скорость устранения ошибок начинает превосходить скорость их обнаружения (рис. 2.11).

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

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

Точка достижения нуля (Zero-bug Bounce) — это момент, ког­да впервые все выявленные ошибки оказываются устраненными (см. рис. 2.11). Вслед за ней пики количества активных ошибок должны уже становиться все меньше и меньше вплоть до полно­го угасания в момент, когда бизнес-решение уже достаточно ста­бильно для выпуска.

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

И наконец, тестирование приемлемости для потребителей (User Acceptance Testing).

Производятся такие тесты, как правило, начиная с фазы раз­работки и продолжаются вплоть до фазы внедрения.

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

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