Как стать автором
Обновить
1056.27
OTUS
Цифровые навыки от ведущих экспертов

Процесс автоматизированного тестирования за 10 шагов

Время на прочтение9 мин
Количество просмотров9.8K
Автор оригинала: www.softwaretestinghelp.com

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

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

В третьей части «Руководства по автоматизации тестирования», я расскажу вам о том, что такое процесс автоматизации тестирования и как начать автоматизацию тестирования в вашей организации. Важно понимать, какой шаг нужно сделать первым и почему.

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

10 шагов на пути к внедрению автоматизации тестирования

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

Итак, начнем.

Шаг 1. Убедите руководителей

Независимо от того, насколько вам хочется внедрить автоматизацию тестирования в вашей организации, вы ничего сможете сделать, если руководство не видит в нем преимуществ. Все знают, что автоматизация тестирования – это дорого. Инструменты – это дорого (лицензия HP QTP/UFT стоит около 8 тысяч долларов на машину). Есть и стоимость работы архитектора или инженера по автоматизации (которая, кстати, тоже немалая). После всего этого преимущества автоматизации тестирования уже не кажутся такими очевидными. Должно пройти 2-3 месяца, прежде чем скрипты будут готовы, проверены и будут хорошо работать, а только после этого вы сможете начать тестирование вашего приложения.

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

Так как же их убедить? Вам нужно показать им анализ рентабельности. Например, вы можете задаться вопросом, сколько вы тратите на тестирование BAT (Build Acceptance Testing) вашего приложения? Если оно занимает день, то вы сможете сказать, что с автоматизацией тестирования сможете протестировать его за 2 часа. Стоимость будет состоять из приобретения инструментов, обучения персонала и ожидания результатов в течение двух месяцев. Через два месяца мы сможем проводить BAT за два часа. Каждый раз при выпуске нового билда вы будете экономить 6 часов. Если билд выпускается 4 раза в месяц, то вы сэкономите 24 часа или 3 рабочих дня ручного тестирования!

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

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

Итак, пять пунктов, которые нужно запомнить, чтобы убедить свое руководство: 

  1. Подробно расскажите им о преимуществах автоматизации тестирования.

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

  3. Скажите им, что нужно будет подождать около трех месяцев, прежде чем появится какой-то результат от автоматизации тестирования. 

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

  5. Автоматизация тестирования — не значит увеличение объемов тестирования и уменьшение количества времени, затраченного на него, она значит, что вы сможете делать больше задач одновременно. (Если ручные тестировщики проводили BAT за 8 часов, теперь они смогут протестировать BAT и другой функционал за те же 8 часов при наличии автоматизации.)

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

Шаг 2: Поиск экспертов по работе с инструментами автоматизации

Есть два вида экспертов по автоматизации:

  1. Архитекторы по автоматизации

  2. Инженеры по автоматизации

Архитектор по автоматизации – редкий зверь. Их непросто найти, они дорого стоят, но при этом они крайне необходимы для успеха проекта автоматизации. Эти специалисты обычно отвечают за создание систем автоматизации. (Фреймворки автоматизации мы подробно обсудим в отдельной статье).

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

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

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

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

Шаг 3: Использование правильного инструмента для автоматизации

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

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

Наиболее важные аспектами, которые следует учитывать при выборе правильных инструментов:

  1. Инструмент должен отвечать вашему бюджету. Средства автоматизации – это дорого. Поэтому у компании под них должен быть заложен бюджет.

  2. Инструмент должен поддерживать технологии, используемые в вашем приложении. Если в нем используется Flash или Silverlight, инструмент должен их поддерживать. Если ваше приложение работает на мобильном устройстве, инструмент должен уметь выполнять скрипты на нем. Вы можете приобрести один инструмент, поддерживающий все технологии, используемые в вашем приложении, или приобрести отдельные инструменты под каждую технологию. Например, для веб-приложений вы можете использовать Selenium, для приложений на Android взять Robotium, а MS Coded UI для десктопных приложений. Каким бы ни было решение, оно должно вписываться в ваш бюджет.

  3. У вас должны быть все необходимые квалифицированные специалисты, которые умеют пользоваться этим инструментом или могут изучить его в кратчайшие сроки. Например, если вы наняли архитектора по автоматизации, у которого есть только опыт работы с QTP, и покупаете лицензию MS Coded UI, то специалист может работать неэффективно. Инструменты – это как хорошие автомобили, но у вас должны быть хорошие водители, чтобы водить их.

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

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

Шаг 4: Анализ различных приложений и определение тех, которые лучше подходят для автоматизации

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

Приложение, которое нужно автоматизировать, должно обладать следующими факторами:

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

  2. Пользовательский интерфейс приложения должен быть неизменным. (Он не должен часто меняться.)

  3. Ручные тесты для этого приложения должны быть задокументированы.

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

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

Шаг 5: Обучение команды

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

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

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

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

Шаг 6: Создание фреймворка автоматизации тестирования

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

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

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

Вы можете узнать больше о фреймворках автоматизации из следующих источников:

Шаг 7: Разработка плана выполнения

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

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

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

Шаг 8: Написание скриптов

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

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

Шаг 9: Отчеты

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

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

Шаг 10: Обслуживание скриптов

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

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

Например, если раньше вы с помощью скрипта вводили текст в текстовое поле, а в новой версии приложения это текстовое поле стало выпадающим списком, то скрипт необходимо немедленно обновить.

Другие изменения могут возникнуть, если раньше ваши скрипты работали на английской версии приложения, а теперь их нужно менять, поскольку приложение будет поддерживать и китайский. Ваш фреймворк должен позволять вам обновлять скрипты без особых усилий, чтобы ваше приложение хорошо работало и на китайском! Именно поэтому архитекторы по автоматизации стоят дорого. :)

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

Заключение

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

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

Я постарался охватить все аспекты и использовал свой собственный опыт для написания этой статьи.

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


Перевод статьи подготовлен в преддверии старта курса Python QA Engineer.

- Узнать о карьерных перспективах профессии.

- Записаться на бесплатный демо-урок.

Читать ещё:

Теги:
Хабы:
Всего голосов 14: ↑12 и ↓2+10
Комментарии1

Публикации

Информация

Сайт
otus.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия
Представитель
OTUS