Разработка критериев анализа систем автоматизации тестирования

Вячеслав Панкратов, автор проекта "Тестер", http://software-testing.ru
Статья была опубликована в Журнале для профессиональных программистов "argc & argv", Выпуск № 6 (51/2003)

1. Поддерживаемые процессы тестирования.
2. Поддерживаемые типы тестов.
3. Поддерживаемые технологии.
4. Интеграция с системами разработки.
5. Техническая и документальная поддержка компанией разработчиком.
6. Обучение и сертификация персонала, работающего с набором инструментов и/или методологией.
7. Представительство компании-разработчика в странах ближнего зарубежья.

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

• Каким образом начать анализ рынка средств автоматизации тестирования?
• На что стоит обращать внимание при анализе средств автоматизации тестирования?
• По каким критериям можно оценивать функциональные возможности инструментов и группировать системы автоматизированного тестирования?

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

1. Поддерживаемые процессы тестирования.

Так как система автоматизации тестирования тесно связана с реальными процессами разработки программных систем, а также опирается на определённые процессы тестирования, при анализе необходимо в первую очередь обращать внимание на поддержку инструментом или набором инструментария определённых процессов/технологий тестирования и жизненного цикла разработки ПО. Итак, первый критерий анализа: Поддерживаемые процессы тестирования.

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

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

• Управление жизненным циклом (Lifecycle Management), как процесс тесно связанный с планированием этапов тестирования, как при "водопадной", так и при циклической модели разработки ПО. ресурсов этапов разработки / тестирования.
• Управление тестированием (Test management), оценка затрат, времени, ресурсов этапов. Организация хранения, использования тестовых сценариев, их организации в тестовые группы, анализ результатов работы.
• Управление изменениями (Change request management), как процесс специфичный для этапов тестирования, но интегрированный в процесс внесения изменений в программный код.
• Управление ошибками (Tracking and defect management), процесс отработки обнаруженных ошибок, выявление повторяющихся ошибок, анализа причин их возникновения.
• Управление требованиями (Requirements management), процесс управления изменяющимися требованиями к разрабатываемой системе.
• Управление конфигурациями (Configuration management), управление конфигурациями и настройками разрабатываемых систем.

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

Поддержка этих процессов является важным критерием при оценке системы автоматизирования тестирования.

2. Поддерживаемые типы тестов.

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

• Функциональные тесты, которые проводят тестирования пользовательских интерфейсов, моделируя реальную работу пользователя с конечной системой. В этот же раздел входит и так называемое Usability тестирование, которое в последнее время становится неотъемлемой частью процесса тестирования программных систем, а значит должно автоматизироваться наравне с другими типами тестов.
• Регрессионные тесты, контролирующие сохранение функциональности при переходе к следующей версии (билду) разрабатываемой системы.
• Нагрузочные тесты, испытание систем на производительность под моделируемой нагрузкой.Тестирование безопасности, как процесс выявление потенциальных уязвимостей системы, определение признаков уязвимости и локализация компонентов или модулей, потенциально ущербных в плане общей безопасности системы.
• Нагрузочное тестирование и тестирование производительности, как этап тестирования архитектурного решения, конкретной его реализации и конфигураций оборудования.
• Unit-тесты, как методология разработки, ведомой тестированием. Тестирование модулей, на уровне разработки самого кода.Unit-тесты, как методология разработки, ведомой тестированием. Тестирование модулей, на уровне разработки самого кода.
• Анализ исходного кода, функционал выявления несоответствий между полученным в результате разработки кодом и принятыми правилами кодирования (code-naming-convention), анализ покрытия и используемости кода. (covering, hit-counting)
• Анализ утечек памяти, анализ работы системы с операционной средой и ресурсами системы.

Наличие функционала, который позволит автоматизировать выполнение определённого типа тестов, является вторым критерием анализа инструментария средств автоматизации тестирования.

3. Поддерживаемые технологии.

Под технологиями будем понимать - организованную совокупность процессов, элементов, устройств и методов, используемых для обработки информации. К примеру, технологии .NET, CORBA, OLE, COM, DCOM, COM+ и т.д.

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

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

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

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

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

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

Отдельно хотелось бы оговорить специализированные инструменты, которые поддерживают технологии работы с данными, серверные компоненты и сервера баз данных. В целом картина на рынке таких инструментов отличается от состояния дел на рынке инструментов для тестирования функциональности. Суть таких инструментов, не только создать нагрузку на сервер базы данных (для этого существует отдельный класс так называемых нагрузочных и стрессовых инструментов), с тем, чтобы зафиксировать время отклика и/или выполнения того или иного запроса или вызова. Средства, которые поддерживают технологию какой-то определённой СУБД (Oracle, Informix, DB2, MS SQL) должны обладать не только функционалом вызова, к примеру, хранимых процедур, или подобной функциональностью, которая будет создавать нагрузку и анализировать поведения сервера, но в идеале и проводить анализ конфигурации серверного окружения, структур и схем хранения данных, контроль за следованием стандартам обращений к данным с тем. Результатом работы такого средства может служить сгенерированный набор аналитических данных на основе которых сервер или окружение будет конфигурироваться под конкретную архитектуру базы данных и возможно настраиваться согласно выбранной технологии реализации клиентского приложения.

