Home

Автор: Виктор Славчев (Viktor Slavchev)

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

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

«Как начать автоматизировать» - первая тема в серии статей. Так как я обещал, я разъясню как для себя, так и для читателей, то, что я знаю про автоматизацию как специфически направленную деятельность со своими целями, поддерживающую тестирование.

Эта серия статей будет:

• Короткой, примерно 5 минут на чтение, хотя это очень сложно для меня.
• Практической – без воды, только эмпирические, полезные советы.
• Основанной на личном опыте и плохих решениях. Я думаю, это очень полезно.

Почему ретроспективные?

Прошлым летом я прочитал книгу «Думай быстро, решай медленно» Даниэля Канемана. Это отличная книга по психологии, прочитайте ее при возможности. Из нее я почерпнул новое слово – «ретроспективный», которое использовалось в предубеждении под названием «ретроспективное предубеждение». Оно обычно происходит в негативном ключе: когда происходит что-то плохое, кто-нибудь обязательно скажет «я так и знал, что это произойдет». Однако оказывается, что этот человек и понятия не имел, что так выйдет. Это просто предубеждение, однако чтобы узнать про эти психологические аспекты больше, читайте Канемана.

Какое отношение это имеет к тестированию?

Один раз я обсуждал с другим тестировщиком свой доклад с конференции под названием «Автоматизация – горькая правда». Он спросил, о чем был доклад, и я ответил, что доклад был посвящен ожиданиям людей об автоматизации и тому, что мы должны реально смотреть на вещи, а не ждать от нее волшебства. Он ответил «Но это же очевидно!». Хм, оказывается, что нет.

Другой пример – от Маарет Пиаярви, с которой мы беседовали на конференции несколько месяцев назад. Зачастую то, что мы считаем здравым смыслом, вовсе не так уж и здраво для новичков в нашем деле, и это в том числе относится и к автоматизации.

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

Формальное определение ретроспективы

Признание реальности, возможности событий, ситуаций, решений и т. п. после того, как они произошли.

Иными словами – все мы однажды облажались с автоматизацией, и нам нужно обломаться с ней еще и еще раз, чтобы получить урок. Полезно было бы поделиться этими уроками, чтобы не пришлось потом говорить «Уж мне-то следовало бы это знать».

Есть определение получше, в Urban dictionary:

После того, как вы что-то провалили, вы магически, удобным образом, приобретаете огромный пласт знаний о том, что вы ДОЛЖНЫ были сделать, чтобы этого избежать.

…казалось очень мне знакомым, пока я не дошел до третьего определения:

«Вселенная тыкает вас лицом в ваши неудачи».

Не правда ли, это прелестно? Не правда ли, на эти грабли наступал каждый тестировщик?

Итак, вдохновением для этих статей служит вопрос, какие ценные урокимы приобрели и можем передать после того, как нас потыкали лицом в наши неудачи?

Напоследок, прежде чем перейти к конкретике, я сделаю несколько предположений:

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

Как начать автоматизировать?

[Примечание: эта тема может быть скучна для опытных автоматизаторов, но я надеюсь, они поймут, почему я об этом пишу]

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

Чтобы начать думать об автоматизации, вы должны четко понимать следующее:

• Автоматизация – это программирование
• Код автотестов – это программа
• Вы программист
• Профессиональная автоматизация – это код
• В автоматизации всегда есть баги
• По большей части вы будете бороться с багами в своем коде, а не с багами в коде продакшена.

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

К сожалению, когда кто-то упоминает инженера-автоматизатора, никто не подразумевает «инженера по записи и воспроизведению».

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

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

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

Снимаем шляпу тестировщика, надеваем шляпу разработчика

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

Когда мы говорим о «программируемом тестировании», мы как будто осознаем ограничения, с которыми мы сталкиваемся при использовании программирования в тестировании, потому что любой фреймворк, язык, API или библиотека имеют свои ограничения, и это абсолютно нормально.

Конечно, мы можем запрограммировать почти что угодно, но учитывая временные, качественные, инструментальные ограничения, вариативность поведения и большое число условий, которое нужно воспроизвести, создавать тесты, пытаясь достичь этого «чего угодно» - уже не самая хорошая идея.

Поэтому в предыдущей статье я развивал идею о двух разных типах мышления – проще говоря, есть разница в подходе тестировщика-исследователя и тестировщика-программиста.

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

Если вы пытаетесь стать автоматизатором, думая, что автоматизация заменит тестирование – вы не очень-то разбираетесь в тестировании.

Если вы стремитесь стать автоматизатором просто потому, что им неплохо платят – возможно, у вас не хватает мотивацией им стать.

Еще раз повторюсь, успешная автоматизация, по моему мнению, возможна, если вы ее любите и вам нравится решать проблемы тестирования программным путем.

С какого языка начать?

Это большая и сложная тема, и чем больше людей вы об этом спросите, тем более предубежденные ответы вы получите.

Если кратко, фреймворк для автоматизации существует практически для любого языка программирования. Если у вас есть опыт работы с каким-то языком и он вам нравится – вперед и с песней. Главное в программировании – и основная причина «религиозной бойни» за различные языки программирования – это то, что вы придерживаетесь того языка или фреймворка, который вам нравится, и с которым вам комфортно. Люди спорят по поводу языков, потому что не могут осознать, что им просто нравится язык – нет никакой другой причины, по которой их избранный язык доминирует над остальными.

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

Если вы хотите заняться автоматизацией, вам еще понадобятся следующие базовые знания:

• HTML5, CSS и JS – просто потому, что (вздыхая) рано или поздно вам придется копаться в UI, так что будьте к этому готовы. Хорошая новость: HTML и CSS относительно легко выучить, если вам не требуются слишком сложные штуки. С JS все не так, но не буду портить вам малину.
• Базы данных – не только из-за вопросов на собеседовании. Знание баз данных необходимо для управления данными для ваших тестов.
• Linux + программирование на Unix – не то чтобы от вас ожидали навыков системного администратора, но от разработчика ждут, что он способен самостоятельно настроить свое окружение. В основном это будет запуск/создание серверов на Linux. Куда лучше, если вы обучены этому до того, когда это превращается в занозу в заднице.
• Web-сервисы и API – их вам придется использовать практически всегда: интегрироваться с веб-сервисом или, как минимум, знать, как он используется приложением. Неплохо бы знать, что такое сервис, как он используется приложением, какие методы есть в API, какие форматы файлов могут использоваться и как мы можем использовать или создавать их через язык программирования.

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

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

Спасибо за чтение.

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