Для чего нужна автоматизация тестирования
Что дает автоматизация тестирования
При создании IT-решений ошибки обходятся дорого, это особенно заметно в медицине, где от качества ПО зависят человеческие жизни, или в сфере банкинга, где возможны крупные финансовые потери. Автоматизация тестирования позволяет организовать постоянную проверку качества продукта. Давайте разберемся, в каких случаях она необходима.
Одни компании ошибочно считают, что автоматизация – пустая трата времени и средств, другие – что это крутой тренд и «таблетка» от всех болезней. Рассмотрим, где золотая середина и в чем смысл автоматизации.
Зачем тестировать
Малейшая ошибка в программном обеспечении грозит огромными расходами. Чем лучше выстроены процессы разработки, тем меньше риски. Однако, если обратиться к фактам, мы видим, что недочеты допускают даже такие гиганты, как Google, Microsoft или ведущие банки.
Например, одна из знаменитых “аварий” финансового мира произошла в Первом национальном банке Чикаго в конце 90-х: в одночасье счета клиентов безосновательно выросли на 900 миллионов долларов. Тогда старший вице-президент банка Джеймс Ланкастер признал, что дело в «программной ошибке в компьютере» – которую, к счастью, никто не успел использовать.
Дорогостоящие ошибки бывают и в других отраслях, казалось бы, не связанных напрямую с IT. Известный пример – аварии при запуске космической техники, в частности, в 2017 году Роскосмос утратил спутник стоимостью 2,6 млрд рублей.
При работе с масштабными IT-решениями, например, системами дистанционного банковского обслуживания (ДБО), важно постоянно тестировать не только работу отдельных функциональностей, но и их взаимодействие. В условиях сжатых сроков, когда ведущие банки каждый месяц обновляют свои приложения, проверить все вручную невозможно – на это как минимум не хватит времени.
При создании IT-продуктов для бизнеса обычно сочетают два подхода:
Что дает автоматизация
Это одно из достаточно новых направлений в разработке, окруженных большим количеством мифов. Чаще всего бизнес обращается к автоматизации, веря, что она:
В свою очередь, два последних утверждения действительно справедливы: грамотная автоматизация тестирования помогает и в ускорении релизов, и в увеличении покрытия кейсов. При этом ручное обеспечение качества и автоматизация, как правило, одинаково важны и используются в комплексе. Кроме того, каждый проект индивидуален, и иногда в автоматизации нет необходимости.
Когда автоматизация обязательна
Задачи автоматизации
Как правило, мы привлекаем экспертов SDET для решения следующих задач:
Результаты
Автоматизация помогает выстроить баланс:
Кроме того, при необходимости можно ускорить релизы. Например, если в спринте разработки нужно проверить около 400 кейсов, то их ручная проверка займет до двух недель, а автотесты можно провести ночью и проанализировать за 4 часа.
Бизнес, благодаря автоматизации, получает возможность в любое время убедиться в том, что ключевые функции системы работают правильно и проверить, нет ли ошибок (а если они есть, то в чем заключаются).
Пример
Предположим, что на текущий момент в мобильном банке нужно проходить до 700 кейсов, каждый – от 70 до 100 раз в год. Ручной проверки требуют менее 25% кейсов, остальные 75% можно автоматизировать.
Затраты времени при ручной проверке:
Затраты времени при автоматизации:
Ночной прогон тестов занимает 8 часов, но без участия человека, поэтому не учитывается.
Прочие затраты времени:
Конечно, каждый кейс имеет свои особенности, поэтому временные затраты могут быть разными. Мы постоянно анализируем, сколько времени нужно на написание автоматических тестов, поддержку, анализ результатов.
В среднем, автоматизация экономит от 30 до 50% времени как минимум, позволяя выделить больше времени, например, на развитие и улучшение продукта.
Как происходит автоматизация тестирования
У каждой IT-компании есть свои особенности в автоматизации тестирования, как и в других рабочих процессах. Мы в SimbirSoft придерживаемся следующих методов, которые помогают оперативно выстроить работу с проектами наших клиентов.
Процесс тестирования начинается с разработки стратегии – тест-плана, основы для составления отдельных тест-кейсов. Для автоматизации SDET инженеры выбирают ключевые, часто используемые сценарии работы пользователя с продуктом – такие сценарии дают около 80% бизнес-ценности.
После этого мы создаем основу для дальнейших автотестов, настраиваем стенды и workflow по работе с ними, CI для регулярного запуска тестов на различных ветках. Мы выбираем, какие подходы к подготовке тестовых данных мы будем использовать (API, доступ к базам данных, генерация синтетических данных, использование данных с прода). Инженеры SDET пишут тесты, которые покрывают ключевые сценарии работы с продуктом, анализируют полученные результаты и необходимость дальнейшей автоматизации.
Мы разрабатываем автоматизированные тесты, используя все наиболее востребованные языки программирования – Java, Python, Kotlin и др. Наши основные инструменты и технологии – Appium, TestNG | JUnit, RobotFramework | Pytest, Selenium | Senenide, Allure, TeamCity, Jenkins, JMeter.
Какие тесты нужно автоматизировать в первую очередь – зависит от особенностей конкретного продукта. Большинство компаний автоматизируют smoke тесты, регрессионные тесты для проверки уже готовых функциональностей, а также кейсы для проверки различных параметров (например, валидных и невалидных данных при регистрации).
Мы в своей практике выстраиваем процессы автоматизации тестирования уже на старте разработки, параллельно с ручным тестированием. Эта работа – не единоразовая, она ведется непрерывно, особенно на крупных проектах, в том числе банковских.
Подводя итоги
Баланс ручного и автоматизированного тестирования позволяет постоянно контролировать качество IT-продукта. Некоторые проекты проверяют вручную, другие задачи можно успешнее решить с помощью автоматизации. Тестирование вручную используют в тех случаях, когда люди незаменимы, например, если нужна локализация, описание ошибок, ручная проверка юзабилити. В небольших проектах часто тесты пишут сами разработчики.
Ручное тестирование в комплексе с автоматизацией проводят при создании крупных IT-продуктов, где работает несколько команд (например, в банковских приложениях), где есть сложные алгоритмы и бизнес-логика. Этот метод помогает выстроить процессы тестирования продукта и снизить риск дорогостоящих ошибок, что бывает особенно важно при работе в условиях жесткого графика релизов.
Спасибо за внимание! Надеемся, что статья была вам полезна!
Автоматизация тестирования: кто должен этим заниматься, кому это нужно и как меняется эта область
В 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 или серьезная затея?
Для чего нужна автоматизация тестирования
Что такое автоматизированное тестирование?
Автоматизированное тестирование или автоматизация тестирования – это метод тестирования программного обеспечения, который выполняется с использованием специальных программных средств, которые, в свою очередь необходимы для выполнения набора тестовых примеров. Напротив, ручное тестирование выполняется человеком, сидящим перед компьютером и тщательно выполняющим каждый шаг теста «руками».
Программное обеспечение для автоматизации тестирования также может вводить тестовые данные в тестовую среду, сравнивать ожидаемые и фактические результаты и создавать подробные отчеты о тестах. Как правило, автоматизация тестирования требует значительных вложений денег и ресурсов.
Последовательные циклы разработки, особенно в крупных компаниях (Google, Facebook, Альфа-Банк, Газпром нефть и т.д.) потребуют многократного выполнения одного и того же набора тестов. Используя инструмент автоматизации тестирования, можно записать этот набор тестов и при необходимости воспроизвести его. После автоматизации набора тестов вмешательство человека не требуется. Это улучшило ROI автоматизации тестирования. Цель автоматизации – уменьшить количество тестовых примеров, которые нужно запускать вручную, а не полностью исключить ручное тестирование.
Какие тестовые случаи стоит автоматизировать?
В процессе автоматизации выполняются следующие шаги:
Выбор инструмента тестирования
Определяем объем автоматизации
На этом этапе выполняются сценарии автоматизации. Сценариям необходимо ввести тестовые данные, прежде чем они будут запущены. После выполнения они предоставляют подробные отчеты об испытаниях.
Выполнение может быть выполнено с использованием инструмента автоматизации напрямую или с помощью инструмента управления тестированием, который вызовет инструмент автоматизации.
Пример: Центр качества – это инструмент управления тестированием, который, в свою очередь, вызывает QTP для выполнения сценариев автоматизации. Скрипты могут выполняться на одной машине или на группе машин. Для экономии времени тестирование можно проводить ночью.
Обслуживание автоматизированного тестирования
Этот этап автоматизированного тестирования проводится для проверки того, как работают новые функции, добавленные в программное обеспечение: нормально или нет. Сопровождение в автотестировании выполняется, когда добавляются новые сценарии автоматизации, и их необходимо проверять и поддерживать, чтобы повышать эффективность сценариев автоматизации с каждым последующим циклом выпуска.
Приведенные выше рекомендации, если их соблюдать, позволят качественно выполнить автоматизацию тестирования.
Преимущества автоматизации тестирования
Инструменты автоматизации тестирования
На рынке доступно множество инструментов для функционального и регрессионного тестирования. В следующих выпусках расскажем в пользу чего делают выбор наши практикующие специалисты.
Это универсальный инструмент для автоматизации функциональных тестов пользовательского интерфейса, регрессионных тестов, тестов на основе данных и многого другого. Ranorex Studio включает простой в использовании интерфейс для автоматизации тестирования веб-приложений, настольных и мобильных приложений.
«Самый быстрый путь к отказоустойчивым сквозным тестам – без кода, с кодированием или и тем, и другим. Testim позволяет создавать удивительно стабильные тесты без кода, которые используют наш ИИ, а также гибкость для экспорта тестов в виде кода. Такие клиенты, как Microsoft, NetApp, Wix и JFrog, ежемесячно проводят миллионы тестов на Testim.
Это инструмент тестирования программного обеспечения, используемый для регрессионного тестирования. Это инструмент тестирования с открытым исходным кодом, который предоставляет возможность воспроизведения и записи для регрессионного тестирования. Селен IDE поддерживает только Mozilla Firefox веб – браузер.
Silk Test предназначен для выполнения функционального и регрессионного тестирования. Для приложений электронного бизнеса шелковый тест является ведущим продуктом для функционального тестирования. Это продукт поглощения Segue Software компанией Borland в 2006 году. Это объектно-ориентированный язык, как и C ++. Он использует концепцию объекта, классов и наследования. Его основная особенность включает
Правильный выбор инструмента автоматизации, процесса тестирования и команда – основные составляющие успеха автоматизации. Для успешного тестирования ручные методы и автоматизация идут рука об руку.