От коллег-тестировщиков я не раз слышал: «В ручном тестировании упёрся в потолок, хочется перейти в автоматизацию, но боюсь, что не потяну» или «…не знаю, с чего начать». Меня зовут Михаил, в тестировании 7 лет, из них около 4 занимаюсь автоматизацией. В последние пару лет мануальщики нужны всё реже, некоторые компании их уже не нанимают. Бизнесу интересны fullstack-специалисты, умеющие и вручную тестировать, и автоматизировать. Мой опыт подсказывает, что перейти из ручников в автотестеры по силам каждому. Так что я протёр клавиатуру и написал для вас эти мемуары. Заходите под кат, возможно, статья будет волшебным пенделем стимулом для тех, кто ещё сомневается и тянет с переходом. 

Я начал #идтивайти немного раньше, чем туда ринулись те, кто раньше штурмовал бухгалтерские и юридические курсы. Отучившись в университете по специальности «Прикладная информатика в экономике», я ушёл отдавать долг Родине. В смысле в армию, а не выплачивать ипотеку. Демобилизовался в 2016 году и начал искать работу. Меня заинтересовало тестирование. Тогда на рынке ещё не было такого обилия джунов, и через месяц удалось устроиться на должность ручного тестировщика. Я пробыл на ней пару лет, тестировал крупную ГИС. Мог бы оставаться и дольше, если бы не подвернулся удачный случай, о котором расскажу ниже. Вообще-то, я не мечтал о карьере ручного тестировщика, меня влекло автотестирование. Было интересно копаться в технологиях, на которых пишут продукты; разбираться в устройстве информационных систем, чтобы понять, как они устроены и как их можно тщательнее проверить. Но на тот момент в проекте к автоматизации не стремились, поэтому мои желания оставались на уровне хотелок. И я продолжал «лежать в нужном направлении». 

Со временем перешёл из ручного тестирования в интеграционное — это проверка взаимодействия систем друг с другом. В нём нужно было глубже разбираться в технической части, поэтому мне было интереснее. Для этого изучал SOAP, FTP, HTTP и XML, потому что интеграция была построена в основном на веб-сервисах. Просто гуглил и читал найденные статьи. Не всегда всё понимал с первого раза, приходилось перечитывать, вдумываться. Если сам не мог разобраться, уточнял нюансы у коллег-разработчиков.

Одновременно стал осваивать программирование. Ещё в университете мы проходили Delphi и Turbo Pascal, немного писали на JavaScript. На работе я увлёкся Python и Java. Вместе с JS это самые популярные в автотестировании языки. Если не умеешь программировать, то и автоматизировать не сможешь, «визивигов» тут (пока ещё) не придумали, хотя уже появляются инструменты zerocode. Изучал синтаксис, основные функции и паттерны языков. 

Постепенно дорос до тимлида. Со временем покрывать всё ручным тестированием становилось всё труднее. Наша информационная система разрасталась и усложнялась, штат тестировщиков приходилось увеличивать. Цикл регресса занимал уже месяц, и то не всегда успевали. Стало понятно, что скоро сроки станут совсем неприличными, и нужно уже начинать автоматизировать тестирование в проекте.

И тут случился тот самый случай. Однажды к нам в проект пришёл автоматизатор и предложил рассказать об автотестировании.

Конечно, мы согласились. За полдня он рассказал нам о примерной структуре и принципах работы тестового фреймворка. Я написал свой первый автотест для поисковика Google, и после этого всё закрутилось. Так я встал на тропу автотестирования. 

Коллега-автотестировщик  посоветовал книгу Герберта Шилдта по Java, это оказался толстенный фундаментальный том. Ещё обильно гуглил, смотрел обучающие видео. Также мне понравился курс по Java от Трегулова.

 Также стал осваивать общепризнанные в автоматизации инструменты. Тут уже есть специализация:

  • для тестирования UI на Java широко применяются фреймворки Selenium и Selenide (более удобная обёртка вокруг Selenium);

  • для тестирования API часто нужен RestAssured;

  • для запуска тестов — JUnit, TestNG.

