Home

Автор: Баз Дийкстра (Bas Dijkstra)

Оригинал статьи

Перевод: Ольга Алифанова

В Твиттере широко обсуждалось, кто должен отвечать за создание кода автотестов. Судя по тому, что я читал, люди разбились на два лагеря:

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

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

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

Одним из катализаторов дискуссии послужила статья Алана Пейджа. Она была основана на серии его твитов, которые широко комментировались Ричардом Брэдшоу в его собственной статье. Согласны вы с ними или нет, я считаю, что обе статьи рекомендованы для прочтения всем автоматизаторам. Большинство из вас, возможно, уже читали их, но если нет – прочитайте.

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

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

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

Не знаю, может, это что-то в воздухе, или мимо меня просто проходят именно плохие (или хорошие, смотря как на это смотреть) базы кода, но в последнее время я наблюдал действительно жуткие варианты автоматизации. К примеру, скрипты Selenium, где каждая третья строка была Thread.sleep(). Методы определения шагов Cucumber, содержащие локаторы Selenium. Жуткие имена переменных (во имя всего святого, что должна мне сказать "y"?). Создание нового кейса Selenium для всех возможных комбинаций ввода и вывода, даже если последовательность sendKeys() и click() остается ровно такой же. И так далее, и тому подобное, о, господи.

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

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

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

Обсудить в форуме