Распространенные заблуждения об автоматизации тестирования

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

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

Заблуждения об автоматизации тестирования

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

Автоматическое тестирование лучше ручного

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

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

Достижение 100% автоматизированного тестирования

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

Быстрая окупаемость

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

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

Более высокая скорость обнаружения дефектов за счет автоматизированных проверок

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

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

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

Нам нужна только автоматизация модульного тестирования

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

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

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

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

Нам нужна только автоматизация пользовательского интерфейса системы

Есть значения в запуске автоматических проверок на уровне пользовательского интерфейса и системы. Мы видим, что испытывает пользователь при взаимодействии с приложением; мы можем протестировать сквозные потоки и 3^rdпартийная интеграция, когда мы не могли проверить иначе; мы также можем продемонстрировать тесты клиентам и конечным пользователям, чтобы они могли почувствовать покрытие тестами. Однако использование только автоматизированных проверок на уровне пользовательского интерфейса имеет свои проблемы.

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

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

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

Утрата веры и доверия к автоматизации тестирования

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

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

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

Заключение

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

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

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