Перспективы разработчика в автоматизации тестирования ПО

    Как и многим, нам в Veeam нужны разработчики автотестов. Обычно на эту позицию претендуют специалисты с опытом в ручном тестировании ПО, но зачастую у них может не быть навыков программирования. А программисты, как правило, нечасто стремятся в разработку автотестов. Между тем у нас в компании есть автоматизаторы, которые изначально были не тестировщиками, а программистами, и они очень хорошо себя проявили в автоматизации. В статье я расскажу почему такой вариант развития карьеры может быть интересен для разработчиков.

    Лирическое отступление

    Это только присказка, сказка впереди

    В начале 2000-x я работал в IT-компании, которая выполняла несколько аутсорсинговых проектов для компании Integrated Genomics. Проекты были связаны с расшифровкой геномов простейших организмов. К примеру, одна из утилит искала фрагменты (праймеры) с определенными свойствами в геноме кишечной палочки. На входе утилиты была последовательность ДНК, загружаемая из публичной базы геномов ERGO и состоящая из азотистых оснований. На выходе — таблица фрагментов и их позиция в цепочке ДНК. Далее эти фрагменты использовались биологами для синтеза геномов. Задача была сравнительно простой. Нужно было лишь позаботиться о том, чтобы программа не выжирала всю оперативную память довольно слабых машин, которые были у нас на тот момент. Сложность других проектов заключалась в том, что они находились на стыке трех дисциплин: биологии, математики и информатики. В тех случаях, когда алгоритм задачи был понятен, его реализация в программном коде не представляла трудности. Но когда сама задача была неопределенной, и не находилось никого кто мог бы ее формализовать, это был серьезный вызов. 

    Выяснилось, что для того, чтобы успешно решать такие задачи, нужны фундаментальные знания по биологии и высшей математике. Нас, молодых и горячих, это не остановило. Мы нашли англоязычную книгу по биоинформатике профессора Павла Певзнера и приступили к изучению. Поначалу повествование было легким и непринужденным. Во вступлении Павел рассказывал о том, как выживал в Москве в студенческие годы, и это было поистине приятное и расслабляющее чтение. Далее в первых главах речь шла про азотистые основания нуклеотидов ДНК — аденин, гуанин, тимин и цитозин — и про комплиментарность нуклеиновых кислот, а именно: как основания нуклеотидов способны формировать парные комплексы аденин—тимин и гуанин—цитозин при взаимодействии цепей нуклеиновых кислот. Было понятно, что такое свойство нуклеотидов играет ключевую роль в репликации ДНК. Я помню, что испытывал подъем и состояние потока, читая это объяснение, и мысленно представлял, как мы сейчас  быстренько все это освоим (подумаешь, биология) и сможем брать более серьезные задачи. Мы даже думали о том, что сможем написать свой геномный ассемблер и взяться за расшифровку простейших геномов. Продолжаю читать книгу, и тут бах — система уравнений на полстраницы без каких-либо объяснений. Из контекста подразумевалось, что эта система проще пареной репы, и любое объяснение будет оскорблением для читателя. Не было даже сноски для факультативного чтения. Я решил эту страницу пропустить, вернуться к ней позже и пока что продолжить читать дальше — вдруг станет понятно. Перелистываю страницу — а там еще одна система уравнений уже на всю страницу и скупое описание, часть слов из которого мы не нашли в словаре. Стало понятно, что эту область знаний на стыке геномики и математики нахрапом не возьмешь. Также стало понятно, почему подавляющее большинство коллег, с которыми мы взаимодействовали, имели биологическое и/или математическое образование. В конечном итоге, шаг за шагом погружаясь в основы геномики, нам удалось создать несколько программных продуктов, и тогда я в первый раз всерьез задумался о том насколько результативной и интересной может быть деятельность на стыке нескольких дисциплин.

    С тех пор еще не раз мне довелось сменить сферу деятельности, и в каждом случае навыки разработчика служили трамплином для решения новых задач. Так произошло и с автоматизацией тестирования ПО.

    Перспективы разработчика в автоматизации тестирования ПО

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

    Исторически сложилось так, что в автоматизацию приходят специалисты с опытом в ручном тестировании ПО. В какой-то момент они осознают, что рутинные операции можно и нужно автоматизировать, либо просто желают попробовать себя в новом качестве. Опыт, привносимый ручными тестировщиками в проект автоматизации, бывает архиполезным. Никто лучше них не знает возможности и слабые места продукта, наиболее трудоемкие сценарии для тестирования, окружение, в котором работает продукт, а также пожелания пользователей и планы на следующие релизы. Как правило, хороший ручной тестировщик четко понимает, что именно он хочет автоматизировать, но с написанием автотестов порой возникают сложности. Почему? Потому что автотесты — это такой же программный продукт, как и продукт, который они призваны тестировать. Нужно продумать архитектуру системы автотестов, механизмы их запуска (Continuous Integration, CI) и самое главное — нужно писать хороший код. По факту, для ручного тестировщика это зачастую оказывается непросто. Ведь здесь требуется создать полноценный проект, который можно интегрировать в CI, изменять, расширять и переиспользовать. Для этого нужны способности к программированию, накопленный опыт и набитые шишки.

    Ручной тестировщик с глубоким пониманием продукта и методик тестирования и разработчик с опытом программирования отлично дополняют друг друга. Первый силен в постановке задачи (use case -> test case), второй в ее реализации. Встает вопрос: почему среди автоматизаторов встречается много ручных тестировщиков?  На это есть несколько причин:

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

    • Для разработчиков переход в автоматизаторы в некотором смысле разрыв шаблона: «Вот я разрабатывал продукт, а теперь буду тестировщиком, который пишет автотесты — какой же я теперь разработчик?» Иными словами, есть опасение потерять квалификацию, превратиться в ручного тестировщика, а также нежелание глубоко погружаться в теорию и практику тестирования.

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

    • Опасение потерять в карьерном росте и зарплате.

    Разберем эти моменты.

    Автотесты — это такой же продукт разработки, как и тот продукт, для которого эти автотесты создаются. Если разработчик идет на позицию автоматизатора в выделенную группу разработки автотестов, он остается на стезе написания программного кода. Да, ему надо иметь представление о тестировании ПО, но базовые знания можно сравнительно быстро получить, пролистав какое-либо руководство по тестированию ПО (например, вот эту книгу). Безусловно, автоматизатору нужно понимать продукт, для которого он пишет автотесты. Но освоить продукт на приемлемом уровне зачастую оказывается легче, чем научиться писать хороший код. Знания о продукте и методиках тестирования будут расширяться по мере ознакомления с багами, написанными на продукт, и общения с ручными тестировщиками. Разработчик не перестанет быть разработчиком, не превратится в ручного тестировщика. Это не его путь. Путь разработчика — писать хорошие автотесты. 

    Задачи у автоматизатора интересные и зачастую сложные. В первую очередь стоит вспомнить про знаменитую пирамиду Фаулера. Модульные, интеграционные, end-to-end тесты подразумевают вдумчивый подход к структуре тестов и выбору инструментов в соответствии с функциональностью продуктов, для которых пишем автотесты. Если говорить о продуктах, разрабатываемых в Veeam, то автоматизатору понадобится работать с  REST, WebDriver, Microsoft SQL Server, Amazon Web Services, Microsoft Azure, VMware vCenter, Hyper-V — список не исчерпан. У каждого из облаков и гипервизоров свой API и свои скелеты в шкафу. Порой приходится писать код на различных языках программирования, использовать заглушки, семафоры, создавать свои обертки и т.п.

    Одну и ту же задачу можно решить по-разному, и автоматизатор ищет наиболее эффективное решение. Вот лишь один из примеров – сценарий, реализованный для продукта Veeam ONE. Один из компонентов продукта – Business View, который позволяет группировать элементы виртуальной инфраструктуры по различным критериям. Критериев и вариантов их комбинирования очень много, поэтому проверка этой функциональности вручную занимает много времени. Написание автотестов «в лоб» с имитацией действий ручных тестировщиков было бы неэффективным: тесты для графического интерфейса десктопных приложений, как правило, сложны и трудоемки в разработке, являются хрупкими, их тяжело модифицировать, и выполняются они долго. Мы нашли другое решение: поскольку действия пользователя в UI интерполируются в SQL-запросы к базе данных, мы используем SQL-запросы для создания категорий и групп. Это позволило нам в разумные сроки покрыть автотестами все свойства и операторы, задействованные в Business View.

    Как сделать так, чтобы тесты, запускаемые параллельно ради уменьшения общего времени запуска, не мешали друг другу? Как измерить покрытие продукта автотестами? Анализ покрытия кода? Анализ покрытия пользовательских сценариев? Как отслеживать падения сервисов? Как интегрировать автотесты с репортинговыми фреймворками? Как интегрировать автотесты со сборкой билдов в CI? Как прогонять тесты по pull-реквестам? И многое-многое другое.

    Нужно обратить внимание на качество самих автотестов. Кто сторожит сторожей? Какому автотесту можно доверять?  Автотест должен быть эффективным по критерию “количество затраченных на него усилий / полученный результат”, автономным, стабильным (нехрупким), быстрым, надежным (никаких false positive и false negative). В автотесте должен быть понятный, хороший код с точки зрения возможностей языка программирования, чтобы этот код можно было легко расширять и изменять.

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

    Что в Veeam?

    В компании Veeam мы будем рады новым боевым товарищам с опытом программирования на C# (например, web-интерфейсы, десктопные приложения, консольные утилиты и т.п.). У нас в Veeam есть много продуктов. Технологии в них могут различаться. В автотестах для нескольких продуктов мы опираемся на REST и WebDriver. Если у вас нет опыта с этими технологиями, но вы уверенно себя чувствуете в написании кода на C# и питаете интерес к автоматизации тестирования, то, возможно, мы также найдем точки соприкосновения.

    Мы будем рады вашему резюме и паре абзацев о том, что вас привлекает в автоматизации, о ваших сильных сторонах и профессиональных планах. Пишите нам на ящик qa@veeam.com – внимательно прочитаем. Если укажете в теме письма [Хабр] (например, [Хабр] Позиция автоматизатора), будет плюс в карму.

    Да пребудет с Вами Сила.

    Veeam Software
    Продукты для резервного копирования информации

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

      +2
      Про вашу «заинтересованность» в кадрах легенды ходят)
        +2
        Расскажите, пожалуйста, какие именно? Самим интересно.
          +1
          1. Сотрудники и софт скиллы — просто откройте первую линку по запросу «Veeam отзывы сотрудников».
          2. Шестиэтапное собеседование. И это не Amazon, который релоцирует в Новую Зеландию.
          3. Обратная связь — слишком затянута по времени. Пока кандидат получит фидбек, он просто примет оффер от другой компании.
          4. Одни и те же вакансии на hh висят по полгода, а это заставляет задуматься:
          а). Либо компания лишь создает видимость найма кадров;
          б). Либо внутренние процессы мешают найти сотрудника.

          Комментарий написан, опираясь на личный опыт и опыт коллег.
            +2
            1. Постоянно открываем, читаем, анализируем и делаем выводы. К сожалению, большая часть этих отзывов написана людьми не прошедшими собеседование и находящимися в состоянии мыши надутой на крупу. Что же до релевантной части отзывов, то можно сказать только одно — идеальных людей, которые нравятся всем на свете, не существует, так что мы тут не исключение.
            2. А сколько этапов должно быть у собеседования, если мы, например, релоцируем в Прагу? Да и как-то не приходилось мне слышать про такие, хотя работаю в Veeam уже больше семи лет. Но даже если допустить, что действительно в какие-то отделы проводят шестиэтапные собесы (хотя ума не приложу, что они там делают) и продолжает эффективно выполнять свою работу, то, вероятно, они делают всё правильно и у них есть причины проводить столько этапов отбора.
            3. Над обратной связью мы постоянно работаем и обязательно всегда её предоставляем. Но да, бывают определённые провалы и проводивший собеседование не всегда даёт моментальный фидбек. Так что вы снова нас подловили — мы не идеальны.
            4. О, это мой самый любимый пункт. Я вам даже больше скажу: некоторые вакансии висят годами. Вот прямо действительно годами. И вы даже почти ловко раскрыли наш хитрый план по проведению собесов ради собесов и имитации бурной деятельности, но упустили один важный момент — компании уже почти 15 лет, и все 15 лет она растёт как не в себя. А для этого роста постоянно требуются люди. Так что да, много вакансий действительно висит и по полгода, и год, и даже больше. Но вы были очень близко к раскрытию нашего тайного плана по созданию видимости найма.

            Спасибо вам за комментарий. Как видите, мы их действительно читаем, анализируем и делаем выводы.
              +1
              Очень приятно, что общаетесь со своей аудиторией. Спасибо, что ответили на каждый из пунктов. Ни в коем случае не хотела принизить заслуги компании, и уж тем более задеть преданных сотрудников, которые посвятили ей не один год. Круто, что вы растете и развиваетесь. Собственно и комментарий был написан, поскольку я — ваш подписчик)
              В любом случае желаю вам успехов и хороших коллег!
            0
            Расскажите, пожалуйста, какие именно? Самим интересно.
            Легенд не знаю, но попасть в Veeam достаточно трудно. Хотя компания с мировым именем и для такого уровня, видимо, так и должно быть. Опишу свой опыт. Я сам проходил собес в Veeam. Решил тестовое, но лиды завалили на тех.интервью, сказав «Приходите через годик.» На тот момент не искал работу, поэтому не сильно расстроился. Но через время присмотрелся к компании, да и в новостях проскочили, и подумал «а почему бы и нет?!». Решил отправить отклик, но фидбека вообще не получил. Никакого. Ладно бы написали: «Не подходите» или «Вы — в черном списке с прошлого интервью», но просто молчание.
            В целом интервью и сама компания в лице лидов и HR с прошлого собеса оставили положительное впечатление. Успехов вам!
              0
              Подтверждаю, во многие отделы у нас действительно весьма строгий отбор. То есть наша политика не заваливать проблемы людьми с рынка, а тщательно отбирать кандидатов, чтобы в итоге все были счастливы.

              Если вы откликались в декабре и не получили ответа, это ненормальная ситуация и явно что-то сломалось. Киньте в личку на какую должность откликались и фио, будем разбираться и накажем виновных =)
          0
          В какой-то момент они осознают, что рутинные операции можно и нужно автоматизировать, либо просто желают попробовать себя в новом качестве.

          Вообще-то, (1) сходу +$100 к зп, (2) уход от социального ярма "А чо, всю жизнь будешь тестером?!" и (3) ощущение постоянной движухи. На самом деле — ненужная суета, но поначалу это незаметно и воодушевляет.

            0

            Разработчик — это тот, кто пишет код. А что этот код делает — продукт для конечных потребителей или других разработчиков — это уже вторично.


            На одну из озвученных проблем, кажется, вы так и не дали ответа — «Опасение потерять в карьерном росте и зарплате.». Сколько менеджерской работы нужно выполнять разработчику автотестов, чтобы приблизиться к зарплате разработчика веб приложений?


            Ну и основная проблема, которую могут просто подразумевать, но не озвучивать. Разработка авто-тестов (чаще всего, веб приложения) — это узкая ниша. Точно такая же, как «Разработчик Shopify» или «Разработчик Wordpress». Большой ли спрос у компаний на разработчиков автотестов в сравнении с, например, Python/Javascript разработчиками?

              0
              Виктор, добрый день. Спасибо за комментарий.

              Спрос на разработчиков автотестов достаточно большой. При этом не исключаю, что количество вакансий для продуктовых разработчиков на Python/Javascript может быть больше.

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

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

                А что, если конкретнее? Возьмём условного middle+/senior- веб разработчика Javascript/Python/PHP/Ruby с ЗП $3000-$4000. Должен ли разработчик автотестов выполнять какие-то непрямые обязанности, чтобы получать такую же сумму (например, брать под свое крыло начинающих автоматизаторов, как указано в статье)? И сколько у вас в компании таких разработчиков?


                Также, давайте представим ситуацию, что разработчик проработал у вас несколько лет в автоматизированном тестировании и решил поменять работу. Как по вашему, насколько дольше он будет искать работу в качестве разработчика автоматизированных тестов, чем разработчик JS/PHP/… ?


                В целом, моя мысль в том, что разработчик автоматизированного тестирования — это просто очередная узкая ниша в разработке. И компания должна иметь это ввиду, ориентируясь в окладе. То есть, если предложение в этой нише невелико (например, потому что сложно и важно), то ЗП должна быть выше. А если предложение больше (как Wordpress например, с небольшим порогом входа) — то, конечно, уже другое дело.


                Но говорить, что разработка автоматизированного тестирования — это та же самая разработка, — на мой взгляд, неправильно, потому что это довольно узкая, ответственная и объёмная по знаниям ниша.

                  0
                  Виктор,

                  Veeam — большая компания. Много проектов, много групп разработки. Задачи и обязанности можно обсуждать и находить компромисс. Если тому или иному специалисту ближе продуктовая разработка на Javascript/Python/PHP/Ruby, и он доволен своими задачами и бенефитами, то это его путь.

                  На мой взгляд, каждый разработчик может определить лично для себя что именно ему интересно по задачам, и какие бенефиты он хочет получить. Далее он смотрит на предложения на рынке и находит для себя подходящую позицию — например, по критерию «хочу/могу/востребовано» или по любым другим критериям, важным лично для него.

                  Выбор пути всегда подразумевает какие-то компромиссы. Трудно быть мастером на все руки. Если разработчик пишет код на C# (будь то сам продукт или автотесты для него), ему потребуются некоторые усилия, чтобы перейти на JS/PHP.

                  Безусловно, стезя разработки автотестов — важная, ответственная и объемная по знаниям. И потому ценная.
              0
              > поскольку действия пользователя в UI интерполируются в SQL-запросы к базе данных, мы используем SQL-запросы для создания категорий и групп

              Но, кстати, тоже скользкая дорожка. Ускорение очевидно, но приходится следить за структурой базы. Если между UI и базой есть какой-нибудь API, лучше им воспользоваться, а то изменение БД-записей напрямую всё же более опасная операция, чем использование API.
                0
                Luckman, да, совершенно верно.
                  0
                  А какая разница? Изменение структруы БД ведет за собой обновление контрактов API, если не автогенерируемый клиент, необходимо будет точно так же отслеживать изменения контрактов. А вообще в автотестах нужно и использование эмулятора(API) и SQL запросы -они не взаимозаменяемые, у каждого из них своя зона ответственности.
                    0
                    Один API-запрос может сразу в несколько таблиц залезать. Он может не измениться, даже если БД структура сильно изменится.
                    + про API иногда бывает документируемым, и изменения в нём проще отслеживать, а про изменение структуры базы часто узнаёшь по факту красной регрессии.

                    В SQL лучше лезть только когда нет варианта с API, но да, это тоже бывает довольно часто.
                      0
                      Именно поэтому API и SQL не взаимозаменяемые, если есть логика приложения при формировании сущности — API, если ее нет, нужна операция клонирования с изменением нескольких полей, к примеру — SQL процедура.

                      В большинстве случаев, если делают документированный API выпускают клиентов под разные языки. Таким образом необходим шаг, который проверял, что версия используемого клиента соответствует версии тестируемого объекта, если шага такого нет — красный регресс, который узнаешь по факту.

                      Для разработки модуля, реализующего SQL шаги, можно применить Database-first подход. Таким образом будет отдельный шаг, который будет синкать entity, дальше можно заиспользовать верификацию контрактов(я делал через верификацию маперов в AutoMapper), и в случае, если верификация не пройдена, блокируется начало выполнения тестов.

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

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