Подход выбрал универсальный: читал документацию, находил общие обзорные статьи и видео, потом более подробные описания и разборы каких-то функций и способов применения. Старался не увлекаться и не изучать досконально что-то одно. Иначе этим можно заниматься бесконечно. В итоге не будешь разбираться в остальных темах. Либо изучишь вдоль и поперёк что-нибудь, перейдёшь к следующему, и пока его освоишь, предыдущие знания успеют выветриться. По моему опыту, изучение должно быть итерационным: что-то освоил, попробовал на практике, потом копнул чуть глубже, внедрил, применил, и так далее. Конечно, старался как можно больше практиковаться. Здесь можно творчески применить закон Парето: 20 % теории и 80 % практики. Да и если теорию не применить вскоре после изучения, она быстро забывается.

С помощью автоматизации тестов в проекте мы стали быстрее проводить регрессы и успевать полностью прогонять их до релизов.

Мне повезло, что нашёлся тогда коллега, который в своё свободное время преподал нам азы автотестирования. Он и потом помогал советами. Это мне сэкономило кучу времени. Самообучение — дело хорошее, но быстрее и качественнее учиться под присмотром наставника. Тогда и знания будут более структурированные, и меньше придётся искать обрывки информации в сети. К слову, у нас в компании есть своя Школа функционального тестирования. Там учат теории и дают много практических заданий, работают над внутренними проектами. Лучшие выпускники могут устроиться к нам, я знаю несколько таких сотрудников. Ещё могу посоветовать курс по автоматизации от Баранцева.

Что делать, если хочется в автоматизацию, но в компании её не используют?

Я бы в таком случае подошёл к начальнику и предложил внедрить. Если бы мне одобрили, то обдумал бы тестовые сценарии и выбрал первые жертвы автоматизации. Главное, хорошо посчитать, а будет ли от этого польза? Стоит ли в моём случае заморачиваться с автотестами? Конечно, если бы речь шла про одностраничный сайт или простенькое приложение, то и говорить не стал бы: один раз вручную всё проверили и забыли. На мой взгляд, писать автотесты имеет смысл только в достаточно крупных, долгосрочных проектах, с частыми релизами. А иначе брать автоматизатора со стороны невыгодно, его работа не окупится. Но если в команде есть ручной тестировщик, который уже подготовился, что-то изучил и горит желанием начать автоматизировать — то есть я :), — то почему бы и нет? Компания ничего не теряет, ведь в первое время новичку вряд ли прибавят зарплату. А в будущем, конечно, уже можно претендовать на увеличение оплаты. Специалист-то теперь более опытный.


Если ты ещё не автоматизируешь своё тестирование, то пора бы. Только этого нужно искренне хотеть. Лучше не заставлять себя изучать что-то, потому что кто-то сказал в интернете. Как известно, в интернете часто кто-то неправ. 

У меня получилось перейти в автоматизацию, потому что она меня искренне интересовала. Мне хотелось развиваться в эту сторону. Я знаю немало примеров, когда автотестировщиками становились люди с гуманитарным образованием. Главное — хотеть и не бояться учиться новому. Это не ядерная физика, при должном старании через полгода-год учёбы можно будет уверенно писать в резюме «Тестировщик-автоматизатор» :)

Комментарии (2)


  1. QArage
    27.09.2023 07:07

    Статья на самом деле должна называться "Как я нарисовал сову". Слишком мало содержания, кроме "я захотел в авто и у меня получилось", многие темы не то что не раскрыты, а даже не затронуты. А как же UI тестирование мобилок, а тесты для очередей и брокеров? Ни слова про PageObject, нет подробностей об инфраструктуре для автотестов и ресурсов под неё.

     если в команде есть ручной тестировщик ... Компания ничего не теряет

    А вот это вообще далеко от реалий. Если в Компании ручной тестировщик начинает изучать и тратить кучу времени на автоматизацию, значит это минус пара рабочих рук. Это либо уменьшить количество фичей за то же время, либо увеличить Time To Market, в любом случае ресурс тестирования просядет. А еще он попросит часть времени devops потратить на себя. Как ни крути, для Компании это затраты и инвестиции, которые еще нужно обсчитать и отбить со временем.


  1. anihorta
    27.09.2023 07:07

    "Компания ничего не теряет, ведь в первое время новичку вряд ли прибавят зарплату."

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