Помните зубрежку к экзамену в колледже? Когда стрелка часов подходила к 4 часам утра и кофе совершенно остывал, занудный голос внутри вас язвительно замечал: “Если бы ты занимался каждый день, ты бы сейчас мог спокойно спать”.

 

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

 

Вот что произошло в 1992 г. в банке Bankers Trust (Нью-Йорк). “Наше тестирование было всесторонним и качественным, но на него была затрачена куча денег, и в целом на проект ушло на несколько месяцев больше”,  -  сказал Гленн Шимамото, вице-президент по технологиям и стратегическому планированию в этом банке. В другом случае из-за тестирования время разработки приложения для финансовых трансферных операций возросло почти на шесть месяцев. А все из-за того, что разработчики передали приложение группе обеспечения качества для тестирования уже после окончательного завершения разработки. Поскольку группа проверки качества не была задействована с самого начала, то, пока дело не дошло до тестирования, она не имела четкого представления о своей роли в проекте.

 

Корпорация Software Quality Engineering (Джексонвилл, шт. Флорида), обучающая и консультационная компания, помогла Bankers перенять наилучшие практические методы тестирования. Теперь в Bankers всякая внутренняя разработка приложений сочетается с детальным планом его тестирования с первого дня существования проекта. Кроме того, они используют средства автоматического тестирования.

 

Почему лишь немногие компании включают в план разработки своих приложений постоянное тестирование? В Bankers расчетные структуры просто не отделили стоимость тестирования от общей стоимости разработки. Небрежность, недосмотр и жесткие сроки выполнения проекта  -  вот некоторые другие причины. Но, как сказал Эд Уэллер, отвечающий за ПО в фирме Bull HN Information Systems (Феникс), “это исходит из нежелания со стороны многих людей [и организаций] уделить пристальное внимание ошибочным данным”.

 

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

 

В случае с Bankers одной очевидной положительной чертой стало более полное удовлетворение заказчиков: пользователи теперь говорят, что выпуск приложения проходит “тихо”, потому что качество продукта намного лучше.

 

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

 

Поэтому, если вы решили сами взяться за тестирование, приготовьтесь принять долговременное обязательство. Как сказал Уэллер из Bull: “Это то, с чем вы себя свяжете на всю оставшуюся жизнь”.

 

Эрин Коллуэй

 

ШАГИ К УСПЕШНОМУ ТЕСТИРОВАНИЮ

 

Поймите и вникните в конкретный случай, чтобы провести качественное тестирование.

 

Разработайте внутреннюю инфраструктуру для поддержания непрерывного тестирования.

 

Найдите ответственного за этот процесс.

 

Измеряйте, измеряйте, измеряйте. Фиксируйте свои находки в системе регистрации дефектов.

 

Опубликуйте улучшения, как только они будут сделаны, и объясните людям, что они делают лучше.

 

УЧЕНИКИ STAR

 

SQE организовывает в мае конференцию STAR по тестированию ПО.

 

Чтобы получить более подробную информацию, звоните Памеле Янг: (800) 423-8378, доб. 208.