Ручные тестировщики не нужны или пора уже в автоматизацию



Нет, конечно же ручники будут нужны. Но с каждым годом потребностей в них будет все меньше. Уровень зарплаты быстро упрется в потолок, а от монотонных задач будет тошнить. Если у вас есть желание оставаться в QA и вырасти в автоматизатора (разработчика?), то текст ниже для вас.

Кто я?


Давайте сначала познакомимся. Меня зовут Александр, и я 15 лет работаю в тестировании. Начинал с разработки, ушел в тестирование, был ручником, сейчас автоматизатор. Тестировал десктоп, UI, мобильные приложения, API, проводил нагрузочное тестирование и много чего интересного, связанного с QA. Я кратко расскажу вам как бы построил свою карьеру в автотестировании, что бы изучал и с чего начал. Да, я что-то упущу, но мои советы это отражение моего опыта, а не истина в последней инстанции.

Какими были ручные тестировщики раньше


Раньше было лучше(с). Лет 15 назад профессия только становилась. К компаниям приходило понимание важности тестирования, и они начинали нанимать тестировщиков. Основные (не всегда!), если коротко, требования к тестировщику — лайтовый программист или специалист, который не попал в программисты, плюс знания основ тестирования. Возможно, вас смутит предыдущие предложение, но я потом поясню его.

Сами тестировщики разделились на ручников и автоматизаторов. Автоматизаторам были доступны продукты от HP, внедрялся Selenium, скриптовые языки. Ручники же тестировали руками, писали тестовую документацию.

Время шло, и ручники слились в одну ветку с автоматизаторами. Причем, по моему мнению, доминировать стали автоматизаторы. И теперь я расскажу, как можно стать AQE (automation quality engineer).

Что надо знать для старта?


Теорию тестирования. Это надо. Виды тестирования, тестовая документация, знать и уметь применять техники тест-дизайна. А также изучить пирамиду тестирования. Может не все в ней будет понятно, но со временем она раскроется во всей красе.

В принципе, для старта подойдет книга Савина “Тестирование Дот Ком” и часов двадцать на ютубе.



Книги прочитаны, ютуб просмотрен, опыт в ручном тестировании есть. Теперь попробуем двигаться в сторону автоматизатора, там интереснее.

Мифы


“Работа QA, как одна из относительно легких точек входа в ИТ,”
“Автотестеры скоро вымрут. Как правило, это такие недопрограммисты”
“Мы тестеры, а не разработчики, нам это знать не надо/не положено/ не обязательно”

Первые два высказывания я нашел в интернете. Третье много раз слышал в живую. Если вы хотите достичь высокого уровня в автоматизации, то не соглашайтесь с этими мифами. Будет тяжело, долго, но интересно. Ваши знания должны быть на уровне программистов. А в большинстве случаев и более — вам же еще знать и применять теорию тестирования.
Откуда берутся такие мифы? Я думаю, что из пункта выше — Какими были ручные тестировщики раньше. Тестировщики это лайтовые программисты (НЕТ).

Думаю, что я могу это доказать. Есть знакомые тестировщики/руководители/разработчики? Спросите их, сколько автотестеров (сильных) они нашли за год? Думаю, что мало, единицы. Наша фирма за год просмотрела 20 кандидатов и взяли одного. Мидла.

Можно попробовать пройти собеседование на синьора AQE. Там уже “Мы тестеры, а не разработчики, нам это знать не обязательно” не прокатит. И собеседовать вас после теории тестирования будут разработчики. Потому что современный сильный автоматизатор — это полноценный разработчик.

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


Не особо важно. Глобально языки программирования похожи друг на друга и за свою карьеру вы будете знать несколько. Если вы поймете основы, то переход на новый язык будет быстрым.
Начинайте с изучения базовых концепций: типы данных, классы, массивы, циклы, работы со строками, функции, ООП. После перейдете к конкретному языку.

В 2020 году для разработки автотестов я бы смотрел на эти языки (напомню, что это исходя из моего опыта, а не инструкция к действию):

