Выбираем инструмент для автоматизации тестирования. Базовый подход

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

1. Определите типы тестирования которые вы собираетесь применять:
• Functional Testing
• Performance Testing
2. Определите какие тесткейсы (сценарии) Вы планируете автоматизировать, а какие нет, и для каких компонентов Вашего продукта
3. Определите технологии и протоколы, которые используются или планируются к использованию в ближайшем будущем компонентами Вашего продукта, тестирование которых подлежит автоматизации
4. Составьте список требований к инструментам автоматизированного тестирования на основании вышеизложенных критериев
5. Выбирайте инструменты на основании составленного списка требований. Если какие-то из них имеют ограничения по этим требованиям - сразу оцените их критичность, и если ограничения критичны - откажитесь от таких инструментов

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

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

Выбор из оставшихся для рассмотрения инструментов сводится в общем к следующим критериям, некоторые из которых могут оказаться для кого-то менее, а для кого-то более важными:

6. Usability:
• Удобство (и знание) скриптового языка (если язык незнаком и сложен для понимания или наоборот примитивен, то наверняка разработка и поддержка скриптов на нем окажется довольно проблематичной). Хорошим признаком будет считаться поддержка скриптов с синтаксисом сходным с известными языками программирования, такими например как VB, java, c# и т. д. Тогда высока вероятность того, что больше людей в проекте смогут понимать код ваших скриптов
• Поддержка технологии Data-Driven Testing очень желательна, я бы даже сказал обязательна в случае работы с многочисленными наборами данных
• Возможность выполнять скрипты по сети на компьютерах тестовой лаборатории посредством тестовых агентов
• Построение и сохранение удобных отчетов по результатам выполнения скриптов
• Наличие автоматической записи скриптов и качество и удобство кода генерируемого ею, возможность вставки переменных и проверок в скрипт непосредственно в момент записи
• Наличие техподдержки
• Наличие развитого комьюнити по инструменту очень важно если он бесплатный
• Интеграция с уже имеющимися у Вас средствами управления тестами (Test Management) и тестовыми лабораториями (Lab Management) или теми, что Вы можете себе позволить ;) Например, в случае, если функционирование некоторых компонентов Вашего продукта зависит от версии операционной системы, а набор поддерживаемых операционных систем состоит из десятка, то Вам предстоит вручную подготавливать каждую машину из вашей тестовой лаборатории, набор скриптов для запуска на ней и хранилище отчетов выполнения скриптов. Каждый запуск такого тестового цикла и анализ результатов выполнения будут представлять массу рутинной работы, а при наличии готовых решений и этот процесс будет автоматизирован.
7. Цена/качество
• Отзывы на профильных форумах, а не только на форуме производителя ;)
• Цена одной копии среды разработки скриптов и одного агента для выполнения скриптов
• Цена сопутствующих средств Test Management и Lab Management

Чего бы я никогда не рекомендовал делать:

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

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