Указанные требования накладывают существенные ограничения на функциональность подобных средств. Зачастую компания-производитель поддерживает на глубоком уровне только одну конкретную СУБД, разработка инструмента ведётся в тесной интеграции с компанией разработчиком самой СУБД с учётом особенностей архитектуры и технологических решений. Инструментарий получается довольно узкоспециализированный и дорогостоящий, его применения оправдано в случае внедрения долгосрочных промышленных систем автоматизации или систем повышенной отказоустойчивости.

4. Интеграция с системами разработки.

Наравне с интеграцией процесса тестирования в процессы проектирования и разработки ПО, современные средства автоматизации процессов тестирования должны предоставлять механизмы интеграции с системами разработки.

Под системами разработки ПО будем понимать не только саму среду разработки (development environment) уровня Visual Studio и Delphi, но и инструменты планирования и управления процессом разработки (к примеру Microsoft Project Manager, DevPartner, Rational Unified Process), документооборота и управления ошибками, конфигурациями (Borland StarTeam, Rational ClearQuest ) и средства централизованного хранения и изменения данных (Visual Source Safe, CVS).

Виды интеграции. Какие сервисы может предоставить современная система автоматизации тестирования в разрезе взаимодействия с системой разработки?

• Генерация тестовых сценариев на основе модели проектируемой системы (многие системы позволяют проводить анализ моделей Rational Rose и на их основе создавать сценарии использования и прототипы интерфейсов приложения).
• Генерация наборов тестовых данных на основе систем разработки структур баз данных.
• Доступ и выполнение unit-тестов или других тестовых процедур в коде приложения.
• Передача тестовых данных и анализ получаемых результатов.
• Автоматическая генерация данных для создания запросов на изменение в системах управления ошибками.
• Генерация отчётов в системах документооборота или офисных приложениях..

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

Что даёт тесная интеграция с технической точки зрения? Преимущества использования среды автоматизации тестирования выдержанной в рамках общих требований к системе разработки и использующей схожие технологии хранения данных:

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

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

5. Техническая и документальная поддержка компанией разработчиком.

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

Документальная поддержка.

В комплект приобретённого инструмента должен входить пакет сопроводительной документации, который включает описание технических возможностей и требований к окружению системы (system requirements), руководство пользователя (user guide), системного администратора (installation guide) и в некоторых случаях руководство администратора системы (process manager guide). Комплект документации должен быть предоставлен в печатном и электронном виде, кроме того, стоит обратить внимание на локализацию документации, так как документация, предоставленная на родном для покупателей / разработчиков языке, будет гораздо быстрее обработана. Самым удобным и эффективным в работе, можно считать электронный вид документации, выполненный по типу MSDN или TechNet. Конечно, такой вариант оформления сопроводительной документации применим при достаточно большом объёме. Такая система требует отдельной инсталляции, является по сути своей отдельным программным продуктом и подходит под классификацию не как документация, а скорее как база знаний. Такого типа система документации позволяет строить более сложные запросы и базируется не только на описании программного продукта или технологии, но включает в себя также и статьи схожей тематики, описания наиболее часто встречаемых проблем, информацию о тематических ресурсах в сети internet.

Техническая поддержка.

Под технической поддержкой будем понимать возможность обратиться в службу технической поддержки, воспользовавшись одним из электронных средств связи или телефон. Особо стоит обратить внимание на круглосуточную поддержку при приобретении средств у западных производителей, так как из-за разницы во времени запросы в службу поддержки могут прийтись на ночное время. Аналогичным критерием при оценке уровня тех поддержки служит поддержка 365 дней в году, так как обращение в службу поддержки должны обрабатываться и в дни религиозных праздников или выходных дней той страны, в которой работает служба поддержки. Уровень доступности поддержки принято оценивать по шкале 365/7/24 - кол-во дней в году / кол-во дней в неделю / кол-во часов в сутки.

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

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

6. Обучение и сертификация персонала, работающего с набором инструментов и/или методологией.

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

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

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

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

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

  Курсы и обучение специалистов оказывают прямое влияние на эффективность использования приобретённого и внедрённого инструмента, то есть являются фактором, который влияет на возврат инвестиций в проект автоматизации в целом.

  Сертификация же является отличным стимулирующим средством в процессе обучения специалиста технологии или работе с инструментом.

  7. Представительство компании-разработчика в странах ближнего зарубежья.

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

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

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

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

  "Растаможивание" программного обеспечения также является фактором, увеличивающим его стоимость. А так как серьёзные программные продукты идут в поставке с документацией и дополнительными компонентами, комплект поставки может составлять не один десяток носителей типа компакт-диск. Стоимость услуг "растаможивания" продукта определяется количеством компакт дисков. Прибавим сюда компакт с рекламой и презентацией и вполне реально получаем солидную прибавку к стоимости продукта, цена которого нас устраивала вначале. В пользу важности этого аргумента может послужить тот факт, что многие компании в СНГ и в Украине в частности переводят подписки на продукцию компании Microsoft в план поставки на DVD носителях. Как известно, DVD носители вмещают до 5 Гб полезной информации, а стало быть, могут служить заменой примерно 7-ми компакт-дискам. Зачастую, гораздо выгоднее установить несколько дополнительных приводов для чтения DVD дисков, чем платить за "растаможку" примерно 150 компактов ежеквартального обновления подписки от Microsoft.

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

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

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