Тестирование ПО как один из элементов системы качества

Наиболее приемлемым ориентиром для корпорации является опыт компании IBM — одного из ведущих разработчиков программ для оборонных проектов США. Известно, например, что в трех миллионах строк кода бортового ПО "шаттлов" содержится менее одной ошибки на десять тысяч строк [1]. Мы активно внедряем в свою практику организационный и технологический опыт IBM [2].

Другим ориентиром стали общепризнанные стандарты качества ISO 9000. Согласно формулировке ISO 8402, под качеством понимается совокупность характеристик программного продукта, относящихся к его способности удовлетворить установленные и предполагаемые потребности клиентов. Основными параметрами качества считаются: функциональная полнота, соответствие требованиям законодательства стран СНГ, безопасность информации, простота эксплуатации, не требующая специальных знаний в области информационных технологий, эргономичность пользовательского интерфейса, минимизация затрат на эксплуатацию, развитие и модернизацию.

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

Качество и надежность в комплексе обеспечивают высокие потребительские свойства ПО. В процессе создания программного продукта они одновременно и непрерывно контролируются и совершенствуются. Однако насколько реально обеспечить качество и надежность сложной многофункциональной системы при ограниченных сроках разработки? Для иллюстрации можно привести результаты опроса более тысячи крупных компаний, проведенного министерством торговли и промышленности Великобритании. Оказалось, что средняя частота отказов информационных систем составила: 1 отказ в год — 40% компаний, 1 отказ в месяц — 29%, 1 отказ в неделю — 15% компаний, 1 отказ в день — 7% и 5% компаний наблюдали у себя более одного отказа в день. При этом доля отказов и сбоев программного обеспечения в общем списке причин неработоспособности (простоев) информационных систем составляла 24% [3].

В зависимости от комплекта поставки, система "Галактика" может включать свыше трех тысяч взаимосвязанных бизнес-функций, результаты выполнения которых контролируются более 300 параметрами настройки. Очевидно, что добиться требуемого качества и надежности можно, только обозначив их в качестве приоритетной цели и постоянно продвигаться к ней по следующим направлениям:

• организация промышленного производства программного обеспечения с четко выраженной специализацией, оптимальным распределением функций, полномочий и ответственности персонала;
• внедрение комплекса наиболее современных и эффективных технологий, включая как технологии разработки и сопровождения программных продуктов, так и технологию управления разработками (проектами);
• развитие системы качества [4] на основе рекомендаций ISO 9000-3 (рис.1).

Рис. 1. Структура системы качества Департамента разработки ПО.

Один из ключевых элементов обеспечения качества — это тестирование. Многие известные разработчики ПО проводят тестирование своих продуктов в несколько этапов, которые отличаются видами выполняемых работ и привлекаемыми ресурсами. Корпорация "Галактика" в этом смысле не исключение.

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

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

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

Во время кодирования проверяются отдельно взятые функции или их блоки в пределах одного модуля системы. Затем начинается тестирование системы как единого целого (интегральное тестирование) на наборах бизнес-процессов, для реализации которых используются функции ряда модулей. Эта стадия цикла разработки включает несколько этапов.

Сначала в работу включаются только подразделения Департамента разработки ПО (отдел интегрального тестирования и др.) — этот этап цикла разработки называется внутренним тестированием. Проверяется функциональная полнота системы, соответствие проектной документации, корректность проектных решений. Контролируется соответствие законодательствам стран СНГ: России, Беларуси, Украины и Казахстана.

На следующем этапе в работу вовлекаются ресурсы, внешние по отношению к Департаменту разработки ПО: подразделения корпорации, занимающиеся сбытом и технической поддержкой; клиенты — заказчики новых функций системы; другие заинтересованные организации.

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

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

Рис. 2. Минимизация ошибок на различных стадиях разработки ПО.

Заключительное тестирование проводит отдел интегрального тестирования Департамента разработки ПО. Его задача — еще раз проверить реализацию максимального количества бизнес-процессов и убедиться, что исправление ошибок на предшествующих этапах не вызвало новых ошибок. Фактически это "прогон" системы, на который отводится 10 рабочих дней. Для сравнения — во время приемки систем военного назначения на аналогичную процедуру выделялось максимум 4 дня. Мы отводим на это больше времени и ресурсов, чтобы гарантировать высокую надежность за счет полного охвата типовых бизнес-процессов.

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

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

Все работы по улучшению качества программного продукта, безусловно требуют организационного, технического и методологического обеспечения.

Следуя опыту IBM и рекомендациям ISO 9000-3 [2,4], в штатную структуру Департамента разработки ПО была введена должность специалиста по качеству, которому функционально подчиняются локальные тестировщики групп и отдел интегрального тестирования. Главная задача этого специалиста — обеспечить необходимый уровень качества и надежности программного продукта (версии, релиза).

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

