fbpx
Какой язык выбрать для тестирования?

языки программирования

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

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

1. Наличие надежной и хорошо поддерживаемой версии инструмента для тестирования.

Этот пункт недаром стоит на первом месте. Инструменты и фреймворки действительно появляются как грибы после дождя каждый день. Но при этом некоторые из них регулярно выпускают обновления, поддерживаются большим сообществом и постоянно развиваются. А другие просто опубликованы автором как результат эксперимента или локальной разработки. В качестве примера приведу PHP клиента для WebDriver – существует несколько реализаций, ни одна из которых “не признана официально”. Все они гораздо сложнее своих аналогов в других языках программирования и развиваются независимо. Поэтому PHP не стоит использовать для тестирования с WebDriver напрямую (есть библиотеки, которые содержат свои прослойки над WebDriver API).

2. Знание языка членами команды.

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

3. Наличие хорошего IDE.

Этот пункт особенно важен для тех команд, где работать с автотестами будут даже неопытные с точки зрения программирования тестировщики. Хорошее IDE помогает многие вещи генерировать вместо того, чтобы набирать руками. Также гораздо ниже вероятность допустить ошибку, потому что IDE подсвечивает потенциальные проблемы и контролирует код по мере его появления. В этом пункте также стоит подумать над вопросом динамических и статических языков. У динамических обычно код тестов гораздо более читабельный и простой. У статических более громоздкий, но зато меньше подвержен “неожиданным” ошибкам начинающих тестировщиков. Хорошим примером являются Groovy и Java. Оба языка позволяют писать код с привычным Java синтаксисом, но многие вещи можно сделать значительно проще на уровне языка Groovy (работа с коллекциями, файлами, базой данных и т.д.).

4. Наличие готовых решений для вашего контекста тестирования.

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

5. Опыт использования в компании.

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

6. Простота изучения языка.

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

А на что обращаете внимание вы при выборе языка? Были ли ситуации, в которых выбор был сделан неверно и привел к нежелательным результатам?

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Обсуждение (9)

Не стоит. И для рубей и для питона море всего уже есть.

Возможно стоит уточнить, что под Java имеется ввиду не язык, а платформа. Тогда многие фишки, такие как testNG, Thucydides становятся доступными для Ruby и Python. Хотя стоит ли такая игра свеч – тот ещё вопрос. А так мой опыт одобряет данное перечесление по важности 🙂

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

У тестировщика который занимается автоматизацией и должен быть солидный технический багаж знаний. Иначе получим то что видим в 90% проектов – кривая архитектура, кривые тесты, кривое все и учеба на шишках. Учитывая, что проблемы с автоматизацией выплывают хорошо если через год – усаживать за это дело wannbe-автоматизаторов себе дороже. Это примерно как брать проект и садить за него команду студентов. Они еще и без особых проблем свалить могут как раз к этому времени – такой уж рынок труда автоматизаторов сейчас.

Ну и насчет архитектуры: если с ней швах, то какой бы язык не выбирали все равно не поможет. Просто вместе с тестировщиками в этом фарше еще и разработчики потонут.

Ты снова берешь в рассмотрение тестировщиков с серьезным техническим багажом знаний, которым интересно и хватает времени опускаться на уровень реализации – Software Engineer in Testing. Таких очень и очень немного (и речь не об аутсорсинге, а вообще о рынке тестирования Украины, России и Беларуси). Для среднестатистического тестировщика это задачи далеко не “на коленку” и не на пару часов, а на недели работы. 🙂

Ой, ну вот чего-чего, а SoapUI пишется на коленке без проблем. К тому же он далеко не для всех сервисов нужен – REST на том же requests заворачивается менее чем за сутки. Ну а если у меня thrift на thrift’е и thrift’ом погоняет, то все равно придется самим писать (тоже быстро делается).

Плюс я не считаю что стоит автоматизацию тестирования ограничивать только API/GUI/Unit тестами. Можно делать сильно больше в том числе для упрощения ручного тестирования. Например пишем маленький питоний скриптик крутящийся на андроиде и я уже знаю когда у меня софт сбоит с геолокацией, а когда это реально проблема железа. Работы меньше чем на час, а профита море.

Холиварить не буду, но из твоей последней фразы про Vim мне многое стало понятно. 😉

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

По поводу нормальной тестовой архитектуры – она есть у 10% проектов (видел я уже перевидел этих проектов). 🙂 Но остальным же тоже жить надо и задача выбора языка перед ними тоже стоит. А в том же самом Thucydides все равно технические детали есть, только они хранятся в Page Object-ах и шагах.

По первому пункту добавлю что зачастую язык программирования и есть инструмент автоматизации. Но тут мы переходим к п.4, где по большей части вопросов примерно одно и то же. Парсить xml в Ruby приятнее, но можно практически везде. Работа со многими базами данных примерно везде одинаковая. HTTP-запросы лично мне в том же Python’е составлять проще, но requests lib уже начал и в другие языки расползаться.

п.2 обязан (!никак иначе!) лечиться хорошими тестами и фреймворком (не тот что xUnit, а тот из которого мы реально тесты собираем). Никаких “расположение элементов, тип элементов, переходы между страницами и т.д.” в тестах быть не должно и при нормальной тестовой архитектуре такие движения вообще не должны требовать никаких особых знаний. Фактически нормально допиленный py-saunter или Thucydides (или сотни блестящих Ruby-поделок) эту проблему решают.

Ну и пункты 3 и 6 они таки холиварные. Лично для меня Vim единственно возможная на данный момент IDE.

Leave a Reply

Your email address will not be published. Required fields are marked *

Pkv Games BandarQQ Online Terbaik Dengan Deposit Super Modern permainan paling populer di situs poker online terbaik di indonesia di situs bukaqq Poker Online Aman dan Terpercaya slot online