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

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

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

Учить Java или .NET? Selenium или UFT?

Создание автотестов зачастую связано с написанием кода, поэтому умение его писать однозначно ценится. Однако привязка к одному специфическому языку программирования может ограничить вас по мере того, как вы движетесь вперед.

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

К примеру, недавно я начал новый проект. До этого момента в большинстве проектов я писал автотесты или на Java, или на .NET, но не в этот раз. За первые несколько недель я написал автотесты, используя PHP, Go и JavaScript. И знаете что? Это было нетрудно. Почему же? Да потому, что у меня есть привычка учиться программированию и изучать принципы объектно-ориентированного программирования вместо того, чтобы зубрить входы и выходы отдельного языка. Эту информацию легко найти в Google и StackOverflow.

То же самое верно для инструментов автоматизации. Я начинал писать UI-автоматизацию, используя TestPartner. Затем я перешел на QuickTestPro (теперь это UFT). В некоторых проектах я использовал Selenium, и успел поиграть с Cypress. Сейчас я пользуюсь Codecept. Все это не важно. Принципы, лежащие в основе этих инструментов, в основном одинаковы: вы идентифицируете объекты на экране и взаимодействуете с ними. Вы должны с осторожностью подходить к стратегиям ожиданий. Если вы с ними справились, то инструмент, которым вы пользуетесь, уже не так уж и важен. Я прекратил гоняться за "инструментом дня", потому что постоянно появляется еще что-нибудь новое для изучения. Принципы меж тем стабильны десятилетиями. Как думаете, какая стратегия саморазвития тут наиболее выигрышна?

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

Оставаться ли в ручном тестировании, или же уйти в автоматизацию?

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

Автоматизация поддерживает тестирование, она не заменяет его. Хотите развиваться в автоматизации? Вам нужно стать профессиональнее и в тестировании тоже. Я сам, кстати говоря, осознал это лишь недавно. Годами я занимался только автоматизацией, автоматизацией, автоматизацией, не думая над тем, помогают ли мои усилия тестированию, и каким именно образом. С тех пор я узнал, что если вы не знаете, что такое тестирование (подсказка – это намного большее, нежели клацанье по кнопкам и следование сценариям), то вам будет очень трудно эффективно поддерживать его автоматизацией.

Не бросайте одну роль ради другой, особенно в ситуации, когда они так сильно пересекаются. Выбирайте и то, и то, а не "или-или".

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

Я много говорил о достоинствах тестов API-уровня – не только в этом блоге, но еще и на конференциях и курсах. Когда я завожу об этом речь, я обычно критично отношусь к тому, как люди применяют автоматизацию на уровне интерфейса. Здесь можно очень многое улучшить! Это не означает, что этот тип автоматизации нужно совсем забросить – просто будьте осторожны, решая, когда и как его применять.

Как и в предыдущих примерах, это не вопрос "или-или". К примеру, представьте что-нибудь простое и однозначное, вроде экрана авторизации (или любой другой формы в приложении). Решая, как подойти к созданию тестов для него, вы не просто выбираете между тестами на уровне UI и тестами на уровне API: все зависит от того, что именно вы тестируете. Это тест, проверяющий, видит ли конечный пользователь форму авторизации и все, что с ней связано? Может ли он взаимодействовать с ней? Правильно ли передаются введенные им данные в API? Выглядит ли форма так, как должна? Это тесты UI-уровня. Ваш тест проверяет, правильно ли обрабатываются пользовательские данные? Верно ли выдаются сообщения об ошибках, если данные введены неверно? Правильный ли уровень прав выдается пользователю после ввода специфической комбинации логина и пароля? Эти тесты, скорее всего, нацелены на уровень ниже от UI. Большое спасибо Ричарду Брэдшоу, упомянувшему этот пример где-то в Slack. С меня пиво, бро.

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

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

Идея, которую я пытаюсь донести при помощи примеров выше, заключается в том, что становление наилучшим из возможных инженером-автоматизатором – это не вопрос выбора между А и В, или способности делать Х или Y. С моей точки зрения, вы намного лучше справитесь с этой ролью, если вы будете уметь, или хотя бы понимать и А, и В, и Х, и Y. Затем извлеките из них общие черты (которые зачастую примут форму принципов и паттернов, упомянутых выше), и научитесь их применять. Изучайте их. Узнайте про них больше. Потерпите неудачу, применяя их, и научитесь чему-то в результате.

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

Не пытайтесь стать мастером одного трюка. Выбирайте и то, и то, а не "или то, или это".

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