Как ручному тестировщику стать автоматизатором?
Всем привет, я Александра Гордеева, QA‑инженер в Авито, занимаюсь тестированием CRM для партнеров по выкупу устройств. В этой статье рассуждаю о способах перехода из ручного тестирования в автоматизированное и зачем этот переход вообще нужен. А еще делюсь личным опытом — как я стала писать первые автотесты, не имея технического образования и не зная языков программирования.
Что внутри статьи:
Правда ли, что fullstack QA проще найти работу?
Ручник и автоматизатор — в чем отличия?
Должен ли тестировщик писать автотесты на всех платформах?
Как я научилась писать автотесты
Четыре способа войти в автоматизацию
Правда ли, что fullstack QA проще найти работу?
Наташа, моя знакомая, — Senior Manual QA с девятилетним опытом. Она работает в крупной международной компании и говорит, что до недавнего времени ей нравилось заниматься ручным тестированием, а работу было найти легко. Она чувствовала ответственность и важность своего труда, так как QA — это источник знаний о продукте, тысяче его настроек и особенностей.
Наташа считает, что без автоматизации можно прожить, а вот без качественного тестирования и аналитики при составлении проверок — нет. Однако сейчас она столкнулась с трудностями при поиске работы, так как компании ищут как минимум fullstack QA-инженеров с навыками автоматизации.
Я тоже наблюдаю этот тренд. Когда только появился спрос на тестировщиков, это были в основном ручные тестировщики, так как писать автотесты непросто. В то время не было такого количества курсов, зрелых фреймворков и в целом культуры покрытия кода тестами. Потом начали появляться UI‑тесты на Java+Selenium и первые автотестеры. В основном ими становились ручники, которые выучили основы программирования, или будущие разработчики, которые начинали как автоматизаторы.
Сейчас в ряде компаний крупного и среднего размеров всё ещё встречается разделение ролей: ручной тестировщик занимается исследованием продукта, поиском багов, пишет тест‑кейсы. Эти тест‑кейсы он передает автоматизаторам, а те по ним пишут автотесты. Моя первая работа в тестировании была как раз в такой компании.
Сейчас многие компании, в том числе и уровня bigtech, ищут fullstack QA, который может написать несложные тесты, не углубляясь в тонкости языка программирования. При этом такой инженер будет не только отвечать за качество функционала, но и заниматься построением процессов тестирования, используя лучшие практики.
Ручник и автоматизатор — в чем отличия?
Разделение на ручников и автоматизаторов кажется мне не самым оптимальным подходом по ряду причин:
Многие проекты работают в Agile-методологии, где цикл разработки короткий и нужна быстрая адаптация к изменениям. Если тестировщик может и руками работать, и автоматизировать, это позволяет оперативно реагировать на изменения. Чем меньше людей в цепочке, тем быстрее команда разработки получит обратную связь.
У меня в Авито несколько раз бывали случаи, когда я ловила баг, написав в автотесте какую‑то хитрую проверку или последовательность шагов, до которой не додумалась при ручном тестировании, так как когда пишешь код, мыслишь по‑другому. Эти автотесты я написала непосредственно после выкатки ветки на тестовый стенд, что позволило сразу сообщить об ошибке. На первой работе в тестировании, где было разделение на ручников и автоматизаторов, случалось так, что протестировали руками, через 2 месяца автоматизировали, и при автоматизации находили баги.
Когда у тестировщиков разделены обязанности, это может привести к утрате целостной картины продукта у автоматизаторов, отсутствию обмена опыта и знаниями. Автотесты должны создаваться с глубоким пониманием продукта, а автоматизаторы часто не вникают во все детали и изменения на проекте. Fullstack QA понимает приоритеты и знает, что стоит автоматизировать, а что нет. Ручнику это сделать сложно, и может привести к ненужным и неэффективным автотестам.
Fullstack QA могут сократить компании количество сотрудников, занимающихся тестированием, так как один специалист способен «играть» несколько ролей.
Наташа рассказала, что в их крупном проекте она не понимает, как можно совместить ручное и автоматизированное тестирование. По её опыту, если QA пишет автотесты — он будет полностью выключен из работы по ручному тестированию.
Я спросила, какие тесты они пишут и оказалось, у них все проверки покрываются на уровне UI. Соответстенно, на написание тестов автоматизаторами уходит огромное количество времени. В Авито мы используем подход shift‑left, когда бОльшее количество проверок сосредоточено на нижних уровнях пирамиды тестирования. Разработчики пишут много юнитов, и написанием api/интеграционных тестов занимаются также чаще разработчики. Тестировщикам нужно убедиться, что большинство проверок уже покрыто на уровнях ниже и написать на фичу 1–2 UI‑теста. Но зато, как правило, на несколько платформ — desktop, мобильный браузер, Android, iOS.
Этот подход мне нравится тем, что тестов не так много, и я успеваю написать их в рамках спринта, где создается фича. Или перенести на следующий спринт. Так не копится бэклог неавтоматизированных фичей, которые мы снова и снова вынуждены проверять руками и тратить на это кучу времени.
Должен ли тестировщик писать автотесты на всех платформах?
Не могу ответить на этот вопрос однозначно. С одной стороны, можно отдать мобильные тесты мобильным разработчикам, но у них свои задачи, им нужно делать новый функционал, а автотесты будут лежать месяцами и ждать своей очереди. В своей команде я сразу же после выпуска фичи пишу тесты на всех платформах по порядку, оставаясь в контексте проверок. Иногда я копирую тест, написанный под iOS в Android‑проект, и так как шаги те же самые, нужно только написать код на нужном языке.
Делая все тесты сама, я уверена, что в тесте будут именно те проверки, которые мне нужны, ведь мобильные разработчики не знают мой продукт глубоко. Так фича сразу покрыта тестами, и мне не нужно к ней больше возвращаться. Может показаться, что писать тесты на нескольких языках программирования — это что‑то запредельное, но на самом деле всё не так страшно, главное начать.
Однако у того, что QA пишет тесты на все платформы, есть и оборотная сторона. Скорее всего, это простые тесты без глубокого погружения в особенности языка и фреймворка, так как очень сложно одинаково хорошо писать тесты на нескольких языках. На переключение будет тратиться время, что‑то придется вспоминать заново, и наверняка по‑настоящему развиваться получится только в одном, край — двух языках.
Как я научилась писать автотесты
Как и Наташа, многие ручные тестировщики в какой‑то момент задумываются о дальнейшем развитии и встает вопрос «а надо ли мне писать код?». С этим в своё время столкнулась и я.
В тестирование я перешла из отдела закупок и никаких способностей к программированию у меня не было.Но тогда я была уверена, что без написания кода зарплата быстро упрется в потолок. А список компаний, где рассматривают только ручных тестировщиков, значительно меньше, поэтому я решила, что надо с этим что‑то делать.
Сейчас в Авито я пишу автотесты на трёх языках программирования, но так было не всегда. И поначалу было очень больно. В первой компании, куда я устроилась тестировщиком, писали тесты на C#. Благодаря курсу на Stepik я выучила основы языка и попросила разрешения глянуть на код, который пишут автотестеры. Маленькие куски я могла понять, но увидев файл с 800 строками кода, растерялась и к коду даже не приступила. Что это за принципы объектно ориентированного программирования, как их понять и уж тем более применить?))
Вторая работа — и опять C#. Девушка из моей команды, разработчик по образованию, написала проект с нуля. Он был очень сложным и разобраться до конца у меня не получилось. С большим трудом я начала писать самые простые автотесты, в основном копируя и соединяя куски из других похожих тестов. Даже после нескольких курсов по C# я понимала очень мало.
Через год с небольшим я пришла на проект, который написан на Java. Синтаксис Java похож на C# и я решила пройти курс Java + Selenium от Udemy. И о, чудо, на этот раз я понимала каждое предложение лектора. С двадцатого раза до меня наконец дошло, вспомнились уроки из курсов, сложилась единая картинка.
Однако в этой команде вообще не было автоматизаторов. Ребята надеялись, что именно я со своим небольшим опытом С# создам им проект с автотестами с нуля. Один из них был в тестировании уже более 10 лет, но не хотел вникать в автоматизацию, так как не верил, что сможет разобраться. Спросить совета было не у кого и пару недель я провела в поисках оптимального решения именно для нашего проекта. Оторваться было невозможно, было так интересно, что я занималась этим почти все выходные и свободные вечера. Пять раз я начинала, но в процессе понимала, что найденный пример нам не подходит.
В итоге из кучи вариантов собрала по кускам проект, который понравился, стала размножать и постепенно усложнять тесты. Так я создала 2 проекта с UI‑ и API‑тестами. Они были самыми простыми, однако работали и заметно сократили время на ручные проверки.
Что это дало? Примерно 2 раза в неделю разработчики отдавали на тестирование новую версию портала, самым трудоёмким и скучным процессом было заполнение многочисленных формочек. На проверку этой группы сценариев уходило около 2 часов, и никто не хотел этим заниматься))
После того, как я определилась со структурой будущего фреймворка и написала первый тест, в течение полутора дней я сделала ещё восемь. Тесты отрабатывали за несколько минут и их можно было использовать каждый раз при регрессе, экономя каждую неделю минимум по три часа. И это всего несколько первых тестов. API‑тесты проверяли коды ответов основных ручек и тело ответа. Прогонялись они за минуту, но позволили сократить количество итераций тестирования с пяти‑шести до двух‑трёх, так как периодически мы получали в тестирование портал, где часть страниц то в одном месте, то в другом отдавала ошибку 500.
Так я написала свои первые автотесты и была безумно рада этой возможности. После первых двух неудачных попыток с автоматизацией можно было сказать, что программирование — не моё и всё бросить, но я решила, что мне просто нужно чуть больше времени, чтобы разобраться, и всё получилось.
Четыре способа войти в автоматизацию
Расскажу о четырех способах войти в автоматизацию, которые я вижу:
Самый простой вариант — узнать, существует ли программа обучения у вас в компании. Бывает, что такие программы есть, но про них не всегда говорят.
Если автоматизация на проекте уже есть — поговорите с руководителем о своем желании начать писать автотесты и спросите, что для этого надо выучить. Обычно руководство не против таких инициатив и поддерживает желание развиваться. В идеале вам дадут более или менее детальный список, что нужно изучить, чтобы вас допустили к написанию простых тестов. Этот вариант потребует от вас больше усилий, но он тоже хорош, так как коллеги будут ревьюить ваши тесты и указывать на ошибки, что на первых этапах особенно полезно.
Если автоматизации на проекте нет вообще, лучше выбрать какой‑то популярный язык (Java, Python, JavaScript) и выучить основы. Потом выбрать какие‑то рутинные задачи, которые вы часто делаете руками и написать скрипты/простые автотесты. Либо через API, либо UI c Selenium, зависит от задачи. Главное, чтобы они работали и позволяли вам экономить время. Далее можно показать руководителю, что получилось, расписать преимущества. Скорее всего, получится договориться о совмещении ручного тестирования и написания скриптов/автотестов. В этом варианте особенно важно после усвоения основ изучить принципы хорошего и чистого кода, паттерны проектирования, которые применяются в автоматизации тестирования. Если этого не сделать, ваш код будет кривым, трудно поддерживаемым и нечитаемым. Я вот сделала это далеко не сразу и первое время писала не особо оптимальные тесты. Не делайте так, не повторяйте моих ошибок)
Может получиться так, что ваша компания не видит смысла в автоматизации и не поддерживает инициативы. Тогда можно опять же подучить основы языка и найти внешнего ментора. Менторство — вообще мой любимый способ обучения, где ты учишься сразу на практике. Уже говорила, что большинство QA в Авито пишет тесты под несколько платформ, но на рынке сложно найти кандидата с опытом написания на 3 языках, и обычно ребята приходят с опытом автоматизации на других языках. Так, я пришла с опытом Java, а для тестов под Android/iOS мне выделили менторов среди мобильных разработчиков. Я выучила основы языков, менторы познакомили с фреймворком и помогли с первыми задачами, где нужно было внести правки в уже существующие тесты. Через какое‑то время я смогла писать тесты самостоятельно. А потом и сама стала менторить.
Выбрать первый язык вам помогут вакансии — определите, какой ЯП требуется чаще и беритесь за него. А еще спрашивайте на собеседованиях, есть ли у работодателя программы обучения и менторства. Со знаниями основ языка вас могут взять на вакансию fullstack QA, где нужны ребята с навыками автоматизации, постепенно вы наберетесь опыта. Учить основы языка программирования без практики не имеет смысла, тк вы всё забудете уже через месяц.
Спасибо вам за уделенное статье время! Надеюсь, мой опыт окажется полезным. На вопросы с радостью отвечу в комментариях, там же жду ваши истории о начале пути в QA и том, к чему вы пришли. Считаете ли вы, что сейчас QA‑инженеру обязательно нужны навыки автотестов? Поделитесь мнением в комментах!
