Какая бывает автоматизация? Часть вторая.

Какие бывают инструменты?

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

Коммерческие инструменты

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

Остальные проблемы обычны для практически всех коммерческих инструментов (не только для тестирования):

• Практически невозможно допилить под свои нужды, особенно если ваш поставщщик считает что он точно знает что вам нужно, а чего нет. А в случаях когда это можно вас в лучшем случае ждут боль и страдания.
• Поставщик инструмента может перестать существовать. Особенно это печально, когда у вас перестает существовать поставщик драйверов к какой-нибудь бурно развивающейся вещи вроде мобильных платформ или браузеров - в этом случае меньше чем через год вы удостоитесь чести унести все ваши труды на помойку без возможности восстановления.
• Ну и классический vendor lock-in. Как правило поставщики коммерческих инструментов предлагают вам полный комплекс решений в котором, по мнению поставщика, замены ряда кусков (как то continuous integration) быть не может и не должно. Раньше это принимало такие чудовищные формы, как, например, изобретение собственных языков программирования для своих инструментов тестирования. Так же много боли вас может ожидать от попыток интеграции с другими инструментами автоматизации, даже если их аналогов в продуктовой линейке поставщика нет.

Бесплатные инструменты

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

• БОЛЬ И СТРАДАНИЯ ЧЕРЕЗ ОПЕНСОРС. Бывают откровенно чудовищные решения с плохим кодом внутри. И на них, как правило, не написано какое хорошее, а какое нет, особенно если вам приходится браться за не очень популярные инструменты.

Чему учиться?

1. Учитесь программировать. Желательно на скриптовых языках вроде Python, Ruby, Perl, JavaScript (продолжать можно бесконечно). Вам все равно придется писать скрипты рано или поздно, так что если у вас есть выбор - лучше выбирайте их.
2. Регулярные выражения. Вам часто приется заниматься разбором больших текстовых выводов в том или ином виде и просто работать с текстом. Увы лучше регулярных выражений для подобных задач пока ничего не придумали. К тому же регулярные выражения +/- универсальные для всех языков.
3. Если вы занимаетесь автоматизацией веба, то учите xpath и css. У веба большое преимущество перед другими видами автоматизации - доступ до всех элементов иинтерфейса, даже если там внутри мрак и фарш. Пользуйтесь пока есть такое счастье.
4. SQL (или NoSQL, но это пока сильно реже). Даже если тестируемые вами приложения не используют базы данных (что сейчас редкость), то оно вам пригодится когда вы возьметесь за тестовую инфраструктуру.
5. Системы контроля версий.

Кто и как обычно разрабатывает автоматические тесты?

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

Автоматизация после разработки

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

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

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

Автоматизация вместе с разработкой

Как и тестирование параллельно/вместе с разработкой - довольно диковинный зверь в наших краях, увы.

Обычно такой подход характерен для agile проектов, когда всякие ATDD начинаются еще до того как хоть что-то написано. Программисты могут довольно оперативно включать "ручки" для улучшения testability, во время планирований и принятия тезхнологических решений сильно проще договариваться о получении различных testability-фич и инструментария. Фактически автоматизация становится неотъемлимой частью разработки, поскольку разработчики и тестировщики довольно плотно сотрудничают.