• Экономия ресурсов и повышение качества тестирования. Автоматическое тестирование по заданному сценарию не требует участия человека — система сама тестирует программный продукт во всех нужных режимах, ничего не пропуская. Вмешательство человека требуется только для пополнения библиотеки сценариев.
• Стабилизация надежности. Когда в системе проводятся какие-либо изменения, то самые трудноуловимые ошибки — те, что возникают в уже проверенных компонентах. Повторный запуск сценариев тестирования после внесения изменений позволяет обнаружить ошибки в ситуациях, где тестировщик с большой вероятностью мог бы их пропустить. Таким образом, надежность уже отлаженных и проверенных компонентов системы находится под постоянным контролем и не может быть нарушена при внесении изменений в другие компоненты.
• Параллельное тестирование системы на разных платформах. Отлаженные сценарии тестирования могут запускаться на любой из поддерживаемых в данный момент платформ (Btrieve, Oracle, MS SQL).

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

Система автоматизированного тестирования теоретически позволяет гарантировать стопроцентное качество системы, необходимо лишь составить исчерпывающую библиотеку сценариев. Традиционно считается, что качество приложения является функцией от количества тестов [5]. Но для сложного многофункционального программного продукта, такого как "Галактика", создание подобной библиотеки — крайне сложная задача, требующая колоссальных ресурсов. Поэтому мы придерживаемся другого подхода: большинство ошибок выявляются и устраняются на ранних стадиях разработки, а во время интегрального тестирования приоритетная роль отводится комплексным тестам, проверяющим реализацию бизнес-процессов в целом, а также взаимодействие различных модулей системы. Разработкой таких сценариев занимаются тестировщики, имеющие богатый опыт автоматизации крупных предприятий различных отраслей и форм собственности.

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

Автоматизированная система "Проблемы и решения" (ПИР) представляет собой средство оперативного контроля качества и надежности, которое активно используется во время тестирования для регистрации и статистической обработки информации о найденных и исправленных ошибках. В то же время ПИР — это система оперативной обратной связи с потребителями. Где бы ни возникла проблема: в Москве, Минске, Владивостоке, она очень быстро попадает в Центр разработки. Скорость поступления фактически определяется скоростью передачи информации по линиям связи, при этом сразу известно лицо, ответственное за решение проблемы, и контролируются сроки.

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

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

Технология тестирования зависит, в частности, от объема информации, хранимой в тестовой базе данных (БД). Непременным элементом тестирования является проверка работоспособности системы на пустой базе, что фактически представляет собой модель деятельности нового клиента: систему надо настроить, заполнить основные справочники, ввести начальные данные. Для детальной проверки сложных бизнес-процессов, требующих настройки на региональную либо отраслевую специфику, используются базы с объемом данных до 1 Гбайт). На всех уровнях интегрального тестирования выполняется ряд эталонных и специфических тестов для набора баз данных. Таким образом, к графику (рис. 2) добавляется еще одно измерение (БД). В результате тестирование становится "трехмерным".

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

Тщательное тестирование программного обеспечения — наиболее очевидный способ обеспечения его надежности. Действительно, тестирование — это диагностика болезни, анализ симптомов, выявление источника и определение наилучшей методики лечения. Однако не менее важны профилактические мероприятия [4, 5].

Система предупреждения "болезни" включает ряд организационных мероприятий, суть которых сводится к обеспечению надежности и качества на всех стадиях разработки, начиная от проектирования. На сегодня соотношение времени, затраченного на проектирование, кодирование и тестирование составляет 40%,20% и 40% соответственно. Проектирование разбивается на несколько этапов: разработка технического задания, его анализ, создание макета системы. Результаты каждого этапа подвергаются экспертизе, перекрестной проверке и взаимосогласованию. Наличие детально проработанной проектной документации существенно снижает вероятность возникновения ошибок и служит дополнительной гарантией надежности продукта.

Казалось бы, какой интерес освещение вопроса тестирования — одного из важнейших аспектов разработки ПО — представляет для наших клиентов? Их интересует конечный результат: система должна обеспечивать отражение конкретных бизнес-процессов, быть простой в освоении, динамично реагировать на изменения жизненных реалий. И не столь важно, какими средствами все это будет достигнуто. Тем не менее, непременно нужно уделять внимание работам, направленным на повышение качества ПО. И для этого существует как минимум две причины:

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

Корпоративная система "Проблемы и Решения" (ПИР) - инструментальное средство регистрации и обработки информации обо всех видах проблем, возникающих в ходе разработки и эксплуатации программных продуктов (ошибки, предложения по развитию, заявки на доработку). Система эксплуатируется в центрах разработки и в региональных отделениях продвижения. Обмен накопленными данными, проводимый не реже двух раз в день, обеспечивает оперативное поступление информации из любого региона. Ввод информации осуществляется сотрудниками корпорации, получающими ее от клиентов (по любому каналу связи и в любой форме), или в процессе непосредственной работы с программными продуктами. Проблема адресуется одному из руководителей групп разработки, который отвечает за решение зарегистрированной проблемы. Процесс решения регламентирован и контролируется по срокам. Для контроля и анализа предусмотрено получение разнообразных форм отчетности