Трудности и необходимые навыки при переходе из ручника в автоматизаторы

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

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

Если же вы определились, что необходимо начинать автоматизировать, то как к этому приступить? Что нужно подтянуть или выучить заново? Какие хард и софт скиллы прокачивать?

Основные трудности

• Отсутствие знания языка программирования

Вопрос вечный, нужно ли тестировщику знать язык программирования? Отвечу раз и навсегда: нужно! Тут приведена градация ЯП по популярности: 

JS/TS->java->python->PHP->C#

Выберите язык из первой тройки и не прогадаете. При этом автоматизировать кейсы на java+selenide не означает, что вы знаете java в совершенстве, но на первом этапе это будет неплохо. Рекомендую познакомиться с pet-проектами, с github для разбора как они работают. 

Пример запроса в Google: github java page object.

• Страх перед новым

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

Но не беда, если менторов нет — есть много интересных школ по обучению, но также много теории и практических применений можно найти на Youtube. Тут важно уметь отделить зерна от плевел, т.к. найти реально хорошие курсы сейчас сложно. Повсюду можно встретить рекламу типа «как войти в IT и заработать 3000$ на входе», лучше на неё не вестись и опираться на отзывы или рекомендации. В целом необходимо привыкнуть к тому, что учиться в IT нужно постоянно.

• Нехватка времени 

Когда уже работаешь full-time, трудно бывает выделить время на смену профессии или профессиональный апгрейд, но без желания и упорства вы не сможете стать автоматизатором. 

• Отсутствие опыта ручного тестирования

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

Немного про DevOps. СI/CD

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

Для этого есть разные инструменты: Jenkins, Bamboo, GitLab, TeamCity и др. Можно настроить job для прогона автотестов после оформления pull-request в основную ветку приложения, или использовать иную стратегию прогона. В целом тема DevOps заслуживает отдельной статьи, и не одной, поэтому здесь раскрыта не будет.  

Если совсем коротко, то DevOps (акроним от development и operations) — метод взаимодействия разработчиков с админами и тестировщиками для обеспечения качества продукта. Понимается как особая культура создания продукта и используется для эффективной организации создания и обновления программных продуктов и услуг.

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

Hard skills, с которыми можно приступать к автоматизации:

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

• Обладать навыками тест-дизайна.

• Базы данных — вы должны не просто делать операции по CRUD сценарию (insert, select, update, delete), но также уметь делать выборки данных, используя join из 2-4 таблиц.

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

• Разобраться с IDE (Integrated development environment), чтобы уметь открывать проект, клонировать в git, уметь выполнять commit-> push, познакомиться с пакетными менеджерами (Maven/Gradle), разобраться, как собирается артефакт. Например: как пользоваться Intellij idea 

• Разобраться с фреймворком автоматизированного тестирования. Например, в Java это Junit или TestNG.

• Познакомиться с инструментами тестирования, которые используются на вашем проекте API, UI, Mobile, Load (факультативно).

• Изучить инструменты непрерывной интеграции CI/CD (умение настраивать job для прогона автотестов при сборке приложения).

Soft skills:

• Обладать опытом работы в команде;

• Умение расставлять приоритеты, в данном случае, ранжировать дефекты/запланированные работы по важности;

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

• Уметь четко изъяснять свои мысли, описывать дефекты, неверное поведение системы;

• Некоторая дисциплинированность тут также очень поможет, как и везде;