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

Что такое автоматизированное тестирование?

Автоматизированное тестирование (Automation Testing, Test Automation) — техника тестирования, в которой для выполнения тест кейсов используются специальные программы. Это отличает ее от ручного тестирования, в котором тест кейсы выполняются вручную тестировщиком.

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

Разработка продукта циклична и итерационна — и на каждой итерации, как правило, требуется выполнение одного и того же набора тестов. С помощью инструментов автоматизированного тестирования можно записывать наборы тестов (test suites) и выполнять, когда это необходимо. Как только набор тестов автоматизирован, участие человека в выполнении тестов практически не требуется. Это делает автоматизированное тестирование эффективной техникой. Цель автоматизации — уменьшить количество тестов, которые нужно выполнять вручную.

Зачем нужно автоматизированное тестирование?

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

Преимущества автоматизированного тестирования:

• Автоматизированное тестирование увеличивает скорость тестирования
• Автоматизированное тестирование не требует участия человека для выполнения тестов. Отсутсвует влияние человеческого фактора.
• Средства автоматизации способны выполнить тест-кейсы, в принципе непосильные для человека в силу своей сложности, скорости или иных факторов.
• Средства автоматизации способны собирать, сохранять, анализировать, агрегировать и представлять в удобной для восприятия человеком форме колоссальные объёмы данных.
• Ручное тестирование всех возможных сценариев использования требует много времени (и, следовательно, денег)
• Автоматизированные тесты могут быть запущены в любое время (днем, ночью, в выходные и праздники)
• Многократное ручное тестирование одной и той же функциональности скучно

Недостатки автоматизированного тестирования:

• Необходимость наличия высококвалифицированного персонала в силу того факта, что автоматизация — это «проект внутри проекта» (со своими требованиями, планами, ко- дом и т.д.).
• Разработка и сопровождение как самих автоматизированных тест-кейсов, так и всей необ- ходимой инфраструктуры занимает очень много времени.
• Автоматизация требует более тщательного планирования и управления рисками,т.к. в противном случае проекту может быть нанесён серьёзный ущерб&
• Коммерческие средства автоматизации стоят ощутимо дорого, а имеющиеся бесплатные аналоги не всегда позволяют эффективно решать поставленные задачи.
• Средств атоматизации крайне много, что усложняет проблему выбора того или иного средства, затрудняет планирование и определение стратегии тестирования, может повлечь за собой дополнительные временные и финансовые затраты, а также необходимость обучения персонала или найма соответствующих специалистов.

Что автоматизировать в первую очередь?

Для максимальной эффективности, для определения сценариев, подходящих под автоматизацию, пользуйтесь следующими критериями:

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

Следующие критерии не подходят для автоматизации:

• Новые тест кейсы, которые еще не были выполнены вручную
• Тест кейсы для функциональности, требования к которой часто меняются
• Тест кейсы, которые выполняются редко

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

Шаг 1: Выбор инструмента для автоматизации Шаг 2: Определение функциональности, которую нужно автоматизировать Шаг 3: Планирование, тест дизайн и разработка тестов Шаг 4: Выполнение тестов Шаг 5: Поддержка написанных тестов

Определение функциональности, которую нужно автоматизировать

Область для автоматизации может быть определена по следующим критериям:

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

Сценарии, обычно подходящие для автоматизации:

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

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

1. Автоматизируй Smoke-тесты. Такие тесты позволяют удостовериться, что приложение в целом работоспособно, и их желательно делать при каждом изменении функциональности, и после каждого билда. Smoke-тесты должны интегрироваться в CI/CD-процессы — это позволяет выловить критические ошибки. Smoke-тестами проверяют основные части приложения/сайта, они должны оставаться работоспособными в любых условиях; гарантируется, что билд достаточно стабилен, значит можно продвигаться дальше в пайплайне.

Автоматизация Smoke-тестирования помогает:

Оперативно найти критические баги, и сделать это очень рано в пайплайне. Главная страница/экран не открывается; у клиент не получается залогиниться или сделать себе аккаунт; платежные системы не подключаются и т.п. Быстрее идет устранение новых или “регрессионных” дефектов. Smoke-тесты сами по себе “дают широкое покрытие, но малую глубину” этого покрытия. Получается много тестовых кейсов без необходимости “глубокого погружения” тестировщиков в проект. Убедились, что самые важные части работоспособны — и идем дальше, к менее важным компонентам. Автоматизация Smoke-тестов позволяет экономить время за счет уменьшения большого количества ручной работы. Включение автотестов в CI/CD позволяет проводить smoke-тестирование еще на этапе сборки билда. 2. Автоматизируй тесты, которые пишутся всегда, и которые пишутся в начале каждого этапа Тогда получаются стабильные тест-сьюты. К примеру, тестирование создания аккаунта должно делаться до того как юзер может логиниться и видеть свое клиентское окно, проводить платежи и т.п.

Создание автоматического “регрессионного” тестового набора (сьюта) позволяет:

Делать тесты, оперативно находящие баги, возникающие из правок в коде. Правки могут быть новыми функциями, или “фиксами” прошлых багов. Тестовый набор, как уже было сказано, получается с повышенной стабильностью и надежностью. Регрессионное тестирование обычно касается существующей функциональности, то есть функции уже тестированы неоднократно. Это повышает стабильность сьютов, экономится время ручных тестировщиков, когда не знаешь, реально “падают” тесты или они нестабильные. Экономится время: можно сосредоточиться на ручном тестировании (особенно граничных значений). 3. Автоматизируй “большие тесты” — с большим массивом данных “Большие тесты” — это может быть ввод больших массивов данных, тестирование форм, или тесты предполагающие многократный ручной ввод самых разных данных. Их-то и надо автоматизировать. Если речь идет о формах, автоматизация позволяет быстро протестировать комбинации данных в форме, например ситуации когда пропущены поля, данные неполные, и т.п. Тут полезно DDT-тестирование, позволяющее модифицировать только данные, а не весь скрипт. Это то что называется “реюзабельный” и эффективный подход.

4. Автоматизируй тесты с множественными конфигурациями Если в проекте множество ОС и целый “парк браузеров”, будет сложная конфигурация.

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

Желательно также почитать что-то о параллельном тестировании, которое также экономит время. Можно применять специальные “тулзы” типа CircleCI — прописывают ОС/браузер/окружение, в которых будут выполняться параллельные тесты.

5. Автоматизируй тесты производительности Такие тесты проводятся для устранения отказов приложения, улучшения пресловутого User Experience, и, разумеется, контроля производительности приложения. Проверяется, как приложение ведет себя под серьезной нагрузкой; находят ее проблемные точки; контролируют то что называется “плавность” приложения, время реакции на действия, стабильность, степень задействования аппаратных ресурсов девайса, и способность безболезненно реагировать на резкий рост нагрузки.

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

Как часто будут выполняться написанные тесты? Самый важный вопрос. Автоматизировать тест-кейс имеет смысл в том случае, если он будет выполняться постоянно. Обязательно учитывайте частоту использования при составлении плана по автоматизации.

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

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

Тест будет выполняться в регрессионном или smoke-тестировании? Регрессионное и smoke-тестирование выполняются очень часто. Это тест-сьюты, которые тестируют приложение “вширь” — т.е. тестируют корректность работы всего базового функционала. Регрессионные тесты интегрируются в процесс сборки приложения и выполняются во время каждого билда. Их автоматизация поможет улучшить качество продукта.

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

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

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

Это негативный тест? Писать негативные автотесты — не лучшее решение.

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

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

На этом этапе создается тест стратегия и тест-план, которые содержат следующие детали:

• Выбранный инструмент автоматизации
• Фреймворк с описанием его особенностей
• Описание функциональности, тестирование которой будет автоматизировано
• Подготовка стендов для выполнения тестов
• Расписание выполнения автотестов
• Результаты автоматизированного тестирования

Выполнение тестов

Во время этой стадии происходит выполнение автотестов. После выполнения генерируется подробный тест репорт.

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

Поддержка написанных тестов

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

Советы по использованию инструментов автоматизации

• Функциональность, подходящая для автоматизации, должна быть определена до начала разработки проекта.
• Инструмент для автоматизации должен быть выбран исходя из требований конкретного продукта, а не из популярности.
• Придерживайтесь стандартов написания кода, когда разрабатываете автотесты. Вот некоторые из них:
  • Придерживайтесь гайдлайнов при написании кода
  • Оставлйте комментарии
  • Обрабатывайте ошибки — при разработке думайте о том, как отработает ваша система в случае некорректного поведения приложения.
• Собирайте метрики, чтобы определить эффективность автоматизированного тестирования. Вот некоторые из них:
  • Процент найденных багов
  • Время, затраченное на выполнение автотестов для каждого релиза

Типы автоматизированного тестирования