Какие виды тестирования лучше автоматизировать?
Иногда ручного тестирования недостаточно, чтобы обеспечить качество, особенно когда речь идет о сложных программных продуктах и многокомпонентном ПО. К тому же, современные IT-компании, адаптируясь к динамичным потребностям рынка, ускоряют разработку, поэтому и на тестирование отводится все меньше и меньше времени. В результате автоматизация играет все большую роль, ведь она позволяет ускорить QA-процессы. Давайте посмотрим, какие виды тестирования следует автоматизировать в первую очередь.
Регрессионное тестирование
Этот вид тестирования автоматизируют чаще всего, что неудивительно, ведь автоматизация в данном случае избавляет тестировщика от многократного выполнения одинаковых тест-кейсов перед каждым релизом. Как правило, сценарии автоматизированных регрессионных тестов разрабатываются на основании ручных тестов, которые уже показали свою эффективность путем выявления дефектов. Наибольшей эффективности при автоматизации регрессионного тестирования удается достичь, если речь идет о сервисах, требующих регулярного внесения изменений.
Автоматизация хорошо себя зарекомендовала и в том случае, когда тестировщику надо выполнять одинаковые действия, но каждый раз с разными данными. Все данные можно собрать в одной базе, а скрипты станут автоматически использовать эту информацию при проведении тестов. Кстати, это уже не что иное, как DDT-подход к тестированию (data-driven testing).
Кроссбраузерное и кроссплатформенное тестирование
Автоматизация способна повысить эффективность и таких видов тестирования, как кроссплатформенное и кроссбраузерное. Тут все просто: одинаковые сценарии автоматизированных тестов используют на разных платформах.
Тестирование локализации
Такое тестирование бывает весьма трудоемким для ручного исследования. К примеру, если мы тестируем сайт с десятками версий на различных языках, мы проверяем адаптацию элементов интерфейса, перевод текста и т. д. Наша задача — получить информацию о том, не привела ли локализация к появлению дефектов. В данном случае автоматизация позволит протестировать нужные аспекты с меньшей затратой времени.
Исследование производительности, нагрузочное и стресс-тестирование
В наше время performance testing (исследование производительности), а также нагрузочное тестирование и стресс-тестирование почти всегда автоматизируются. Существует ряд инструментов для автоматизации (JMeter, Gatling, Tsung), позволяющих воспроизводить разные условия, в том числе и «на грани фола», то есть условия, которые могут вызвать проблемы с производительностью программного приложения. Используя автоматизированные тесты, вы смоделируете нехватку оперативной памяти и другие ситуации, ну и, что немаловажно, сможете зафиксировать реакцию программного обеспечения на эти ситуации.
От пирамиды тестов – к колесу автоматизации: какие проверки нужны на проекте
О задачах автоматизации тестирования и случаях, когда она необходима, мы уже писали на Хабре. А для выбора необходимых проверок удобно иметь под рукой наглядное пособие, не ограничиваясь знаменитой пирамидой автотестов. Предлагаем перевод статьи Кристин Джеквони (Kristin Jackvony), где графически показан еще один метод – колесо автоматизации.
Автоматизация тестирования, как правило, наиболее необходима в масштабных приложениях с большим количеством бизнес-функций, при внедрении CI/CD и регулярных релизов. Подробнее об этом мы рассказывали в статье «Что даёт автоматизация тестирования».
С разрешения Кристин Джеквони – автора блога Think Like a Tester и ряда популярных материалов о тестировании – мы перевели статью «Переосмысление пирамиды автотестов: колесо автоматизации» (Rethinking the Pyramid: The Automation Test Wheel). В конце статьи рассмотрим пример проверок из практики наших специалистов по автоматизации тестирования (SDET).
Каждый, кто занимался автотестами, слышал о Пирамиде автотестов. Обычно она имеет три слоя: тесты UI, API и Unit. Нижний слой, самый широкий, занимают Unit-тесты – это означает, что таких тестов должно быть больше, чем прочих. Средний слой – это API-тесты; идея в том, что их нужно запускать меньше, чем Unit-тестов. Наконец, верхний слой – это UI-тесты. Их должно быть меньше, чем остальных, т.к. они требуют больше времени на прохождение. Кроме того, UI-тесты наиболее нестабильные.
Пример пирамиды автотестов на Хабре. Метод описан в книге Майка Кона «Scrum: гибкая разработка ПО» (Succeeding With Agile. Software Development Using Scrum).
С моей точки зрения, в этой пирамиде две проблемы:
- описывает далеко не все типы автотестов;
- говорит о том, что именно количество тестов – лучший индикатор качества тестового покрытия.
Я предлагаю другой подход к автоматизированному тестированию – Колесо автоматизации.
Каждый из типов тестов можно рассматривать как спицу в колесе. Нет спицы, которая была бы важнее других – они все необходимы. Размер сектора колеса не означает число тестов, которые должны быть автоматизированы. При этом нужно предусмотреть проверки по каждому указанному направлению, если в вашем проекте требуется обеспечивать качество в соответствующей области.
Unit-тесты (Unit Tests)
Unit-тесты – это самые маленькие автотесты, какие только возможны. Они проверяют поведение только одной функции или одного метода. Например, есть метод, который проверяет, равно ли число 0, тогда можно написать такие Unit-тесты:
- с аргументом 0 метод возвращает True;
- с аргументом 1 метод возвращает False;
- со строковым аргументом метод возвращает ожидаемую ошибку.
Компонентные тесты (Component Tests)
Эти тесты проверяют разные сервисы, от которых зависит код. Например, если мы используем API GitHub, то можно написать компонентный тест для проверки того, что запрос на данный API получает ожидаемый ответ. Или это может быть просто пинг до сервера, проверка доступности базы данных. Должен быть хотя бы один компонентный тест на каждую используемую в коде службу.
Примечание: например, у нас в SimbirSoft к компонентным тестам, помимо проверки ответов сторонних сервисов, относятся проверки модулей одной системы, если её архитектура представляет собой набор таковых.
Сервисные тесты (Services Tests)
Такие тесты проверяют доступность веб-сервисов, к которым обращается приложение. Чаще всего работа с ними организована через использование API запросов.
Например, для API с типами запросов POST, GET, PUT и DELETE мы можем написать автотесты на проверку каждого типа запросов. Причем наши тесты будут проверять как позитивные, так и негативные типы сценариев, при которых некорректный запрос возвращает соответствующий код ошибки.
Тесты пользовательского интерфейса (User Interface Tests, UI Tests)
UI-тесты проверяют правильность реакции системы на действия конечного пользователя. К таким проверкам относятся, например, тесты, проверяющие ответ системы на заполнение текстовых полей или на нажатие кнопок.
Как правило, любая функциональность системы, которая может быть протестирована с помощью Unit, компонентного или сервисного теста, должна быть проверена с использованием упомянутого типа теста. Тесты же пользовательского интерфейса должны быть сосредоточены исключительно на выявлении ошибок во взаимодействии пользователя с графическим интерфейсом.
Визуальные тесты (Visual Tests)
Визуальные тесты проверяют отображение элементов интерфейса на экране. Они схожи с UI-тестами, но фокусируются на проверке внешнего вида интерфейса, а не на функциональности. Примерами таких проверок могут быть проверка правильности отображения изображения кнопки или проверка отображения логотипа продукта на экране.
Тесты безопасности (Security Tests)
Это тесты, проверяющие соблюдение мер безопасности и защиты данных. Они по механике похожи на сервисные тесты, но тем не менее рассматривать их следует отдельно. Например, тест безопасности может проверить, что токен авторизации не будет создан при недопустимой комбинации логина и пароля. Другой пример – создание GET-запроса с токеном авторизации для пользователя, не имеющего доступа к этому ресурсу, и проверка того, что будет возвращен ответ с 403 кодом.
Примечание: с сервисными тестами эти проверки роднит только способ вызова служб – через http-запросы. Цель таких тестов – исключительно в проверке защищенности системы и пользовательских данных от действий злоумышленника.
Тесты производительности (Performance Tests)
Автотесты производительности проверяют, что ответ на запрос приходит в рамках соответствующего периода времени. Например, если есть требование к системе, что GET-запрос никогда не должен занимать дольше двух секунд, то при превышении этого ограничения автотест вернет ошибку. Время загрузки web-интерфейса также можно измерять с помощью тестов производительности.
Тесты доступности (Accessibility Tests)
Автотесты проверки доступности служат для проверки самых разных вещей. В сочетании с тестами пользовательского интерфейса они, например, могут проверять наличие текстового описания изображения для слабовидящих. В рамках проверки доступности визуальные тесты могут быть использованы для проверки размера текста на экране.
Как выбрать методы проверки
Возможно, вы заметили, что приведенные выше описания тестов часто пересекаются друг с другом. Например, тесты безопасности могут выполняться в процессе тестирования API (сервисные тесты), а визуальные тесты – в процессе тестирования пользовательского интерфейса. Здесь важно, чтобы каждая область была проверена тщательно, эффективно и точно.
После выхода статьи «Переосмысление пирамиды автотестов: колесо автоматизации» (Rethinking the Pyramid: The Automation Test Wheel) вышел список факторов, помогающих определить необходимую долю тестов каждого типа в колесе автоматизации:
- От какого количества сторонних сервисов зависит ваше приложение? Если таких сервисов много, нужно больше компонентных тестов.
- Насколько сложен ваш пользовательский интерфейс? Если он содержит всего одну или две страницы, вам потребуется меньше тестов пользовательского интерфейса и визуальных тестов.
- Насколько сложна ваша структура данных? Если вы имеете дело с большими объектами данных, вам потребуется больше API-тестов для проверки правильности обработки операций CRUD (Create, Read, Update, Delete).
- Насколько безопасным должно быть ваше приложение? Приложение, которое обрабатывает банкинг, будет нуждаться в гораздо большем количестве тестов безопасности, чем приложение, которое сохраняет фотографии котят.
- Какой должна быть производительность вашего приложения? Игра в пасьянс не обязательно должна быть такой же надежной, как кардиомонитор. Соответственно, от этого критерия зависит процент тестов производительности.
Из практики SimbirSoft
Мы считаем, что колесо автоматизации – полезный способ визуализации типов тестирования. Безусловно, мы давно используем описанные тесты, но картинка помогает проанализировать покрытие системы и держать всё перед глазами.
Если у вас отлажен процесс тестирования и вы регулярно прогоняете автотесты, это минимизирует риск попадания дефектов в продакшен. К тому же, автотесты помогают оперативно выявлять проблемы, которые могут возникнуть в процессе работы системы. Например, с помощью планового ежедневного прогона автотестов можно контролировать свой сайт, чтобы защитить себя от взломов.
Какие использовать проверки и в каком количестве – зависит и от требований, и от самой проверяемой системы. Так, в одном из наших продуктов – банковском мобильном приложении – по требованию клиента были подготовлены автотесты всех перечисленных ранее видов. Рассмотрим их примеры далее.
Автоматизация тестирования: что можно, а что не нужно
Непрерывное тестирование ускоряет поставку программного обеспечения, делая весь процесс тестирования более быстрым. А благодаря незамедлительной обратной связи, которая помогает уже на самых ранних этапах выявлять ошибки и другие проблемы в приложении, гарантирует, что команды разработки будут создавать высококачественные и надежные приложения. Кроме того, сама способность организовать и проводить эффективное тестирование может значительно снизить затраты в компании, как за счёт экономии времени разработчиков, так и вследствие создания добротного конвейера поставки, в котором они могут быстро вносить изменения в код с минимальными рисками нарушения работоспособности приложения в продуктивной среде.
Главным элементом непрерывного тестирования является его автоматизация, что даёт множество преимуществ:
- Быстрое получение обратной связи
- Аккуратное и тщательное тестирование
- Высокое покрытие тестами
- Быстрое обнаружение ошибок
- Повторное использование тестов
- Более короткие сроки поставки
- Адаптация для DevOps
- Экономия времени и денег
Несмотря на перечисленные выше преимущества, начальные вложения в автоматизацию тестирования могут быть очень высоки. Приобретение ПО, затраты на обучение работе с ним, проектирование и создание автоматизированных тестов — всё это требует немалых времени и денег. Однако, как только вы начинаете всё активнее разрабатывать новые функции в своём продукте, ручное тестирование в конечном итоге выходит дороже, а автоматическое — дешевле.
Кроме того, следует понимать — не всё нужно автоматизировать и не всё можно автоматизировать. Поэтому важно тщательно оценить, изучить и проанализировать свои требования, прежде чем решить, как лучше всего организовать автоматизацию тестирования. Когда следует автоматизировать тесты, а когда — нет?
Какие тесты можно автоматизировать
Практически каждая команда разработчиков работает над проектом, который критически зависит от сроков, а значит, что времени на применение всех передовых практик всегда не хватает. То же самое относится к стратегии тестирования, поскольку тестирование как вид деятельности не всегда является приоритетом для команд разработки. Нужно попытаться найти баланс и сделать правильный выбор в зависимости от типа разрабатываемого приложения, временных рамок, используемого ПО для тестирования и имеющихся ресурсов. Вот важные типы тестов, которые можно автоматизировать.
Модульное тестирование
Это отличный способ приступить к автоматизации тестирования, поскольку модульные тесты направлены лишь на часть кода, в ходе которых он проверяется на работоспособность, и не зависят от других частей приложения. Таким образом, разработчики получают больше информации о работе созданной функциональности. Благодаря современной культуре тестирования многие команды используют методологию разработки через тестирование (test-driven development, TDD), при которой они начинают составлять тесты до написания кода. Таким образом гарантируется качество и кода, и тестов.
Приоритетные функции
Если у вас в плане десятки функций и сжатые сроки на их разработку, вы можете выделить среди них те, что имеют высокую вероятность сбоев. Тестирование подобных функций нужно начинать как можно раньше.
Регрессионные и интеграционные тесты
Интеграционные тесты используются для определения того, работают ли отдельные модули в приложении как группа, а регрессионные тесты проверяют, что функции приложения работают должным образом. Эти два теста обычно выполняются после изменений / улучшений приложения, поэтому тестировщики постоянно проводят эти тесты. Автоматизация таких тестов экономит огромное количество времени, высвобождая его для выполнения других типов тестов.
Нагрузочные тесты и тесты производительности
Для тестов производительности и нагрузочных тестов нет альтернативы в виде ручного тестирования, поскольку необходимо моделировать сотни или тысячи пользователей, работающих в разных условиях: из-под разных браузеров, в разных часовых поясах, использующих разные операционные системы и т.п.
Повторяющиеся тестовые сценарии
Это очень важные тесты, которые команды разработки вынуждены запускать чуть ли не постоянно. Например, работоспособность функции входа в систему — она обеспечивает возможность пользоваться приложением, влияя на его доступность. Поэтому лучше автоматизировать тестирование и сэкономить прорву времени тестировщиков и разработчиков.
Базовая функциональность (дымовые тесты)
В отличие от других тестов, дымовые тесты не такие сложные и относительно легко реализуемые. При этом прохождение этих тестов имеет решающее значение. Они информируют команды разработки о том, правильно ли работают базовые функции приложения, например: открывается ли окно входа в приложение, могут ли пользователи войти в систему, доступен ли API, доступно ли приложение из разных мест и т.п.
Какие тесты не нужно автоматизировать
Всё больше и больше узнавая о преимуществах автоматизации тестирования и глубоко проникаясь ими, можно задаться закономерным вопросом — а почему бы не автоматизировать вообще все тесты? Ответ в виде “не нужно пытаться автоматизировать всё” идёт вразрез с DevOps-мышлением, в котором явная установка на автоматизацию всего и вся. Перед планированием автоматизации тестирования нужно учесть несколько факторов. Вот примеры тестов и сценариев, для которых не нужна автоматизация.
Пользовательский опыт (UX)
Эта область тестирования не может быть автоматизирована. Многие аспекты UX-проектирования требуют ручного, долгого и утомительного тестирования. Например, когда разработчики хотят понять, насколько легко пользователи могут зарегистрироваться на веб-сайте, или проверить, какие наборы полей дают лучшую видимость профилей пользователей. Подобные тесты должны быть проведены вручную.
Стадии ранней разработки
Когда какая-то функция только-только разрабатывается, в её код постоянно вносятся изменения, а это может затруднить составление и теста. На ручное тестирование этих функций уходит меньше времени, поэтому следует дождаться стабильной версии.
Функциональность, не имеющая большой важности
Автоматизация тестирования требует времени и усилий, поэтому следует автоматизировать тестирование не всех функций, разрабатываемых в рамках проекта, а лишь самых важных функций. Низкоприоритетные можно оставить в стороне и продолжить тестировать их вручную.
Тесты без понятных результатов
Командам разработки необходимо знать ожидаемый результат для каждого входа функции. Если результаты непонятны, то и автоматизация не предоставит необходимых доказательств того, что функция работает должным образом.
Тесты, которые невозможно полностью автоматизировать
Если автоматизирована половина теста, а другая половина так и осталась выполняемой вручную, то это приводит к сложности и дополнительным расходам, поскольку проведение такого теста требует много времени, а достоверность его под большим вопросом. Было бы рациональнее продолжать тестирование таких функций вручную.
Фреймворки автоматизированного тестирования
В каждой команде разработки и поставки ПО группа QA отвечает за разработку, внедрение и выполнение тестов. Для каждого типа тестирования должен быть определён тестовый сценарий, принципы, правила и инструменты для проведения. Фреймворк тестирования — это набор этих руководств, инструментов и практик, который помогает инженерам-тестировщикам эффективно выполнять тестовые сценарии.
Существуют разные фреймворки для разных целей тестирования. Вот некоторые из самых популярных типов фреймворков для автоматизированного тестирования:
- Модульный: приложение разделено на отдельные модули, и каждый модуль тестируется в изолированном состоянии
- Линейный: составление и исполнение тестовых скриптов. Тестировщики пишут тестовые сценарии последовательно, выполняя их затем для каждого отдельного тест-кейса
- Библиотечная архитектура: создан на основе модульного фреймворка тестирования, с той лишь разницей, что содержит функции для многократного использования
- Управляемое данными тестирование: тестовые скрипты выполняются и верифицируются на основе данных, которые хранятся в центральном хранилище данных или базе данных (SQL, ODBC-ресурсы, csv или xls файлы)
- Тестирование по ключевым словам: в данном фреймворке не обязательно иметь навыки программирования, поскольку ключевые слова, используемые при создании тестов, отделены от технического кода. Тестировщику достаточно иметь представление о всём наборе действий, реализованных во фреймворке
- Гибридный: комбинация из различных фреймворков.
Главная цель всех команд разработчиков программного обеспечения — обеспечить быструю поставку качественного и надежного программного продукта. Чтобы обеспечить быстрый и эффективный процесс поставки, необходимо непрерывное тестирование. Автоматизация — ключ к тому, чтобы разрабатываемое ПО могло быстро пройти через все стадии конвейера разработки и предоставить клиентам свои функции. Однако, это не означает, что команды должны вкладывать всё свое время и ресурсы в автоматизацию тестирования. Команды должны понимать, что можно и нужно автоматизировать, а что не стóит. Правильный выбор охвата тестов на ранних этапах разработки имеет большое значение.
Виды тестирования по степени автоматизации
Но почему же автоматизированное тестирование до сих пор не вытеснило ручное? В чем плюсы и минусы каждого из них? Давайте разбираться.
Ручное тестирование
Ручное (мануальное) тестирование — это тестирование без помощи каких-либо программ, автоматизирующих работу.
Например, чтобы протестировать работу формы авторизации, мы сами заходим на сайт и вручную заполняем поля «Имя» и «Пароль». То есть мы выступаем в роли обычного пользователя продукта.
Напомню, что ручное тестирование строится на методах тестирования. Сюда относятся и техники тест-дизайна, и техники, основанные на опыте. Просто еще раз хочу обратить внимание, что тестирование — это заранее продуманная деятельность по сравнению фактического результата с ожидаемым, а не просто поиск ошибок «методом тыка».
Плюсы ручного тестирования:
- Пользовательский фидбек. Весь отчёт тестировщика может быть рассмотрен как обратная связь от потенциального пользователя.
- UI-фидбек. В наше время пользовательский интерфейс играет огромную роль и поэтому полностью протестировать его можно только вручную.
- Дешевизна. В краткосрочной перспективе ручное тестирование дешевле, чем инструменты автоматизированной проверки.
- Тестирование в реальном времени. Незначительные изменения могут быть исследованы сразу, без написания кода и его исполнения.
- Возможность исследовательского тестирования. Его целью является проверка разнообразных возможностей приложения. Важно, что используются не заранее составленные тест-кейсы, а придуманные на лету сценарии.
Минусы ручного тестирования:
- Человеческий фактор. Хотя UI и может быть протестирован только вручную, люди часто склонны к неэффективности. Некоторые ошибки могут остаться незамеченными.
- Трудоемкость повторного использование. Провести серию стандартных автоматических тестов проще, чем протестировать проект вручную после внесения даже небольших изменений.
- Невозможность проведения некоторых видов тестов, например, нагрузочного тестирования. Невозможно смоделировать большое количество пользователей вручную.
Автоматизированное тестирование
Автоматизированное тестирование предполагает использование специального программного обеспечения (помимо тестируемого) для контроля выполнения тестов и сравнения ожидаемого результата работы программы с фактическим.
Этот тип тестирования помогает автоматизировать часто повторяющиеся, но необходимые для максимизации тестового покрытия, задачи.
Это отдельная дисциплина искусства тестирования. Значительная часть эффективности работы отдела тестирования зависит от того, какие задачи отданы для автоматизации и как эта автоматизация была осуществлена.
Подходы к автоматизации
Ниже представлена пирамида автоматизации Майка Кона, которая иллюстрирует эффективный подход к автоматизации тестирования.
Пирамида автоматизации
Ширина каждого уровня пирамиды показывает, сколько тестов должно быть на каждом уровне по сравнению с другими.
На нижнем уровне пирамиды находятся компонентные автотесты. Это тесты, которые проверяют на корректность отдельные модули исходного кода программы, наборы из одного или более программных модулей вместе с соответствующими управляющими данными, процедурами использования и обработки. Например, можно сделать тест на добавление одного товара в корзину. Или проверку одного вычисления на калькуляторе.
Средний уровень занимают интеграционные автотесты, которые верифицируют бизнес-поведение (но не через GUI). Такие тесты иногда называют API тестами. API — это интерфейс, который позволяет общаться напрямую с программой, минуя пользовательский интерфейс.
Например, вместо того, чтобы зайти на сайт, выбрать нужный товар и положить его в корзину, автотесты могут напрямую сказать сайту, отправив запрос “положи товар в корзину”.
Верхний уровень пирамиды — автотесты пользовательского интерфейса, которые непосредственно затрагивают пользовательский интерфейс. Например, проверяем отображение или изменение информации о сумме покупок в корзине через пользовательский интерфейс.
Что можно автоматизировать?
Давайте в качестве примера рассмотрим несколько программ автоматизации.
1. Программы для помощи в черноящичном тестировании. Например:
— автоматическое создание аккаунтов пользователя;
— запросы к базе данных и генерация файлов формата, утвержденного системой VISA, используя извлеченные данные;
— генерация транзакции покупки в нашем магазине и т.д.
2. Программы для регрессионного тестирования. Это специальное ПО, созданное для буквального воспроизведения действий тестировщика.
Например, согласно тест-кейсу мы должны:
— войти в систему,
— выбрать товар,
— положить его в корзину,
— заплатить,
— удостовериться, что баланс на кредитной карте уменьшается на сумму покупки.
Чтобы исполнить этот тест-кейс, мы должны запустить браузер, ввести имя пользователя и пароль, нажать на кнопку «Вход»… и, в конце концов, сравнить фактический и ожидаемый результаты. Теперь представьте себе, что некая программа делает те же самые действия за вас.
Такое ПО, как правило, поддерживает режим «Запись / Воспроизведение», т.е. когда мы нажимаем на кнопку «Запись» и начинаем кликать мышками и клацать клавишами клавиатуры, ПО записывает наши действия и, когда мы закончили, генерирует код. Этот код мы можем запустить с этим же ПО, и оно воспроизведет все наши клики и клацы, т.е. буквально будет водить курсором мышки, набирать текст и т.д.
3. Программы для тестирования скорости и надежности. Это программы, которые помогают проводить стрессовое и нагрузочное тестирование.
Плюсы и минуса автоматизации
Преимущества:
- Исключен «человеческий фактор» во время выполнения: тест-скрипт не допустит ошибки по неосторожности.
- Скорость выполнения выше возможностей человека.
- Автоматически формируемые и сохраняемые отчеты о результатах тестирования.
- Выполнение в фоне – во время выполнения тестов можно заниматься другими задачами или выполнять тест-скрипты в нерабочее время.
- Способность средств автоматизации выполнить тест-кейсы, в принципе непосильные для человека в силу своей сложности, скорости или иных факторов. Например, нагрузочное тестирование.
Недостатки:
- Необходим высококвалифицированный персонал в силу того факта, что автоматизация — это «проект внутри проекта» (со своими требованиями, планами, кодом и т.д.).
- Высокие затраты на сложные средства автоматизации, разработку и сопровождение кода тест-кейсов.
- Автоматизация требует более тщательного планирования и управления рисками, т.к. в противном случае проекту может быть нанесён серьёзный ущерб.
- Средств автоматизации крайне много, что усложняет проблему выбора того или иного средства и может повлечь за собой финансовые затраты (и риски), необходимость обучения персонала (или поиска специалистов).
- В случае ощутимого изменения требований, смены технологического домена, переработки интерфейсов (как пользовательских, так и программных) многие тест-кейсы становятся безнадёжно устаревшими и требуют создания заново.
Смешанное/полуавтоматизированное тестирование
Здесь ручной подход сочетается с автоматизированным. Например, с помощью программы создается новый аккаунт, а потом вручную генерируются транзакции покупки.
Почему ручное тестирование не вымерло?
Да, автоматизация значительно сокращает время на тестирование определенных фич. Плюс есть вещи, которые просто невозможно проверить вручную. Но не стоит забывать и о ее стоимости. Не все продукты финансово могут потянуть автоматизацию. Да и не всегда требуется что-то автоматизировать.
Также вручную можно протестировать практически любое приложение, в то время как автоматизировать стоит только стабильные системы. То есть мы не можем, по крайней мере на сегодняшний день, автоматизировать все проверки.
Автоматизированное тестирование используется главным образом для регрессии. Кроме того, некоторые виды тестирования, например, исследовательское тестирование, могут быть выполнены только вручную.
Автоматизация начинается с ручного тестирования. То есть для того, чтобы начать процесс автоматизации тестирования, нужно точно знать, что и как вы собираетесь делать. Идеальный автотест базируется на ручном тест-кейсе с должным уровнем детализации.
Ручное тестирование существует, так как невозможно автоматизировать все проверки и автоматизация не всегда финансово выгодна.
На реальных проектах часто используется комбинация ручного и автоматизированного тестирования. Уровень автоматизации зависит от многих факторов: тип проекта, особенности постановки производственных процессов в компании, финансовых возможностей и т.п.
Оба вида тестирования имеют как преимущества, так и недостатки. Комбинация обоих — хороший способ получить от тестирования максимальный результат.