Автоматизированное тестирование: как не выстрелить себе в ногу. Объясняет Software Engineer in Test Иван Катунов

Иван Катунов, Software Engineer in Test в компании Flo Health, организатор Minsk Test Automation Meetup, рассказывает про положение дел в автоматизированном тестировании.

Для каких целей компании применяют автоматизированное тестирование?

Основные цели — это:

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

Почему это направление востребовано сегодня?

Для бизнеса важно как можно скорее доставлять изменения пользователям, опережать конкурентов. Это возможно благодаря гибким методологиям разработки, а также таким практикам, как continuous integration и continuous delivery. Последние подразумевают использование автоматизированного тестирования.

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

Так ли всё хорошо на практике, как в теории?

На практике есть огромное количество способов «выстрелить себе в ногу» и получить негативный опыт, чем многие и пользуются.

Владельцы бизнеса порой готовы вкладывать серьёзные средства в неэффективные процессы, узнав о том, что сегодня востребовано какое-либо новое направление. То же самое происходит и с автоматизацией. То, что они получают в виде плохо продуманных решений, разработанных низкоквалифицированными специалистами, часто их разочаровывает. Они думают: лучше было бы набрать большую команду ручных тестировщиков, либо организовать новый бенефит для сотрудников вместо автоматизации.

Что именно может быть организовано неэффективно?

1. Нередко приложение проектируют без учёта необходимости его тестировать. В таком случае сложно (либо невозможно) выделить отдельные компоненты на разных уровнях и проверить корректность их работы.

2. Могут отсутствовать модульные и интеграционные тесты — то, за что, как правило, отвечают разработчики. Причины могут быть самыми разными. Это может быть связано и с первой проблемой (нетестируемое приложение).

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

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

3. Тестирование бизнес-логики зачастую проводится через пользовательский интерфейс. На первый взгляд, это логично, ведь пользователи именно так и взаимодействуют с приложением. Вот только бизнес-логика, как правило, реализуется на уровнях ниже. И если есть возможность обращаться к ней напрямую, можно получить на порядки более быстрые тесты, при этом более надёжные. Пользовательский интерфейс можно проверить небольшим количеством отдельных тестов.

pic.twitter.com/WOqu77NO0A

— Erik Johansson (@Empirical) 22 ноября 2017 г.

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

Сегодня в описании подобных продуктов либо сервисов часто можно встретить Machine Learning, AI, Big Data. Как тут устоять?

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

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

Зайти можно далеко, вплоть до того, что только для отчётов по автотестам понадобятся отдельные сервера.

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

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

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

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

Как понять, когда стоит переходить от ручного тестирования к автоматизированному?

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

Чем более долгосрочный проект, чем более частые предполагаются релизы — тем более выгодным становится применение автоматизированного тестирования.

Существуют так называемые калькуляторы ROI (Return on Investment). На основе ряда параметров они помогают определить, в какой момент автоматизированное тестирование становится более выгодным по сравнению с ручным.

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

Обучают ли где-либо на автоматизаторов? Легко ли из ручного тестирования перейти в автоматизацию?

Курсы по автоматизированному тестированию проводятся при ИT-компаниях и частных образовательных центрах. Очень многое на курсах зависит от опыта и ответственности преподавателя, от качества материалов.

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

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

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

В вашей ежедневной работе может присутствовать множество рутинных задач, которые можно упростить, написав простой shell или Python скрипт, а зачастую и вовсе избегая написания кода. Установка билдов, копирование либо удаление файлов, подготовка тестовых данных — отличные кандидаты для того, чтобы упростить свою работу и начать разбираться в разработке. Причём результат будет ощутим сразу же.

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

Что необходимо знать и какой опыт иметь, чтобы быть востребованным специалистом? Какие есть карьерные перспективы?

Если просмотреть большинство вакансий, самыми частыми требованиями окажутся знание основ тестирования, знание основ одного из языков программирования — чаще всего Java/C#/Python/Javascript, понимание принципов объектно-ориентированного программирования, знание основ SQL, Selenium, английский уровня A2 и выше.

Это минимум, которого может быть достаточно, чтобы добавлять автотесты в готовом решении для тестирования веб-приложений.

Кроме веб-приложений, есть десктоп и мобильные приложения, веб-сервисы и так далее. Есть общие подходы и практики, применимые ко всем типам приложений, есть и множество особенностей. Можно проработать много лет в разных командах, над разными проектами, стать экспертом в нескольких направлениях, при этом в какой-то момент впервые столкнуться с необходимостью тестировать веб-сервисы, например.

Поэтому универсальный автоматизатор это как универсальный программист: объять всё сложно. Да и нужно ли?

Если есть желание расти дальше, то рекомендации во многом будут совпадать с рекомендациями для разработчиков. Знание лучших практик программирования, того, как писать хороший код, как и когда имеет смысл применять паттерны проектирования, рефакторинг. Для решения определённых задач могут понадобиться знания о многопоточности, работе с памятью, сериализации, тестовых двойниках, сетевых протоколах, виртуализации, практиках CI/CD и многом другом. Понимание процессов и методологий разработки, хорошее владение английским также важны, если есть желание расти. Поэтому быстрая обучаемость становится важнейшим качеством.

Некоторые специалисты переходят в разработку.

Ещё один вариант — расти в менеджмент: team lead, software testing manager. Путь сложный, так как может потребовать совмещения технических задач и управленческих, нести ещё большую ответственность. 

Если говорить о том, какие специалисты сегодня востребованы, то ответом может быть: практически все. Есть явная нехватка специалистов и большой спрос.

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

Проводятся ли специализированные мероприятия, посвящённые автоматизированному тестированию?

В Минске периодически проводятся конференции по тестированию. Часть докладов, как правило, посвящена автоматизации.

Из зарекомендовавших себя профильных конференций на просторах СНГ можно выделить SeleniumCamp, которая проводится ежегодно в Киеве, и Heisenbug, которая проводится два раза в год — в Москве и Санкт-Петербурге. Записи докладов с этих конференций выкладываются на YouTube.

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

Есть ли различия в этой специализации у нас и в Западной Европе, США?

Наверное, многие слышали про то, что ручное тестирование становится всё менее востребованным. В Западной Европе, США в последние годы такая же тенденция наблюдается и относительно автоматизаторов, таких, какими их часто представляют у нас, — разрабатывающих автотесты для веб- и мобильных приложений с использованием Selenium, Appium и подобных инструментов.

Во многих ИТ-компаниях в США, Западной Европе сейчас есть должности (Software Development Engineer in Test, Software Engineer in Test), главная особенность которых в том, что это разработчики, выбравшие тестирование в качестве основной доменной области. Они могут быть ответственными за создание всей инфраструктуры тестирования, за написание автотестов, за обучение программистов лучшим практикам тестирования, за разработку дополнительных сервисов, необходимых для тестирования.

Постепенно эти тенденции добираются до нас.

Место солидарности беларусского ИТ-комьюнити

Далучайся!