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

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

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

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

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

Недостатки автоматизации тестирования (их тоже немало):

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

Для того чтобы принять решение о целесообразности автоматизации приложения нужно ответить на вопрос «перевешивают ли в нашем случае преимущества?» — хотя бы для некоторой функциональности нашего приложения. Если вы не можете найти таких частей, либо недостатки в вашем случае неприемлемы – от автоматизации стоит воздержаться.

При принятии решения стоит помнить, что альтернатива – это ручное тестирование, у которого есть свои недостатки.

В поиске эффективных мест для автоматизации вам может помочь глава «Что необходимо автоматизировать».

Автоматизация тестирования: от выбора стратегии до выбора реализации

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

Стратегия автоматизации тестирования при разработке программного продукта тесно связана со стратегией тестирования в целом. На ее формирование влияют такие факторы, как цели тестирования, определяющие объекты и виды тестирования, оценка необходимой тестовой среды, определение необходимых процессов и инструментов автоматизации.

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

Разобраться в этих нюансах помогает ведущий специалист-тестировщик компании IT_One Алексей Антонов.

Алексей Антонов
Ведущий специалист-тестировщик компании IT_One

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

• Какие цели мы преследуем?
• Что именно мы будем тестировать?
• Какие виды и уровни тестирования будем применять?
• Какое тестовое окружение нам понадобится?
• Кто будет этим заниматься?
• Когда необходимо планировать мероприятие по тестированию?
• Какие существуют ограничения на объем выполняемых работ?

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

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

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

На этапе формирования перечня объектов тестирования нам нужно понять, из чего наша система состоит, видеть ее логическую архитектуру, получить спецификацию или набор требований к системе. В нашем примере с интернет-магазином пользователь обращается к сервису через веб-интерфейс или с помощью мобильного приложения; имеется сервер приложений, с которым происходит взаимодействие по протоколу HTTP/HTTPS на базе REST архитектуры; в базе данных накапливается информация о покупках, платежах и прочих операциях пользователя; интеграция с какой-то внешней системой позволяет магазину выполнять доставку товара, проводить платежи и т. д.

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

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

Автоматизировать или нет?

Теперь перед нами встает задача: какую часть процесса тестирования мы можем автоматизировать. При этом мы учитываем следующие факторы:

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

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

Можно выделить ряд проектов, в которых автоматизация всегда оправдана:

1. долгосрочные проекты с частыми изменениями;
2. проекты с высокими требованиями по безопасности;
3. проекты со сложными вычислениями, фильтрацией данных;
4. тестирование сборки и установки;
5. протоколы, API и интеграции;
6. высоконагруженные системы;
7. проекты с высокими требованиями к качеству разработки.

Наоборот, автоматизация окажется излишней в небольших коротких проектах без поддержки (PoC, демо) и в проектах с небольшим количеством итераций тестирования.

Выбор инструментов тестирования

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

Вернемся к нашему примеру с интернет-магазином и первому объекту тестирования: интерфейсу пользователя. Мы берем конечный интерфейс взаимодействия пользователя с нашей системой и начинаем подбирать наиболее подходящий инструмент, обращая особое внимание на то, насколько стабильно он распознает и умеет управлять элементами интерфейса. В итоге это могут быть такие программные продукты, как как Unified Functional Testing (UFT), Katalon Studio, Test Complete, Ranorex или программные библиотеки Selenium, Appium и аналогичные им.

Аналогично мы выбираем инструменты для других объектов с учетом их специфики. Например, для тестирования автоматизации API приоритет отдается поддержке нужных протоколов взаимодействия, а для тестирования хранилища данных – работе инструмента с СУБД.

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

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

Открытый код, проприетарный продукт или собственная разработка

Отдельно стоит упомянуть о разделении инструментов тестирования на категории по типу разработки:

1. решение на базе Open Source-элементов;
2. коммерческое (проприетарное) решение;
3. внутренняя разработка.

Каждая категория имеет свои преимущества и недостатки.

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

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

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

Так ли надо писать код

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

Менеджер продукта, аналитик, тестировщик – создают тесты, определяют наборы тестов с приоритетами, пишут некие скрипты для автоматизации, запускают автотесты, анализируют результаты. В целом они формируют требования к автоматизации тестирования, так как являются основными пользователями.

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

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

DevOps инженер – помогает как разработчикам, так и тестировщикам, а также автоматизаторам в поддержке и развертывании сред разработки и выполнения автоматизированного тестирования.

Итак, писать код стоит:

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

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

Когда стоит переходить к автоматизации тестирования на проекте?

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

Автотесты

Ручное тестирование

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

Предпосылки для использования автотестов в команде:

1. Ваше приложение имеет большое количество функций, требующих проверки на регрессе;
2. Масштаб проекта и долгоидущие планы на его развитие, хотя бы больше года. В этом случае также пора задуматься об уменьшении ручного труда с переходом в автоматизацию.
3. Частые релизы. Если ваш проект увеличивается, релизы ускоряются, но штат сотрудников QA остается прежним, то стоит приступать к автоматизации, многие рутинные операции получится быстрее проверять.
4. Усложнение технологий, в котором проверить «вручную» сложно. Перелопачивать действительно большой объем данных, с которым мы можем столкнуться разве что в BigData, не имеет смысла. Например, сложно вручную проверить все связи между микросервисами или в IoT (Internet of Things).

Стратегия, которая поможет на первых шагах автоматизации:

1. Исследуйте. Потратьте время на поиски повторяющихся кейсов, которые выполняются регулярно. Это позволит снизить нагрузку на специалистов QA в целом;
2. Ищите связи. Если ли вы проводите тестирование в разных браузерах (UI-тесты) с одним бизнес-кейсом — автоматизируйте данные операции;
3. Работайте в команде. При изменениях вашего ПО (рефакторинге, добавлении новой функциональности или изменении текущей) будьте готовы поддерживать ваши кейсы в актуальном состоянии. И прислушивайтесь на планировании, что делают ваши коллеги разработчики, чтобы тесты не падали.
4. Руководствуйтесь логикой. Автотест должен быть независим от других тест-кейсов — тест должен быть объективно маленьким, легко читаться и проверять одно условие.
5. Подходите творчески. Автотест должен иметь стабильный ожидаемый результат (не всегда рекомендуется использовать генерацию случайных величин, чтобы избежать нестабильных (flaky) тестов, который то работает, то нет, и каждый раз необходимо тратить время и искать причину).
6. Следите за порядком. Автотесты не должны дублировать проверки между собой. Например, на уровне unit-тестов можно проверить вариации данных, на API уровне выполнить проверку между сервисами, используя т.н. заглушки — самописные приложения (stub), UI-тестами проверить клиентские сценарии (переход по страницам, ввод данных, нажатие кнопок). Таким образом, будет разбивка между проверками для бизнес-функций на каждом уровне тестирования для достижения оптимального времени прогона автотестов.

Была ли статья полезной?

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

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

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

Задачи автоматизации

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

Автоматизация нужна для того, чтобы:

• Заменить трудоемкое ручное тестирование рабочих процессов и множества сценариев
• Исключить ошибки вследствие «человеческого фактора»
• Обеспечить прозрачный контроль над процессом тестирования
• Сократить затраты при повторно используемых скриптах
• Получить точные и надежные результаты испытаний
• Сократить время выхода готового продукта на рынок
• Улучшить процесс разработки (Continues Integration)

Когда нужно автоматизировать

Как понять, что пришло время автоматизировать тестирование? Во всех ли случаях рентабельность инвестиций в автоматизацию будет оправдана?

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

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

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

• Сценарии регулярно повторяются
• Сценарии трудоемки, сложны и не подходят для ручной проверки
• Проверка тест-кейсов занимает много времени
• Сценарии для высоконагруженных приложений (High-load applications)

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

Что автоматизировать

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

• Back-end процессы и сервисы
• API
• Запись логов
• Работу баз данных
• Часто используемые опции и инструменты сайта, приложения, ресурса: формы регистрации, системы онлайн-оплат и т.п.
• Автоматизацию заполнения полей, сохранение и проверку
• Валидацию вводимых данных
• Хранение и целостность данных

Какие типы тестирования можно автоматизировать

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

Рассмотрим типы тестирования, которые рекомендуется автоматизировать.

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

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

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

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

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

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

Выбор той или иной стратегии зависит от того, с каким проектом сталкивается компания-тестировщик. Если автоматического тестирования (АТ) не проводилось, точные цели не были поставлены, тогда рекомендуется начать с подготовительных этапов, внимательно отнестись к выбору инструментов, и начинать работу с верхнего уровня, не сильно углубляясь в АТ определенных модулей.

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

Как проходит процесс автоматизации тестов

Рассмотрим работы поэтапно:

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

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

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

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

Инструменты для автоматизации

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

При их выборе важную роль играет наличие таких функций:

• Простота использования и интуитивно понятный интерфейс
• Встроенная поддержка основных типов тестирования – производственное, регрессионное, функциональное и т.п.
• Легкость в отладке и поддержке сценариев
• Формирование информативных отчетов о тестировании

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

Selenium

Selenium предназначен для тестирования сайтов и веб-приложений на разных операционных системах и браузерах. Его преимущество в том, что тестировщики могут выбирать свой язык программирования для написания тестов. Среди основных: Python, Perl, PHP, Java, C# и др.

TestingWhiz

Данный инструмент позволяет наладить автоматизированное тестирование для веб-продуктов и мобильных приложений, ПО, баз данных, программных интерфейсов приложений (API). Среди тестов поддерживается регрессионное и кроссбраузерное тестирование.

HPE UFT

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

JMeter

Создавался для тестирования веб-приложений, но сегодня его функционал позволяет проводить нагрузочное тестирование для таких соединений как FTP, HTTP, JDBC, POP3, LDAP и др. С его помощью можно создать группу запросов сразу с нескольких ПК. Результаты тестов оформляются с использованием инфографики.

TestComplete

Платформа от компании SmartBear Software, в которой настроена автоматизация десктопных и мобильных продуктов с поддержкой таких языков: C ++ Script, Python, C# Script, JavaScript, DelphiScript, JScript, VBScript.

TestNG

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

Sahi

Инструмент для автоматизированных тестов мобильных приложений, написанный на Java и JavaScript. В платформу встроена поддержка таких фреймворков как Dojo, ExtJS, YUI и др. Одной из функций является кроссбраузерное тестирование.

Ranorex

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

Webload

Платформа для автоматизации тестирования с широким функционалом с возможностью нагрузки от Amazon EC2 в случае облачного тестирования. Формирует более 80 вариантов (на выбор) отчетов с использованием инфографики.

Postman

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

Резюме

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

Когда нужна автоматизация:

• При разработке масштабного приложения, ПО или сайта с большим набором функций
• Для долгосрочных проектов
• При внедрении CI/CD, выпуске регулярных релизов

Преимущества автоматизации:

• Оптимизация затрат
• Ускорение процесса тестирования
• Повышение качества ПО
• Сокращение времени и ресурсов на проведение тест-кейсов
• Повышение эффективности работы команды
• Широкое тестовое покрытие
• Поддержка и обновление автотестов

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