JavaScript отлично подходит для тестирования UI. Быстро развивается в тестировании. Фреймворки на JS активно вытесняют Selenium

Java самый популярный язык для автоматизации в России. Так исторически сложилось, очень много вакансий.

Python язык с самым быстрым входом. Язык “простой”, легко читается и изучается.

И надо понимать, что это долго, надо запастись терпением. В зависимости от интенсивности обучения от 4 месяцев до года.

Паттерны проектирования


Паттерны проектирования описывают типичные способы решения часто встречающихся проблем при проектировании программ.

Вот что я недавно услышал:

“Нам нужны крепкие мидлы, которые будут разгребать и понимать наши тесты. Мы их уже мало понимаем”.

Когда у вас сайт с 3-2 страницами, то все просто, быстро, красиво. Но, если у вас проект, где одновременно ui/api/mobile/e2e тесты, и все это написано без паттернов, то в 90% случаев это превратится в помойку (извините).

Знание Page Object это хорошо, но в мире есть еще много полезных шаблонов, которые могут сделать разработку проще. Чем раньше вы решите этот вопрос, тем меньше проблем будет в будущем (это как найти баг на раннем этапе, тогда исправить его будет дешевле).

Вот ссылка почитать.

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

Также рекомендую прочитать книгу Head First. Паттерны проектирования. Фримен Эрик, Робсон Элизабет.

Какую ОС выбрать?


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

Фреймворки для тестирования


Фреймворк (англ, framework — структура, каркас) — совокупность решений по архитектуре, структуре и способам объединения компонентов системы, которые могут быть применены для некоторого множества однотипных задач.

Вот уже подбираемся к тестированию. Для каждого языка есть отличные фреймворки. Для JS это Cypress, Nightwatch, Puppeteer и другие. У Java Selenide, в Python стандарт pytest. Изучайте их, как придет время. Документации по ним море.

Придет время и вы будете сами развивать свой фреймворк, естественно, перед этим хорошо поняв тему паттернов.

GIT и ревью


Git (произносится «гит») — распределённая система управления версиями.
Ваш код надо где-то хранить. Для этого есть git. Git де-факто это стандарт.
Тут процесс обучения можно построить так:
Установите git
Зарегистрируйтесь на github.com
Прочитайте документацию
Откройте ютуб, найдите уроки и работайте по ним.

Для входа вам понадобится изучить небольшое количество команд git:
clone, add, push, pull, stash, commit, status, rebase, checkout. За неделю вы это изучите и освоите. Главное практика.

Код ревью — это мощный инструмент для обмена знаний, поиска багов и “глупых” ошибок, проверки вашего кода. Первое время будут проверять чаще вас, но со временем и вы начнете ревьювить остальных. Попробуйте воспринимать ревью как помощь и развитие себя. Ошибки и опечатки есть у всех.

Почитать

Что еще изучить?


CI/CD Непрерывная интеграция / Непрерывное развертывание.

Главные цели CI/CD — свести к минимуму ошибки, ускорить сборку и повысить качество конечного продукта:



Почитать

Docker — это платформа, которая предназначена для разработки, развертывания и запуска приложений в контейнерах

Почитать

HTTP — это протокол для обмена данными в сети. Возможно, писать UI тесты без знания HTTP вы сможете, но API тестировать нет. Да и локализация проблемы будет быстрее с этими знаниями.

Почитать

xpath — язык запросов к элементам XML-документа.

Ссылка на шпаргалку

SQL — это стандартный компьютерный язык для управления реляционными базами данных и обработки данных. SQL используется для запроса, вставки, обновления и изменения данных.

Почитать

Этот список можно продолжать дальше, но на этом я остановлюсь.

Где получить знания?


Ютуб
Тематические форумы
Книжки
Курсы по программированию
Курсы по автоматизации тестирования

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

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

P.S. Я прошел все: книги, ютуб, статьи, курсы. И для меня лучше всего подошли курсы, это был скачок в развитии. Возможно, у вас будет по другому.

Ссылки


