Автоматизация тестирования: минусы

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

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


Отбор тестов для автоматизации


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

Стоимость


Далеко не всегда оказывается, что разработка и сопровождение автоматизированных тестов будет дешевле ручного тестирования. Необходимо потратиться на среду разработки, системных администраторов, наем программистов, их информационную поддержку (имеется ввиду поддержка при возникновении вопросов относительно тестируемой системы и тест кейсов), обеспечить им рабочие места. Все это выльется в немалую сумму и окупится только при тестировании больших систем, когда есть возможность автоматизировать довольно большое количество тестов. После разработки скриптов их нужно кому-то запускать и анализировать результаты. Не получится проводить тестирование по схеме «запустил – подождал – получил конечный результат». Нужен человек, который сможет анализировать выполнение автотестов: определять, нужно ли отправлять тест на доработку, действительно ли существует ошибка, найденная автотестом, подготавливать данные для тестирования. На подготовку среды для разработки, саму разработку уйдет масса времени.

Отдельная статья расходов на автоматизацию – это поддержка автотестов.

Поддержка


Автотесты всегда требуют поддержки. Так как написание автотестов – это программирование, то чтобы изменить\исправить логику автотеста нужно лезть в исходный код. Для этого нужно нанимать дополнительных специалистов, которые будут сопровождать написанные скрипты. Это новые расходы, без которых не обойтись и которые значительно повышают стоимость автотестов. Есть 2 основных случая, при которых может понадобиться вмешательство в исходный код:

1. Изменение входных данных к тесту

Хорошо, если при выполнении нескольких итераций тестирования приложения можно всегда подавать автотестам на вход одни и те же данные. Например, проверка занесения записи в базу данных, или проверка открытия какого-либо меню, где входные данные вообще не требуются.
Но бывает и так, что перед каждым запуском автотестов данные нужно готовить заново. При большом количестве тестов подготовка входных данных может занять много времени. Например, при тестировании банковской системы могут потребоваться счета в рублях, долларах, евро; счета с разными суммами, принадлежащими как физическим лицам, так и организациям. После прогона серии автотестов на всех счетах может остаться нулевой баланс, некоторые из них будут закрыты, некоторые заблокированы. При последующем тестировании необходимо будет использовать другие счета. В некоторых случаях данные могут быть хардкодом прописаны в скриптах автотестов, и происходить это может не из-за того что разработчику было лень сделать свой скрипт более гибким, а просто потому что такого хардкода требовал тест кейс. Через некоторое время тест кейс изменится (например название банка изменится с «хабрабанк» на «хабракредитбанк»), и потребуется изменение скрипта.

2. Изменение функционала

Особенно актуально для регрессионного тестирования – тестирования новых версий. При каждом обновлении интерфейса или функционала тестируемого ПО потребуется доработка автотестов. Автотесты не могут сами адаптироваться под новый интерфейс, и для продолжения их корректной работы приходится все изменять вручную. Чем больше количество тестов, и чем больше произошло нововведений в ПО, тем больше времени понадобится на актуализацию.
Пример: в старой версии программы было меню «Файл -> Опции», в новой версии этот пункт разделили на два: «Файл -> Настройки» и «Файл — > Параметры». Автотест по прежнему будет искать пункт «Опции», и хоть ты тресни, не найдет «Настройки».
Либо может измениться например время загрузки тестируемой страницы. Если раньше она загружалась моментально, то теперь на это уходит минута. Допустим, теперь скорость соединения слабая, или база тормозит. Автотест же этого не знает, ждет загрузки страницы 10-15 секунд и выдает сообщение «Ошибка: страница не загрузилась». Опять же понадобится доработка исходного кода скрипта.

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

И всё-таки


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

image

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


Комментарии 13

    0
    Ни какие автоматизированные тесты не смогут полностью повторить людей. Для меня тест — это когда человек, который незнакомый с твоей программой, получает полную свободу действий и начинает тыкать все подряд в той последовательности какой захочет он (а никак задумывалось, мы все мыслим об одном, но по-разному). Тесты всегда следуют алгоритму, который заведомо правильный, а бывает шаг влево и всё… поведение программы рушится, ломается или программа и совсем падает.
    Не спорю, что без автоматизации тестов не обойтись, но как подмечено в статье, что надо разграничивать. Например, я с удовольствием автоматизирую нажатие пальцем на кнопку 1000 раз, но последовательное нажатие пунктов в меню доверю человеку.
      +6
      > Ни какие автоматизированные тесты не смогут полностью повторить людей.
      ни один человек не способен выполнить такое количество тестов, которео может выполнить машина
        0
        человек сможет, он же это написал, вопрос времени :)
        и как следствие денег.
          0
          Ага. Особенно в контексте continuous integration =)

          А человек тоже всегда нужен — проходить тесты «от дурака» =)
          +1
          это просто РАЗНЫЕ виды тестирования
          автотесты — автотестами
          Exploratory testing — то о чем вы пишите
          они прекрасно живут паралельно в реальной жизни…

          en.wikipedia.org/wiki/Exploratory_testing
          0
          Еще несколько плюсов автоматизации:

          Забыт один из самых важных — регулярное отслеживание работоспособности ночных билдов.
            0
            Автотесты могут выполняться ночью

            Но ведь и человека можно в любое время посадить тестировать.
              0
              Можно, но их же не посадишь на 24 часа в сутки.
              0
              Автотесты могут определить достаточно грубые ошибки. Аля вылезло окошко с ошибкой после некоего действия.
              Или наоборот, не вылезло ожидаемое окошко…
              Собственное мнение: толку от них не то что бы много… но немного есть.
                0
                >>>Например, невозможно (читай: очень сложно) автоматизировать тестирование таких вещи как:
                >>>установка операционной системы

                Не правда, у нам на работе постоянно приходится пераставлять OCи (все виды.) и этот процесс полностью автоматизирован.

                >>>проверка содержимого картинки, видео
                Опять таки очень часто приходится распознавать текст со скриншотов.
                Да это не полная проверка картинки/видео, но всё равно распознавание работает.

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

                    Просто у нас основной инструмент perl. По-этому мы не сильно скованы в средствах. :)
                    То что нельзя сделать примощи perl, можно сдeлать чем-нибудь ещё и обернуть в perl.
                  +3
                  OMFG, ну почему каждый пост на хабре о тестировании — непроходимая чушь?!
                  Ну кто вам сказал, что «Автотест — это обязательно скрипт, имитирующий взаимодействия пользователя с приложением»?
                  А юнит-тесты не могут быть авто-? А нагрузочные? А UI-тестирование?

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

                  Самое читаемое