Задумался о переходе из разработчиков в автоматизацию тестирования.
Сфера деятельности интересная, а общий уровень загруженности представляется меньшим,чем в разработке.Плюс привлекает отсутствие жестких дедлайнов, когда от скорости работы напрямую зависит выход нового релиза продукта.
У нас отдела QA не существует,поэтому было бы интересно узнать у местных,уже состоявшихся автоматизаторов - как строится ваш рабочий процесс (хотя бы в общих чертах)? Насколько сильно я ошибся в своей оценке и в чем именно?
Интересная и довольно редкая ситуация Уровень загруженности очень сильно зависит от пректа. Если проект только-только стартует, то первое время автоматеры находятся в относительно свободном режиме подготавливая то что и понадобится для автоматизации в будущем(тестовый фреймворк, выбор средств автоматизации, концепция и т.д.), на конечной стадии продукта (конец разработки основного функционала + переход в стадию поддержки/дополнения новых фич) работы может быть больше чем у девелоперов
[quote=“Roman_Griczko, post:1, topic:16818”]
отсутствие жестких дедлайнов,когда от скорости работы напрямую зависит выход нового релиза продукта
[/quote] - как раз очень даже наоборот, если вы работаете в команде, которая отвечает за качество + занимается автоматизацией, то перед релизом у них работы еще больше! А вот если это этакая сервисная тима, которая просто автоматизирует для других манульных тим, то тогда ей релизы вообще не страшны
[quote=“Roman_Griczko, post:1, topic:16818”]
как строится ваш рабочий процесс (хотя бы в общих чертах)
[/quote] - у нас сейчас как раз старт нового продукта, т.е. стоял вопрос выбора концепции, тем более, что корпорация дала “добро” на самостоятельный выбор. хотя перед этим пришлось доказать, что старые средства не подойдут. Вот-вот выйдем на старт написания тестов для новых фич, все уже готово, множество фич уже написано, но из-за некоторых блокеров мы их могли видеть только в виде кода. Так что теперь работы у нас будет выше крыши и очень быстро
Вы сильно заблуждаетесь. Если заказчик “дерзкий” - а-та-та и ра-та-туй, как впрочем и посиделки за буком до 3-4 утра, вам обеспечены. Да - ручками тоже придется тестить при форс-мажорах
Сфера деятельности интересная, а общий уровень загруженности представляется меньшим,чем в разработке.
Это действительно так (и по части загруженности тоже). Решать порой приходится очень нетривиальные задачи. И если предыдущая работа была связана с формошлепством, то однозначно будет интересно.
А рабочий процесс строится приблизительно так (из своего опыта разумеется):
Нужно определиться, какие тест-кейсы будете автоматизировать.
Нужно определиться со стеком технологий.
Весьма вероятно придется одновременно с тестами делать свой кастомный фреймворк, специфичный для проекта, ну или как минимум либу с хелперами.
Нужно будет тестовое окружение, где гоняются тесты. И почти 100% то, которое юзают ручники, не подойдет.
Нужна команда для автоматизации (одному скучно правда).
На первом этапе вашим тестам будут не доверять. У ручника ведь не воспроизводится - значит все норм. А то, что у девов код юнит-тестами не покрыт, и флаки-багов по самые уши, которые начинают лезть на больших цифрах и при множестве прогонов - это типа норм
Придется очень сильно доказывать, что тесты реально падают по реальным причинам. Т.к. часто будете слышать: “это твой скрип ломает приложение”.
Рекомендую юзать Jira и canban/agile-борды для отслеживания прогресса;
Также очень-очень здорово запускать тесты по ночам и утром делать анализ. Без постоянных запусков тесты протухают.
Постарайтесь также определиться, какой профит собираетесь приносить автоматизацией. Лучше сразу начать замерять, сколько экономите человеко-часов ручной работы, и т.п. Критериев оценки много. Нужно для того, чтобы менеджмент чувствовал пользу и больше и больше вкладывался в автоматизацию
Автоматическое заведение тасок в джире не ведем, есть человек, который разбирает отчеты по утрам. А потом распределяет падения на баги тестов и баги продуктов, и заводит баги в Jira.
Jira используем, чтобы трэкать прогресс по работе и выполненным задачам отдела.
В моем отделе это происходит так:
Есть jira board c полями stories, backlog, select4dev, inProgress, postponed, done, closed
В поле stories лежат глобальные таски, над которыми ведет работу команда. Эти таски обычно для разных проектов, причем один проект может включать несколько story-тасков.
Все другие таски должны принадлежать к какой-либо story-таске.
Итерация - 1 неделя.
Планирование итерации и распределение задач - в пятницу вечером.
В confluence храним инфу по проектам, куда линкуются story-таски.
Учитывайте тот факт, что во многих конторах почему-то меньше ценят нашего брата, я за последние два месяца пересмотрел кучу вакансий, и скажу вам что ЗП весьма плачевные бывают местами, а требования к кандидатам бывают весьма странные. Очень многие конторы хотят человека-комбайна, чтобы руками тестил, дизайны писал, автоматизировал все это, а еще и по возможности девопсил и требования писал
P.S.: Да и задач бывает по более чем в разработке, но это зависит от проекта
В основном хотят “комбайна” те конторы, которые жили не тужили без тестирования, и тут ОПА приехали, так срочно нужен авт. тестировщик, который сделает процесс тестирования с нуля, т.е. экономия на ресурсах, вместо 2-3 спецов, пусть один делает, и по практике - эти вакансии так и весят, периодически меняя должность (ведущий автоматизатор, эксперт, тимлид)
Ну не знаю, я думаю тут причина в другом. Просто считают нас несильно важными и по этому пытаются повешать еще другие задачи, а то че это ты мы какому-то тестировщику платим так много?)
Это только если проект вялотекучий. В динамическом проекте будете работать больше разработчиков.
При этом от в вас нужно будет не просто знание языка программирования (уровень, конечно, меньше разработчика), но и знание разных ОС, браузеров, если веб проект, + все то что делают мануальщики вы должны уметь, а там тоже не мало. В общем, скучно не будет.
Во многие компании уже давно не берут в QA без опыта работы девелопером , аналитиком, архитекторм , менаджером и тд и тп. По этому специалисты такого уровня обычно легко справляются с автоматизацией любой сложности да еще и код ревью делают девелоперам а иногда и код проекта поправляют. Работа простым автоматизатором это все равно что баги все время фиксить… так что рекомендовал бы просто перейти в специалисты по качеству
Нетривиальное желание, обычно все в точности до наоборот) Насчет загрузки - однажды работала на таком проекте, после которого потом год не могла прийти в себя. Но справедливости ради надо сказать, что девелоперам на нем было еще хуже. Если у нас был треш и угар в рабочее время, то они пахали и по вечерам, и даже по выходным. Поэтому если брать в среднем, то автоматизаторы и правда меньше пашут, но и зарплаты у них ниже. Тем не менее я бы хотела со временем перейти в разработку)
А я наоборот - в разработку решил переходить, прохожу обучение без отрыва от работы на Java мидла.
Еси вы работаете в продуктовой компании, то в принципе, работа автоматизатора может быть интересна, т.к. проект будет долгоиграющим и компания будет вкладываться в качество продукта. И вы сможете контролировать процесс покрытия тестами по всей пирамиде тестирования (как разработчик).
В аутсорсе много скучных проектов автоматизации - короткие, и основной KPI - скорость написания тестов. Работа не пыльная, но лично мне однообразие быстро надоедает.
Тогда такой вопрос: если у вас нет тестирования, то что же ты, милчеловек, собрался автоматизировать?
Автоматизатор тестирования прежде всего тестировщик и только во вторую очередь автоматизатор. Это в случае, когда нет чёткого разделения на ручных и автоматизаторов.
Если такое разделение есть (а это возможно только там где есть ручное тестирование), то автоматизаторы могут работать в нескольких режимах (в зависимости от того как организовано на проекте). Например:
тестируют вручную И автоматизируют
Самая простая начальная стадия развития автоматизации тестирования
пишут автотесты (и фреймворк для них) по сценариям ручного тестирования, вручную ПОЧТИ не тестируют
Это возможная стадия развития тестирования на проекте
пишут тулзы в помощь тестировщикам, а сами не тестируют. Тестировщики, используя тулзы (фреймворк и т.д.), тестируют вручную и автоматически.
Обычно такое применяется на матерых проектах, с богатой историей развития тестирования (начиная с ручного)
Таким образом, специализации “автоматизатор тестирования” в отрыве от тестирования не существует. В 3-м варианте моей классификации это может быть разработчик (без навыков тестировщика), но чаще всего автоматизатор тестирования ДОЛЖЕН уметь тестировать и быть готовым к ручному тестированию.
Я предположил,что если есть желание заняться автоматизацией тестирования,а отдела QA на текущем месте работы нет,то эту проблему тоже можно решить )
Например,сменой места работы.Довольно очевидно.
Была бы цель,а средства в ее достижении всегда найдутся.
testomat.io управление авто тестами
Уровень загруженности очень сильно зависит от пректа. Если проект только-только стартует, то первое время автоматеры находятся в относительно свободном режиме подготавливая то что и понадобится для автоматизации в будущем(тестовый фреймворк, выбор средств автоматизации, концепция и т.д.), на конечной стадии продукта (конец разработки основного функционала + переход в стадию поддержки/дополнения новых фич) работы может быть больше чем у девелоперов 