форум автотестеров (там почти все) automated-testing.info
js for testing t.me/js_for_testing
QA — автоматизатор t.me/qa_automation
Серьезный тестировщик t.me/serious_tester
Если еще не сделали, то добавляйте в закладки, это маст хэв ru.stackoverflow.com

Почему я это написал


Недавно я был на митапе, где один из докладчиков рассказывал про свой опыт применения автоматизации тестирования. И его компания пришла к выводу, что легче найти разработчиков и сделать из них AQE, чем тяжело искать автотестеров, которые на долгой дистанции не приносят той пользы, который от них ожидали. И причины были в том, что у автотестеров не хватает знаний в разработке (паттерны, знание библиотек). В чем-то я с ними согласен. Я уверен, что кто-то подумает что я описал требования к супер тестировщику или к разработчику в тестировании (Software Developer In Test). С развитием скрама, когда исчезает такое понятие, как разработчик/аналитик/ тестировщик, мы становимся инженерами и равноправными членами команды, цель которой выпустить продукт/сделать фичу за спринт. В этих условиях требования к автотестерам будут расти и на рынке будут цениться T-shaped специалисты (статья на vc.ru). Такие люди смогут не только четко локализовать проблему, но и исправить ее (например, на фронте). И за этим будущее.

Конец


Как я писал раньше, процесс обучения не будет легким. Для входа в профессию AQE надо будет потратить +- год. Написано много статей, как выстроить обучение, я же отмечу два пункта:

  1. Умейте отдыхать и делать перерывы
  2. Практикуйтесь. Выбирай сайты, проекты. Пиши на них тесты, тестируй API. Храни свой код на github, призывай друзей, коллег к ревью.

