qa automation с чего начать
Как стать автоматизатором тестирования?
Вчера, отвечая, кажется, в шестой раз на этот вопрос, твёрдо решил, что пришло время для написания статьи. Сразу отмечу – это исключительно моё видение, с которым, уверен, добрая половина мира автоматизаторов не согласится, – мой рецепт несколько сложнее, чем «почитать про тулзу», «поставить тулзу», «использовать тулзу», «написать в резюме, что умеешь пользоваться тулзой».
Эта статья полезна не только для мануальных тестировщиков, желающих автоматизировать свои рутинные проверки, но и для бизнеса и HR-ов, которые ввиду отсутствия каких-либо общепринятых критериев, как правило, понятия не имеют кто есть QA Automation Engineer и в большинстве случаев принимают решение на основании «хороший человек».
Бывает ещё хуже – руководитель/PM/etc… приходят к своим мануальным тестировщикам и говорят: «слушай, а может мы автоматизируем наше тестирование – это сэкономит нам кучу времени и денег. Скажи, какие книги тебе нужны и какие курсы».
Итак, мы узнаём, что такое примитивы, классы, объекты, полиморфизм, инкапсуляция, интерфейсы, абстрактные классы, статические поля, циклы, массивы, листы, мапы, потоки и так далее… Это изучение будет продолжаться в целом всё время, даже когда вы уже автоматизируете тестирование. Но на базовом уровне – Junior Java Developer – вы должны (если выбрали Java) быть знакомы с языком и иметь соответствующие навыки, потому как первичная локализация возникшей проблемы лежит на ваших плечах. Забудьте про «а вот у меня сценарий, ошибка наигрывается непонятно как и непонятно почему» — ваша задача, чтобы разработчик знал, что тут вот рядом человек может найти баги даже не запуская приложение. Не поверите, как вдруг качество продукта возрастает, когда есть человек, который не просто слышит запах плохо пахнущего кода, но и может предложить решения по улучшению.
Мы плавно перешли к
2. Использование шаблонов проектирования для разработки тестового фреймворка.
ДА-ДА. Вы открыли, например, Selenium, — всякие примеры, скопировали бездумно, написали на получившемся «фрэймворке» 1000 тестов. Приходит заказчик к бизнесу, говорит «мне тут нужно кое-что переделать», бизнес приходит к разработчику — «нам тут нужно немного подстроиться под рынок», разработчик всё прекрасным образом запиливает, — 90% тестов падают. Приходят к автоматизатору «мы тут немного поменяли, надо привести тесты в порядок», а автоматизатор в ответ «тут работы на месяц»… Упс…
Архитектура фрэймворка, который вы пишите, должна не просто быть гибкой, а должна постоянно стремиться минимизировать время рефакторинга имеющихся тестов и написания новых. В идеале, если разработчик и автоматизатор одновременно садятся исправлять что-либо, то автоматизатор должен сделать всё быстрее и предоставить разработчику некую форму TDD.
В создании такой чудо-архитектуры нам помогают паттерны проектирования и их грамотное использование… Builder, Facade, Factory, Null Object, Singleton, Adapter и многие другие паттерны активно помогают в решении подобных задач. Грамотная архитектура тестового фреймворка – это счастье для вас, для разработчиков, для бизнеса…и в конечном счёте для пользователя. Помните, что экспоненциальный рост ресурсов поддержки тестов при линейном росте/изменении функционала свидетельствует о том, что вам пора дорабатывать архитектуру движка. С наиболее полным списком паттернов с примерами на Java можете ознакомиться здесь. Отдельно отмечу Page Object Pattern, но лучше, сначала познакомиться с классическими.
3. Использование библиотек
То, что плавно вливается в любые задачи, — внешние API, библиотеки, драйверы и прочие прелести. Selenium — тестируем Web, Robotium/Espresso — тестируем Android, Fest/Jemmy — тестируем Java Swing, JemmyFX — тестируем JavaFX, замечательные Apache HttpComponents — делаем запросы и тестируем множество API, GSON — помогает приводить json к объектной модели и обратно и так до бесконечности… Библиотек прекрасных много написано почти под любую задачу — про некоторые из них можно почитать здесь. Не стоит бояться того, что их много — вы уже достаточно знаете, чтобы выбрать то, что вам подходит/нравится/вписывается в архитектуру. Например, под тестирование Java Swing приложений я использую JUnit, Fest, Mockito и широкие возможности java.lang.reflect — этого набора мне более чем хватает.
Будьте готовы к частому посещению stackoverflow и подобных ресурсов на ранних этапах. Будьте готовы к тому, что иногда надо будет заглянуть в исходники. И самое главное — не бойтесь не разобраться.
5***. Написание утилит и собственных библиотек
Тут звёздочки… У вас уже всё замечательно на проекте, регресс покрыт, тесты гоняются, разработчики спокойны и могут спокойно рефакторить архитектуру, не боясь сломать имеющийся функционал. Но, например, для того, чтобы что-то сэмулировать руками, разработчику приходится проделывать из месяца в месяц одно и то же действие руками. Напишите для него утилиту, оптимизирующую эти процессы, включите туда всякие невалидные сценарии, разрекламируйте на уровне компании, — пусть все начнут пользоваться… Это ускорит работу и, как ни странно, уменьшит количество багов, так как у разработчика появится больше времени на то, чтобы проверить побольше сценариев, прежде чем коммитить измненения в ветку. Оглядитесь по сторонам и вы увидите так много процессов, которые можно автоматизировать, что не будете знать, за что взяться.
Пишите достаточно абстрактные библиотеки, могущие быть использованными на разных проектах в вашей компании, да и просто в вашей работе в будущем.
P.S.
К бизнесу, руководителям, специалистам по подбору персонала:
Профессиональный автоматизатор тестирования в конечном счёте экономит деньги компании, я бы даже сказал, в краткосрочной перспективе. Смотрим сравнение очень близкое к реальности здесь.
Как QA организовать автоматизацию тестирования на проекте. Один практически примененный способ
Готовимся учиться
Итак, как же можно организовать автоматизацию тестирования на проекте? Если ваш ответ — взять замечательный Selenium и какой-нибудь фреймворк к нему и вперед, то с высоты 13-летнего опыта работы в тестировании я бы не стала так делать точно. Придется осваивать новые горизонты.
Чем же чреват подход «зациклиться на selenium»? А тем, что вы уже и сами не раз читали и слышали. Тем что, эти тесты UI-ные, они дорогие и долгие как в написании и прогоне, так и в поддержании работоспособности. Это знает каждый, но со всей болью этой истины сталкиваются лишь тогда, когда ее игнорируют. UI end-to-end автотесты должны быть обязательно, никто кроме них, не даст вам уверенности в том, что то, что увидит клиент после очередного деплоя не станет для него разочарованием. Но они не должны стать центром автоматизации вашего тестирования.
Возьмите за центр контроля за качеством вашего продукта Test Pyramid Principles. Те самые, о которых уже тоже много где сказано, но на практике не каждый QA понимает, как эту пирамиду сделать прикладной.
Каждый найдет вариант для своей архитектуры.
Внедряем Testing Pyramid Principles в работу QA
Во-первых, как бы лениво и непривычно это ни было, освойте белоящечное тестирование и станьте «частично девелопером».
Поднимите проект локально, так же как это делает каждый разработчик (наверняка, на проекте есть документация как это сделать, найдите). Вероятно, вы стопятьцот раз проклянете это дело, делая это в первый раз, у вас будет миллион вопросов и проблем, но когда вы это сделаете вы уже многое будете знать: каковы архитектурные идеи, какая база данных, что откуда куда пересылается, где нужные конфиги, а главное, где хранятся автотесты и как их запускать.
Во-вторых, разберитесь с автотестами, которые пишут сами разработчики.
Найдите их место в структуре проекта, какие виды тестирования и инструменты используются, как запускаются. Оцените покрытие проекта автотестами, научитесь ориентироваться в них. Есть множество инструментов для автоматической оценки покрытия, можете пользоваться, но я сейчас говорю не об этом. Я больше о развитии вашего чутья: берете кусок функционала и смотрите, как он покрыт автотестами: хорошо или плохо. Если хорошо, повод быть вам за эту часть спокойным, если плохо — вы нашли себе фронт работы на те дни, когда на повестке нет срочных задач. А пока при каждом прогоне регрешна имейте в виду, что это место в коде уязвимо.
В-третьих, наберитесь смелости, ревьюйте пулл реквесты разработчиков.
Каждый раз когда вы приступаете к разработке нового функционала, запишите себе все тест кейсы для него. Отметьте те из них, которые нужно обязательно автоматизировать, чтобы больше не возвращаться к ручному тестированию этого функционала. Ревьюйте пулл реквесты разработчиков и обоснованно требуйте реализацию тех автотестов, которые они пропустили. Мне много раз попадались очень крутые разработчики, которые писали классные тесты, но даже они уступали хорошему QA в понимании того, как точно, скорее всего, будет пользоваться продуктом конечный клиент. Поэтому даже для матерых спецов находится, что порекомендовать в написании автотестов.
В-четвертых, наберитесь еще большей смелости, и пишите автотесты прямо в коде продукта.
Да, также как это делают разработчики. Наравне с ними. Каждый раз когда вы сталкиваетесь с тест кейсом, который нужно автоматизировать, не бросайтесь сразу воплощать его обособленными инструментами, используемыми лишь внутри команды QA. А первым делом задайте себе вопрос, можно ли его автоматизировать посредством юнит/интеграционных автотестов в коде продукта? Если да, сделайте именно так. Если страшно, то это страшно только в первый раз, зато какой level-up ваших скиллов, ведь ваши пулл реквесты будут ревьюить опытные программисты. Да, сначала разнесут в пух и прах то, что вы сделали, но развитие всегда предполагает боль 🙂 Зато в итоге вы получите прекрасные дивиденды:
Это будут тесты, которые будут поддерживаться лишь командой QA. В них можно воплотить
Что из этого получается
Сейчас я работаю именно по такому сценарию. В итоге на верхушке моей пирамиды тестирования всего 9 штук end-to-end тестов. И их поддержка — моя ответственность. А все остальные десятки и сотни тестов живут вместе с основным кодом продукта, начинают свою работу еще на локальном компе разработчика и поддерживаются всей командой инженеров.
Мои end-to-end тесты работают довольно долго, это связано с тем, что они загружают видео файлы на платформу, а потом конвертят их с разными параметрами, отправляют на обработку на сторонние сервисы, ждут ответа и так далее, совершенно без заглушек. Поэтому в автотестах много моментов ожидания окончания операции. Команде не понравилась перспектива иметь такие тесты в CircleCi, да и не нужно, на самом деле. Поэтому я реализовала их как джобы в Jenkins.
Когда все тестовые проверки в коде продукта пройдены, мы деплоим тестируемый бранч на тестовое окружение и прогоняем на нем end-to-end тесты посредством Jenkins. Еще несколько ручных функциональных тестов для пущей верности от QA и все, можно бранч мержить в мастер. Сегодня Jenkins джобы для автотестов на тестовом окружении гоняю не только я, разработчики постоянно запускают их, когда им нужно генерировать свежие тестовые данные и имитировать активности пользователей. Их немного, поэтому они стабильны и всегда работают. Удобно всем.
Отмечу еще одно приятное преимущество для QA Инженера в такой вот реализации пирамиды тестирования. Получается,, вы по полной программе становитесь частью команды инженеров. Вы, действительно, делаете неотъемлемую часть единой работы — пишете код вместе со всеми, просматриваете код разработчиков, общаетесь с ними, и они делают то же самое по отношению к вам. Вы видите работу друг друга, лучше collaboration, сильнее team building. Вы будете разбираетесь в проекте не только снаружи, но и изнутри, достойно уважения, не правда ли?
Заключительное напутствие
Моя статья не претендует на универсальную пилюлю, которую можно использовать всегда и везде. Все проекты очень разные, все команды очень разные — каждая должна строить свой самый лучший путь сама, часто это квинтэссенция разных подходов и инструментов. Даже знаменитый Скрам, сколько проектов я видела, каждый исповедует по-своему 🙂 Я вообще не верю в строгие инструкции, верю, что они нужны как ориентиры, а действовать нужно по ситуации.
Однако мир IT развивается, и в него приходят все новые и новые люди, поэтому уверена, что среди читающих этот материал обязательно найдется тот, кому мои маленькие инструкции помогут выбрать верный путь. Улыбнитесь мне в комментариях, если было полезно :), мне будет приятна обратная связь!
От тестировщика — к QA инженеру. Советы новичкам
Привет! Меня зовут Сергей Могилевский, я QA Engineer в NIX, спикер NIXMultiConf. На протяжении пяти лет занимаюсь тестированием, последние три года являюсь Group Lead, два года — Lead тестировщик в проекте.
Тестирование остается одним из самых популярных направлений среди новичков в IT. «Светлые головы» приходят в команды со своим видением и свежими идеями. Но техническое образование есть далеко не у всех. Ребята ищут направления, которые не требуют длительной подготовки и специфических знаний. Действительно ли профессию тестировщика так легко освоить? Давайте разберемся детальнее.
Тестировщик — многогранная профессия
Хотите быть ответственными за контроль качества IT-продукта? Тогда для успешного старта в карьеру необходимо освоить базовые скиллы: внимательность, усидчивость и понимание особенностей тестируемого приложения. Это три кита, которых в процессе работы дополняет умение пользоваться специфическими вспомогательными инструментами (баг-трекинговыми системами, мессенджерами) Когда навыки сложились в один большой пазл — с уверенностью пробуйте себя на должности QA. В современном мире IT для уверенного входа в профессию этого будет недостаточно. Чтобы сойти за QA — trainee, нужно знать теорию и основы предметной области, попрактиковаться с приложениями, узнать распространенные подходы к тестированию. Это все нетривиальные вещи. Их освоить легче, чем вид программирования, паттерны разработки, основы менеджмента. С уверенностью могу сказать Вам, что скука уйдет прочь уже на старте, какими бы примитивными не казались таски. Здесь работает всем известное правило — первое впечатление зачастую обманчиво. Каждодневная практика поможет понять прелести профессии. Есть куда расти, а это значит, что без челленджей не обойдется! Идеальный сценарий для новичка — найти, заполучить оффер мечты, визуализировать себя в уютном офисе в роли перспективного QA. Следующий уровень доступен не всем. Если у кого-то все сложилось так позитивно, это не значит, что тестирование — несложная работа.
+1 челлендж в копилку
Ступая на путь QA, важно уяснить, что с первой в своей жизни работой тестировщика специалист не становится инженером в чистом виде, он лишь тестировщик (вспомним деление на testing, QA, QC и вот это вот все). Перед ним открывается разнообразный мир новой профессии, который он только начинает осваивать. Появляются первые сложности. Однако, справившись с каждой из них, новичок получает отличный профит.
Системное мышление — важная «мышца». Это умение, которое можно и нужно развивать. Благодаря этому QA смотрит на проект шире, генерирует более правильные, оптимальные способы тестирования и тест-кейсы. Например, когда молодой специалист смотрит на фичу, он видит только ее и больше ничего вокруг, максимум — несколько близких очевидных зависимостей. Когда перед QA стоит проблема планирования тестирования для масштабного проекта — навык, как никогда необходим. Если специалист не умеет рассматривать проект, как цельную систему с внутренними зависимостями и взаимосвязями, велика вероятность не оптимально выстроить стратегию тестирования. Стремясь разобраться в фиче любой ценой, найти нужный подход к ее тестированию — мировоззрение становится шире, опыт позволяет находить полезные тест-кейсы, эффективность работы повышается в разы. У QA — инженера появляются возможности заниматься другими задачами и раскрывать себя перед лидом с другой стороны.
Ожидание VS реальность. В начале моего карьерного пути сложилась ситуация, что я зашел на новый проект одним из первых. Мне дали возможность написать тест-кейсы на пару модулей в системе, затем пришлось оставить проект из-за непредвиденных ротаций. Через несколько лет я вернулся в ту же команду, но уже в роли временного усиления состава. Догадаетесь, какие тест-кейсы мне попались на прогоне мануальной регрессии? Бинго, мои же собственные! Юмор оказался в том, что я это заметил, когда обсуждал с коллегой узость и непродуманность подобных проверок.
Оказалось, за прошлые месяцы ни у кого не дошли руки актуализировать, проверить тест-кейсы. В целом проверяли функционал. С прокачанной «мышцей» системного мышления я, буквально, за пять минут понял то, что не смог заметить, будучи новичком. Проверки, которые казались чуть ли не идеальными, на самом деле были поверхностными и плохо продуманными.
Качественная коммуникация — необходимый аспект. QA — это не только о тестировании, но и регулярный сбор информации, документации, построение слаженного общения в команде. Специалист, умеющий быстро добывать нужную информацию, делиться с заказчиком, грамотно ее распределять в задачах для тиммейтов — профи на вес золота. Начинающий специалист не всегда понимает, какие вопросы, кому конкретно, когда лучше задавать, с кем делиться результатами работы, что потом делать с фидбэком. Освоение этого навыка позитивно влияет на информированность и осознанность всей команды. Проект не стоит на месте, а продвигается. Коммуникабельность тестировщика, как и всех остальных участников команды, помогает не упускать важные для проекта моменты и оставаться на острие IT-сферы.
Обновлять и пополнять имеющийся инструментарий — must have для QA-инженера. Работа может выполнятся быстро и качественно, если подобрать для нее подходящий инструмент. Например, автоматизированное тестирование web UI на Angular намного проще, если использовать тулзы вроде Protractor. При этом работа пройдет гораздо сложнее, если использовать Selenium. В этом случае он не совсем подходит. Умение быстро выбрать правильный инструмент, изучить его, если он еще не освоен — сложная, но необычная и интересная задача, которая всегда развивает специалиста.
Почему тестировщик и QA не одно и то же
На практике основные задачи тестировщика отличаются от обязанностей QA-инженера. Тестировщик запускает тесты, проверяет и сверяет фактический результат с ожидаемым. У QA-инженера — масса задач для поддержания качества продукта. Общение с командой или заказчиком, планирование работ по тестированию, генерация специфической проектной документации и множество других тасков. Но если относиться к такой работе, как к длительному процессу развития, то большая часть умений приходит к тестировщику с опытом. Он участвует в командных активностях, постепенно получает доступ ко все большему количеству интересных заданий и усиливает свою экспертизу. Потихоньку начинающий тестировщик приближается к гордому званию настоящего QA.
Опыт получен. В запасе появились новые скилы. Что дальше? Всегда можно придумать другой подход к тестированию того, что уже сотню раз проверяли, и найти то, что можно оптимизировать.
QA — в первую очередь инженер
Для многих это звучит непривычно и вызывает небольшое сопротивление. Не стоит нервничать 🙂 Специалист каждый новый таск воспринимает, как челлендж, рвется его преодолеть с помощью имеющегося тулсета? Поздравляем, Вы нашли идеального QA. Столкнувшись с незнакомой задачей, тестировщик скажет: «Я такого не умею. Найдите того, кто умеет», а инженер ответит: «Дайте я разберусь и объясню, как могу решить эту задачу». В моей команде есть несколько специалистов, которые постепенно начали разделять и поддерживать этот подход. В тот момент, когда они приняли новые правила игры, когда страха неудачи не существует, а очередная задача — это всегда увлекательный и посильный челлендж — они стали получать от работы больше удовольствия и постоянный респект от коллег. Ребятам достаются новые, «непонятные» таски и в них они находят для себя постоянный рост.
Какие активности доступны с описанным выше складом ума? Любые! Ограничений практически нет. За любую задачу можно взяться, почерпнув из нее что-то новое. Например, виды тестирования, помимо простого мануального, это же кладезь интересных задач:
автоматизация функциональных проверок;
Среди других активностей, могу выделить такие:
вникание в код приложения для поиска новых вариантов проверок или отсечения дубликатных;
применение новых техник тест-дизайна к существующим проверкам;
построение новых пайплайнов тестирования.
Этот список можно продолжать. Каждый специалист найдет что-нибудь полезное для профессионального роста, руководствуясь своими навыками и интересами. Чтобы получать доступ ко все новым активностям и таскам. Крутой инженер умеет все, а с чем еще не знаком, разберется и сделает самостоятельно.
Единственным ограничителем может стать проектная ситуация и команда. Кто ищет, тот всегда найдет. При большом желании, заинтересованный в личностном развитии QA-специалист, всегда будет охотно браться за новые вызовы, стараться проявлять себя в интересных задачах с необычной стороны. Проверено на собственном опыте и команде. Лично мне хотелось бы, чтобы каждый, кто покоряет профессию QA, четко понимал — это не только про тестирование. Разнообразие активностей в этом направлении подходит практически каждому, кто готов на старте быть усидчивым и внимательным. Нужно просто немного изменить склад ума, чтобы тестировщик позволил себе стать инженером. Тогда перед ним мгновенно откроются десятки карьерных возможностей!
QA Automation: что за профессия и как в неё попасть?
QA Automation – профессия на стыке тестирования и программирования, которая является весьма перспективным направлением как для начинающих, так и для опытных технических специалистов.
Мы попросили коллег из нашей QA Automation команды – у каждого из них особенный путь в профессию и различный бэкграунд – рассказать о настоящем и будущем этой специальности.
Алексей Бедункевич
Group Manager iTechArt
Стаж работы в компании– 11 лет. Руководит группой тестирования в составе 35 человек.
Екатерина Юрасова
Group Manager iTechArt
Стаж работы в iTechArt – 4 года. 10 лет экспертизы в автоматизации.
Екатерина Жуковская
QA Engineer iTechArt
Молодой специалист, до начала работы по специальности стажировалась в Students Lab по направлению «QA Automation».
Алексей Поболь
QA Engineer iTechArt
Начинал как QA Manual, перешёл в ряды QA Automation, переобучался в iTechArt.
Как ты пришёл (-ла) в QA Automation?
Летом 2019-го я перешел в должность Group Manager, и на данный момент у меня в группе тестирования 35 человек.
АЛЕКСЕЙ ПОБОЛЬ: Поработав мануальщиком на протяжении 3 лет, устал от монотонности, хотелось упростить себе работу через автотесты. Основной мотив – попробовать что-то новое, изучить язык программирования.
Я пришёл в iTechArt с базовым знанием Java, мне нашли проект с автоматизацией на C#, недолго думая, я начал учить С#. Мне помогал ментор с изучением базовых основ автоматизации, коллеги проводили код ревью. Освоил C#, Entity Framework, поработал с Api тестированием, Http Client, Specflow, Git, Report Portal. Очень доволен переходом, все сложилось лучшим образом.
Алексей Поболь, QA Engineer
От себя отмечу, что понимание специфики мануального тестирования намного упрощает рабочий процесс. Например, если нужно покрыть тестами модуль, который еще не задокументирован или нет тест кейсов, тут как раз пригодится прошлый опыт.
ЕКАТЕРИНА ЮРАСОВА: Мой путь начинался в Могилеве 10 лет назад. Я стартовала как Manual QA, но уже тогда была на микс-позиции. На проекте мы тестировали большие формы на Selenium. Когда попала на бенч, решила использовать высвободившееся время на учёбу. По окончании обучения стала искать проект, где могла бы применить полученные знания. Далее свой путь в автоматизацию продолжила уже в Минске, где нарабатывала продакшн опыт на Java и С#.
В iTechArt я пришла с запросом на развитие в наиболее трендовых направлениях. В первый год мне пригодился опыт по C# – я делала «реновацию» устаревших скриптов для клиента. Примерно через год в iTechArt мне посчастливилось заполучить первый проект на JS. А еще через некоторое время мне посчастливилось попасть на проект со стэком Cypress+JS. И хотя я вообще ни разу не работала в Cypress, я быстро поняла, насколько он выигрывает перед Selenium. Эта тенденция была очевидна еще в 2019-ом, когда популярен был Protractor.
К 2019-му у меня уже был год опыта работы в Cypress, и, хотя меня никто не просил, я понимала, что нужны какие-то обучающие материалы для менторинга ребят. Я начала сама писать методичку, благодаря ей мы стали развивать QA Automation в Бресте. В течение двух лет мы с практически с нуля выстроили в городе сильную экспертизу. В Минске курс также продолжает пользоваться популярностью. В целом, он работает на выращивание экспертизы для людей с многогранным бэкграундом – ручные тестировщики с желанием развиваться в этом направлении, автоматизаторы со знанием других технологий и языков.
Group Manager стала относительно недавно. Приняла это решение, поскольку почувствовала, что на данном этапе таким образом смогу внести больший вклад.
Екатерина Жуковская, QA Engineer
Мне нравится Automation QA, я бы даже назвала специалиста, работающего в данном направлении, Software Developer in Test, ведь по сути это та же самая разработка, только в сфере QA. Мне нравится моя работа, потому что я понимаю, что я делаю то, что люблю.
Изначально я собиралась быть Manual QA, ещё с 11 класса интересовалась тестированием и читала различную техническую литературу, но решила связаться с алгоритмизацией и программированием, так как неплохо разбиралась в этом предмете в ВУЗе. По итогу я прошла именно на специализацию по автоматизации тестирования, что и послужило стартом карьеры.
На 2 курсе в университете по субботам один из преподавателей организовывал встречи с выпускниками. Однажды пришёл сотрудник iTechArt – Вадим Чирица, который рассказывал про DevOps и QA. Уже на тот момент я задумывалась о карьере в QA, и, поговорив с Вадимом, обрела уверенность в себе и вдохновилась историями о работе в компании.
Что входит в основной пул обязанностей QA-автоматизатора?
АЛЕКСЕЙ БЕДУНКЕВИЧ: Как ни странно, автоматизация QA процессов:
ЕКАТЕРИНА ЖУКОВСКАЯ: Обязанности разнятся от проекта к проекту. В основном это непосредственно:
На что Group Manager обращают внимание, когда привлекают новых людей в команду специалистов по QA Automation? Можно ли прийти в эту профессию без понимания принципов мануального тестирования?
Алексей Бедункевич, Group Manager
Наличие опыта мануального тестирования не обязательно, опять же хорошо, когда он есть, но у меня много кейсов, когда люди приходили в тестирование сразу в авто, и все было замечательно. Но книжечку почитать я все равно говорил 🙂
Для меня главное – желание развиваться, причем это уже должно быть подкреплено каким-то делом, а не просто “планирую изучить”. Желание учить несколько тех стеков для авто стеков: Java/JS, Python/C# и т.д. Софт скиллы: командная работа, живость в общении, позитив.
ЕКАТЕРИНА ЮРАСОВА: При наборе для нас важен уровень английского языка, готовность изучать другие языки и технологии. Нужно быть гибким и открытым к новому, и в целом, наш потенциальный коллега должен быть позитивным, открытым, готовым к компромиссам. Сотруднику должно нравится тестирование как таковое. Он, как и Manual QA должен знать теорию тестирования. Он должен быть заинтересован осваивать некоторые DevOps темы, поскольку для автоматизатора важно уметь настраивать запуск авто-тестов на CI/ CD самостоятельно, не прибегая к помощи devops специалистов.
При этом сотруднику важно понимать, хочет ли он (она) больше развиваться в тестировании или программировании. Случается, что front end разработчики рассматривают направление как вход в IT.
Екатерина Юрасова, Group Manager
Я стараюсь давать людям понимание того, что им в первую очередь нужно выбрать что-то одно и двигаться по этому пути, поскольку Automation – это отдельная стезя, со своими приключениямим и челленджами, а не легкий вход в IT. Так мы не тратим время друг друга впустую.
Верно ли, что QA-автоматизаторам нужно разбираться в программировании чуть ли не лучше разработчиков?
АЛЕКСЕЙ БЕДУНКЕВИЧ: Я не считаю что автоматизатору надо разбираться в коде на уровне разработчика, но всегда хорошо если человек разносторонне развит. Но даже простое знание базы и наличие здравого смысла уже позволит стать довольно успешным автоматизатором.
Есть ли у тебя какой-нибудь персональный лайфхак, который бы упростил жизнь всем QA-автоматизаторам?
АЛЕКСЕЙ ПОБОЛЬ: Если я нахожу какое-то интересное решение, то сразу документирую это на внутреннем портале, чтобы другие члены команды тратили меньше времени в будущем
ЕКАТЕРИНА ЖУКОВСКАЯ: Сложно назвать это лайфхаком, но могу сказать, что нужно уметь писать не только красивый и правильный по структуре код, но также и уметь создавать, так называемые, “костыли”. Это действительно упростит жизнь и сократит время на решение какой-то нетривиальной проблемы, где красота кода ничем не помогает, ведь это уже будет критическое мышление, основанное на опыте.
А самое главное – не нужно бояться, что ты чего-то не знаешь, главное желание и усердие. Мы учимся всю жизнь – “Чем больше мы знаем, тем ещё больше нам придётся узнать”.
Какие пути карьерного роста есть из этой специальности?
АЛЕКСЕЙ БЕДУНКЕВИЧ: DevOPS – первое что вспоминается, так как очень часто Auto QA встраивает свою работу в пайплайн разработки. Development – тут все понятно 🙂
ЕКАТЕРИНА ЮРАСОВА: Пути могут отличаться. Главное чувствовать, что автоматизация – это твоё. Иначе, если не случилась любовь с профессией, то уже через 2-3 года выгоришь.
Карьера на этой позиции может развиваться как вертикально (от специалиста к менеджеру), так и горизонтально (через освоение смежных областей). Главное – не сдаваться, если случаются неудачи. Следить за экспертами, развиваться в трендовых инструментах, знакомиться с описанием вакансий, стараться получать информацию из разных источников.
Ждёт ли IT-сферу в будущем полный переход на автоматизированное тестирование?
АЛЕКСЕЙ БЕДУНКЕВИЧ: Нет, всё так же есть много задач, которые не имеет смысла автоматизировать, да и, тестируя руками, ты оцениваешь приложение как пользователь, можешь предложить улучшения, которые сделают работу с приложением более удобным.
ЕКАТЕРИНА ЮРАСОВА: Однозначно нет. Во-первых, всё ещё есть и будут “быстрые” проекты (продолжительностью 1-3 месяца). Если проекту 1 месяц, автоматизированное тестирование для него попросту неактуально.
Ручные тестировщики выполняют очень много важной работы, связанной с анализом требований, в том числе могут участвовать в формировании этих требований, находя «дыры» в них на самых ранних этапах. Ручная работа нужна всегда, когда нужно проверять новые фичи и придумывать новые тестовые сценарии, определять скоуп работ.
Конечно же, удобно, когда рядом с QA Automation работает QA Manual. Мы, автоматизаторы, это очень любим – в таком случае можно сосредоточиться на технической части. С другой стороны, так получается не всегда – клиент очень ценит микс-людей.
Приглянулась сфера QA Automation? Прямо сейчас у нас открыты вакансии по этому профилю для специалистов различного уровня, а также идёт набор стажёров! Присоединяйся!
А для углубленного погружения в тему переходи на наш YouTube канал! Каждый месяц там появляются новые выпуски образовательных ивентов iTechMeetup, которые проводят наши DEV и QA-специалисты. Последний iTechMeetup. Online#15 с Екатериной Юрасовой на тему «Тестирование e-mail, или когда внешность имеет значение» ищи тут.