В IT все происходит стремительно, и полгода-год — достаточный срок для кардинальных перемен. Это применимо и к автоматическому тестированию. Чтобы узнать, как изменился этот сегмент и отношение самих тестировщиков к своей профессии, поговорим с двумя опытнейшими специалистами в этой области — Игорем Хролом и Илари Хенриком Эгертером.




Игорь Хрол — специалист по автоматизации тестирования, около 10 лет работает в этой области в различных ролях: как инженер, архитектор, менеджер, тренер, консультант. Имеет большой опыт использования большинства популярных инструментов  (Selenium, HP QTP, TestComplete, JMeter). Программирует в основном на Ruby и Scala, но и на других языках также приходилось писать (Python, Java, C#, JavaScript, VBScript).
Сейчас работает в Toptal.

— Добрый день, Игорь. Многие читатели уже знакомы с вами и видели выступление в прошлом году на конференции Гейзенбаг. Если не секрет расскажите, пожалуйста, чем сейчас вы занимаетесь сейчас? Над чем идет работа?

Игорь Хрол:
Доброго дня! С прошлого Гейзенбага род моих занятий принципиально не изменился — я все еще работаю в отделе аналитики компании Toptal. Правда, с того момента изменилась должность, я был QA Automation Engineer, а сейчас Team Lead. Теперь могу влиять на качество итогового результата по всем фронтам: и с точки зрения тестирования, и со стороны разработки, ну и организационные улучшения тоже не обходятся без меня.

Мы работаем над тем, чтобы давать бизнесу актуальную информацию. Собственно, об этом я и буду рассказывать в своем докладе в Санкт-Петербурге: как проверять отчеты, корректность поступающих данных, какая архитектура приложения подходит для решения подобных задач. Ну и, конечно, в большинстве своем это все про автоматизацию тестирования и написание кода. Мы не любим повторять одно и то же много раз и тестируем в основном автотестами.

От модных трендов Toptal не отстает, конечно. Внедряем технологии машинного обучения и прочего модного data science. Похоже, доклад про это будет хорошей темой для следующего Гейзенбага.

— Cовременный автотестер — это мастер на все руки или узкий специалист?

Игорь Хрол:
Мне хотелось бы верить, что мастер на все руки. Если бы это было не так, то вряд ли бы я занимался этим 10 лет — стало бы скучно. Я не верю в узкую специализацию в IT вообще. В моей картине мира хороший инженер должен знать смежные области. Разработчик должен уметь тестировать и писать автотесты. Тестировщик — писать код и понимать вопросы управления. Я видел много глупостей и потерянного времени именно из-за того, что люди пилили свою узкую задачу и в силу разных причин не решали ее совместно с другими специалистами.

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

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

— Часто мы можем увидеть советы о том, как быстро стать гуру в определенной области, например, освоить язык за два месяца. Как вы считаете, автоматизация тестирования приемлет такую спешку или специалисты в данной области — это в большинстве бывшие разработчики?

Игорь Хрол:
По моим наблюдениям, специалисты в автоматизации тестирования — это в большинстве своем бывшие тестировщики, а не разработчики. Есть среди них разработчики, но не бывшие, а текущие. Это люди, которые в процессе разработки пишут большое количество автотестов и так или иначе сталкиваются с проблемами этой области. Что интересно, чаще именно они, а не автоматизаторы, выросшие из тестировщиков, двигают экспертизу в этой сфере вперед.

По поводу изучения языков за два месяца. За этот срок можно стать junior-специалистом, если есть склонность и стремление. Гуру не станешь, но работу найти можно будет. А дальше — годы реального опыта, пока не придет просветление.

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

Игорь Хрол:
Модульное тесты взаимодействуют непосредственно с кодом и очень часто, чтобы он был тестируемым, его нужно менять. Я слышал истории отдельных команд, пишущих юнит-тесты после кода, но я слабо представляю, как это может нормально работать. Плюс ко всему, я не понимаю, зачем в принципе выделять написание тестов отдельным людям. У нас (в Toptal) автор изменения сам добавляет нужные тесты (не только модульные), и ничего плохого не происходит. Когда так делаешь, лучше понимаешь, как конкретно должен использоваться класс, API или как пользоваться тем, что написано.

Что касается огромных проектов и команд по автоматизации тестирования: я вел автоматизацию проектов по сервисному принципу, когда отдельной команде приходит запрос на автоматизацию в виде тест-кейсов, и они дружно пишут автотесты. Это были действительно большие проекты на несколько десятков автоматизаторов. Честно скажу, мне не очень понравился результат. Автотесты — это неотъемлемая часть продукта. И когда ими занимаются отдельные люди, не вовлеченные плотно ни в процесс разработки, ни в процесс тестирования, эти тесты становятся отдельной вещью в себе, нужной только самим автоматизаторам. Я называю это «писать тесты в тумбочку». С точки зрения формальных показателей выглядит все прилично — работа кипит, покрытие растет, а по факту эти автотесты используются очень мало.

Мне больше нравится подход Spotify, когда есть отдельные автономные команды состоящие из специалистов разного профиля, и при этом есть «гильдии», объединяющие одинаковых специалистов и решающие общие вопросы. Работая внутри команд, лучше понимаешь, что нужно для решения конкретных задач, и быстрее решаешь вопросы, которые стоят на пути автоматизации.

— Хотелось бы задать вам вопрос, связанный с использованием Selenium WebDriver. Вы говорили, что активно следите за данным направлением начиная с версии 0.8. Как вы относитесь к тому, что стандарт W3C WebDriver получил статус W3C Candidate Recommendation? Как вы думаете, это приведет к активной доработке Selenium-а?

Игорь Хрол:
Сам WebDriver уже давно сильно не меняется, по крайней мере внешне. В том числе благодаря этому он и стал стандартом. Что меняется — это качество реализации и поддержки на разных браузерах. Разработчики браузеров лучше знают, как сделать правильно, и могут менять, в том числе, сам браузер. И W3C «заставляет» их заниматься поддержкой WebDriver’a самим браузером.

Сейчас активно развиваются надстройки над Selenium’ом, вроде Selenide’a. Ситуация напоминает JavaScript и jQuery. Чистый Selenium/WebDriver хорошо знать, но пользоваться удобнее более высокоуровневыми библиотеками, в которых решены типовые задачи, специфические для взаимодействия с пользовательским интерфейсом.

— С момента участия в прошлогодней конференции Гейзенбаг изменился ли у вас подход к тестированию или набор программ, который вы используете?

Игорь Хрол:
Полгода — это не такой большой срок для того, чтобы кардинально менять подход. Хотя, конечно же, мы пересматриваем наше тестирование, и оно эволюционирует. За последнее время мы начали активней использовать model based testing для тестирования наших бизнес-процессов. Если в двух словах, то мы случайным образом ходим по нашим workflow, глядя на возникающие проблемы и противоречия.

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

— Огромное спасибо. С нетерпением ждем вас на конференции.

Игорь Хрол:
Спасибо!

Илари Хенрик Эгертер — специалист по программной инженерии и тестированию ПО, более 10 лет работает в этой сфере, начиная с области программного обеспечения и заканчивая электронной коммерцией на eBay. В 2013 году стал соучредителем Международного общества тестирования программного обеспечения (ISST), которое выступает за возвращение здравого смысла к тестированию, и сейчас является президентом организации. В 2015 году был избран в совет Ассоциации по тестированию программного обеспечения (AST), где выступает в качестве вице-президента по маркетингу.
В настоящее время управляющий директор House of Test GmbH.

— Илари, добрый день.  Расскажите, пожалуйста, о себе и своей работе.

Илари Хенрик Эгертер:
В тестирование я пришел скорее случайно. Четырнадцать лет назад я изучал лингвистику и социологию в университете в Цюрихе, и там была работа в компании по медицинскому оборудованию, связанная с установкой ПК. Они также нуждались в тестировании, и именно поэтому я основательно подсел на данный вид деятельности. Мне очень понравилось сочетание социальных элементов и техники в этой работе. Через пару лет, уже став линейным менеджером всей команды, я также решил изучить разработку программного обеспечения. Затем я сменил работу и перешел в eBay, где возглавил группу тестирования для сайтов eBay в Европе.

Два года назад я стал независимым с House of Test, и мы начали развивать свою команду. В настоящее время у нас на полной ставке семь инженеров-тестировщиков, которые работают в качестве внешних подрядчиков в самых разных отраслях. Помимо управления компанией, я являюсь вице-президентом по маркетингу в Ассоциации по тестированию программного обеспечения. Каждому тестировщику, гордящемуся своим ремеслом, советую присоединиться к нам. В личной жизни я люблю читать, проводить время с семьей и увлекаюсь пивоварением.



— В прошлом году вы выступали с докладом «No Such Thing as Manual Testing and Other Confusions». Ваша аудитория состояла из людей из различных областей: тестировщиков, менеджеров, разработчиков. Как вы думаете, почему люди разных направлений так активно интересуются вопросами тестирования? Связано ли это с тем, что компании постепенно становятся зависимы от автоматизации тестирования?

Илари Хенрик Эгертер:  
Я думаю, что когда вы тестировщик, то вполне естественно интересоваться вопросами тестирования. Кроме того, различные должности вне тестирования, безусловно, вовлечены в процесс, и я приветствую их интерес к этой области. Использование инструментов в автоматизации, безусловно, становится все более продвинутым. Я хотел бы отметить, что автоматизация тестирования не может быть самоцелью. Цель — найти адекватные решения проблем. Некоторые из них можно решить с помощью автоматизации, к остальным требуются более подходящие решения.

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

Илари Хенрик Эгертер:  
Я думаю, что большинство людей мало подходят для той работы, которой они занимаются, и поэтому результат не всегда хорош. Экспертиза по определению редка.

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

Мое понимание тестирования ориентировано на человека, поскольку тестирование удовлетворяет потребность в информации о состоянии продукта и выявляет угрозы для своевременной поставки продукта. Многое из этого может быть сделано только здравомыслящими людьми. Вы не можете автоматизировать вопрос «уместна ли автоматизация здесь?».

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



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

Илари Хенрик Эгертер:  
Я никогда не говорил, что вам не нужны технические навыки для автоматизации. Автоматизация в тестировании — это проект по разработке программного обеспечения, и поэтому он, конечно, нуждается в инженерных знаниях. Причина, по которой я уделяю много внимания коммуникации, критическому мышлению и эпистемологии, состоит в том, что они часто игнорируются, хотя являются важными элементами, которые должны быть — назовем это — полным набором тестировщика.

— Скоро вы будете выступать с докладом «Think Bigger – How to Truly Become World-Class in Testing». Что вы хотите добиться от аудитории, показывая примеры и шаги для достижения целей в автоматизации тестирования? Какую отдачу вы хотите получить? Важно ли вам знать, что ваша информация помогает уложить данные в головах у собравшихся и направить их мысли в нужное русло?

Илари Хенрик Эгертер:
Опять же, у меня есть целостный взгляд на тестирование, и автоматизация является его частью. Я хочу добиться того, чтобы люди начали размышлять о том, что значит быть отличным тестировщиком. Я хочу, чтобы люди пришли к своим собственным выводам, и они не обязательно должны быть такими же, как у меня. Я не обладаю истиной, но у меня есть обоснованное мнение. Я хочу, чтобы люди тоже бросили мне вызов. Если я начну активные беседы с людьми, и если у меня будет такое впечатление, что люди начали размышлять, это будет то, что я хотел бы получить в них ответ.

— Большое спасибо за ваши ответы. Будем с нетерпением ждать ваше выступление.

Илари Хенрик Эгертер:
До встречи на Гейзенбаг в Санкт-Петербурге.

Больше информации и знаний  по автоматизации тестирования, инструментарию, окружению для тестирования и другим направлениям в этом нелегком ремесле вы можете узнать на предстоящей конференции Гейзенбаг 2017 Piter 4 июня. Мероприятие соберет автоматизаторов, разработчиков, управленцев, да и просто фанатов тестирования. Ждем вас!

Возможно, вас заинтересуют материалы по автоматизации тестирования.
Видеозаписи с Гейзенбаг 2016 Moscow, а также интервью с Никитой Макаровым на тему Тестирование: простая дорожка в IT или серьезная затея?
Поделиться с друзьями
-->

Комментарии (13)


  1. Iron_Max
    17.05.2017 16:16
    +1

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


    1. VolCh
      17.05.2017 17:27

      Тестирование не повышает качество, а лишь сигнализирует есть ли с ним проблемы. И это не единственный источник сигналов.


      1. Iron_Max
        17.05.2017 18:32

        Я знаю, что так далеко не у многих, но у нас в компании тестировщик выступает сразу в нескольких ролях.
        1. Проверяет итоговый продукт на пригодность/соответствие требованиям. Как со стороны пользователя, так и со стороны требований заказчика (тут вообщем ничего нового)
        2. Активно участвует в организации новых фич для продукта. Поскольку заказчики/PM'ы не всегда видят техническую сторону продукта, а у разработчиков не всегда хватает времени/желания придумывать себе новые задачи, то тестировщик аккумулирует в себе гуманитария и технолога, и за счет этого создает новые таски. Которые в последствии попадают к PM'у/заказчику
        3. Помогает в написании ТЗ. Это возможно не только потому что тестировщик способен понимать, где находится «тонкий лед», но и сразу может писать ТЗ так чтобы итоговую программу можно было грамотно тестировать.
        4. Пишет автотесты/тест кейсы. К слову о последних — они так же часто выступают как своеобразный аналог ТЗ, в который тоже можно посмотреть и узнать где, как и когда работает.


        1. VolCh
          17.05.2017 22:15

          Это роли тестировщика, я же про процесс тестирования :)


      1. Fesor
        17.05.2017 19:51

        testing vs checking. Надо все же различать о чем мы говорим.


        1. VolCh
          17.05.2017 22:14

          Что для вас значит testing?


          1. Fesor
            18.05.2017 01:32

            Больше поиск новых кейсов, анализ качества продукта, то что нельзя автоматизировать. Exploratory testing, a/b testing и т.д — вот это инструменты которые могут помогать отвечать на некоторые вопросы в этом контексте. Соответственно "тестирование" может приводить к повышению качества так как анализируется именно оно.


            а автоматические тесты — это как раз про checking. Верификация системы на предмет соответствия требованиям.


            Ну а вопрос нужно или нет автоматизировать верификацию как по мне глупый. Это быстрее, дешевле и удобнее. Так же если этог оне делать скорее всего не будет времени на собственно тестирование.


            1. VolCh
              18.05.2017 10:10

              Пост всё же об автоматизации тестирования, скорее всего о checking в вашем смысле


  1. kna986
    17.05.2017 18:21
    +1

    «Помимо управления компанией, я являюсь вице-президентом по маркетингу в Ассоциации по тестированию программного обеспечения. Каждому тестировщику, гордящемуся своим ремеслом, советую присоединиться к нам.» Забавно, но факт — «The active presidents of the International Society for Software Testing have taken the decision to disband the organisation.»


    1. lxsmkv
      18.05.2017 11:52
      +1

      я думаю имеется ввиду https://www.associationforsoftwaretesting.org/


      1. ARG89
        18.05.2017 12:16

        Да, спасибо, пофиксил ссылку.


  1. Sh1k4r1
    18.05.2017 10:35

    http://www.commonsensetesting.org/ — Щас как зайду, как присоединюсь.
    The International Society for Software Testing is disbanded :(


    1. ARG89
      18.05.2017 11:08

      Мда, конфуз!