Удачи!
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 23

    +1

    Расскажите, как тестировать игры, написанные на С++?

      0
      Добрый день. К сожалению, не тестировал игры, поэтому подсказать не смогу.
      +2

      Первый "миф" не совсем миф: не раз видел, как люди идут по пути ручной тестировщик – автоматизатор – разработчик (последний шаг обычно со сменой места работы). И причина очевидна: тестировщиком без навыков и опыта устроиться проще, тут упорство и добросовестность могут компенсировать неопытность.

        0
        На самом деле это редкий путь из ручника в разработчика (в качественного разработчика!).
        Часто бывает так, что после ручного тестирования человек попадает в автоматизацию, изучает несколько фреймворков и на этом его развитие заканчивается.
          0

          hazemax отличный момент, чтобы рассказать свою историю ;)

        0

        Вот вы утверждаете, что раньше это 15-20 лет назад.
        Но ведь "на западе" люди уже лет 40 как вручную тестируют, и вакансии не заканчиваются.
        Т.к. нет смысла, да и возможности тестирования всего автоматически.

          +1
          Нет, я утверждаю немного другое «Нет, конечно же ручники будут нужны. Но с каждым годом потребностей в них будет все меньше.».
          Совсем ручники не уйдут, даже если часть их задач заберут на себя автоматизаторы. Но это отдельная статья.
            +2
            А почему вы считаете, что автоматизаторы ЗАМЕНЯТ ручников, а не встанут вторым эшелоном для отдельной категории задач?
              +1

              Причём вполне определённой: регресс

          +1
          У вас AQE это какой-то «человек возрождения» получается. По-моему, все эти разговоры про T-shape специалистов, происходят от желания работодателя иметь швеца, жнеца и на дуде игреца за один оклад. Реальность же такова: для ручного и автоматизированного тестирования нужен совершенно разный склад ума. В одной голове они обычно не умещаются, если, конечно, носитель головы не страдает раздвоением личности. AQE и SDET — это лишь подвид разработки. Просто от разработчика там требуется знание предметной области — тестирования, также как от разработчика 1C требуется знание бухучета.

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

          Так что, путь который вы описываете, я сам прошел, но мои неоднократные попытки перетащить в свой стан многих мануальных тестировщиков — так и окончились ничем. Мотивация про T-shape не работает. И «Это — норма» (С) Малышева. Они пишут тест-кейсы, я их автоматизирую. И всем хорошо.

          В остальном согласен. Обзор необходимых знаний и технологий, совпадает с моим мнением.
            +3
            Возьму за пример свой опыт. Если посмотреть со стороны scrum, то у нас нет разработчиков, аналитиков и тестировщиков. У нас есть члены команды, которые должны дать вместе результат. У нас T-shape команда — я могу поправить фронт, аналитик протестировать функционал, фронты писать бэк. И для нас этот вариант работает. Ну и очевидные вещи в виде развития.
              0
              Охотно верю, что работает. Для стартапчиков — самое оно, когда надо MVP выкатить как можно скорее и дешевле. А когда начинается этап конвеерного пиления фич и поддержки, то оказывается, что разделения труда выгоднее.
                0

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

              0
              Реальность же такова: для ручного и автоматизированного тестирования нужен совершенно разный склад ума

              А есть какой-то пруф на этот счет? Что за склад ума? Есть ли какие исследования на этот счет?
                0
                HH.ru — мой пруф. Там почему-то это отдельные специальности. С разными требованиями и разной оплатой труда. Склад ума вроде вашего — сомневающийся во всем. Готовых исследований у меня нет, поскольку мне вполне достаточно моих наблюдений, и платят мне не за исследования. Но вы можете их поискать сами. Если не найдете, выдвинуть гипотезы «pro» и «contra», провести количественные исследования, сделать выводы, пройти рецензирование, опубликоваться. Ну, а потом посмотреть, а кто же на рынке труда нужен, кому платят больше? Узким специалистам или T-shape?
                  0
                  т.е. наличие разных вакансий свидетельствует о разном складе ума?
                  Интересное наблюдение.

                  Вы говорите:
                  — Нет исследований
                  — Достаточно собственных наблюдений
                  — Разные специальности означает разный склад ума
                  — Вам не платят за исследования (это очень интересный факт, но не ясно какое отношение он имеет к вопросу)

                  Риторические вопросы:
                  Кто на рынке труда нужен и кому платят больше.

                  Подводя итог, из какого из этих утверждений следует, что для ручного тестирования и для автоматизированного нужен разный склад ума?
                    0
                    ОК, мнения тысяч работодателей, что это разные специальности, для вас ничего не значат. Преклоняюсь перед вашей интеллектуальной отвагой.
                      +1

                      Я тоже не пойму, откуда, что разные склады ума? Вот есть, например, вакансии фронтенд, бэкенд и фуллстэк разработчиков, или JS, PHP, Jav, C# — это всё тоже разные склады ума нужны?


                      Ну и даже формально в одинаковых вакансиях круг обязанностей может быть совершенно разным. Где-то у AQA основная обязанность тест-кейсы переводить на язык программирования, а где-то это лишь незначительная часть обязанностей, а основное сбор требований и написание этих тест-кейсов, а уж на ЯП перевести — мелочь. А где-то нужно полностью CI/CD инфраструктуру поднимать и поддерживать.

              +1

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


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

                0
                Есть задачи, которые невозможно за разумное время протестировать вручную.
                Делал систему матчинга заказов. После нескольких итераций сложность стала такой, что ее невозможно уместить в голове. Сначала добавилась гибкая конфигурация, затем динамическое построение пайплайнов в зависимости от тойже конфигурации, параметров заказа, текущего состояния системы и т.д. В итоге, количество возможных пермутаций выросло до десятков тысяч.

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

                Я это к тому, что формошлепство возможно дешевле тестировать вручную, но ни одну сложную систему вручную протестировать невозможно (за разумное время, что есть деньги).
                  0
                  Программа по алгоритму не может протестировать программу, но человек по алгоритму может?
                  А в чем отличие?

                  желательно чтобы тестер не думал как программист

                  А что вызвало такое умозаключение?
                    0

                    Как вариант "ну не могли же они не экранировать запросы в SQL, что их тестировать" или "не float же они для денег используют"

                      0
                      если попадается такой инженер(QA), кто знает то, что вы отмечаете, то кмк это находка! =)

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое