Автоматизация тестирования повышает эффективность контроля качества и является одним из важных элементов в процессе современной разработки программного обеспечения. В чем преимущества автоматизированного тестирования перед ручным? На каком этапе работы над ПО лучше начинать тестирование? И зачем нужны универсальные тестировщики?
Подходы в тестировании
В зависимости от специфики бизнеса и особенностей продукта при проведении тестирования могут использоваться различные подходы.
При традиционном подходе тестирование конкретной задачи проводится по факту ее готовности. В этом случае требования и объемы работ заранее определены, а все итерации и этапы тестирования идут последовательно.
Но применяются и другие модели — Shift-left («сдвиг процессов влево») и Shift-right («сдвиг вправо»). В первом случае тестирование требований стартует до начала кодирования, что дает возможность находить ошибки на ранних этапах и более широко покрывать программный продукт проверками. Второй подход, наоборот, не подразумевает проверок ни на этапе документации, ни даже на этапе кодирования, но способствует более быстрому выводу системы в промышленную эксплуатацию. Исправления в продукт вносятся уже на основании обратной связи от пользователей. Затраты на тестирование при таком подходе зачастую меньше.
Преимущества автоматизированного тестирования
Объемная тестовая модель с наличием большого количества ручных тестов приводит к нехватке времени на регулярное проведение полного регресса. Из-за отсутствия повторного полного тестирования после внесения изменений ранее исправленные ошибки могут появиться вновь.
Еще один аспект ручного тестирования связан с необходимостью проверять новые patch-запросы и пакеты обновлений при поддержке старых версий ПО, что является трудозатратным и идет сверх основного регресса.
Из-за человеческого фактора при ручном тестировании существует высокий риск пропуска ошибок, а между появлением бага, его обнаружением и исправлением проходит много времени.
Решить эти проблемы можно с помощью автоматизации тестирования. Она позволяет проводить круглосуточный запуск тестов в масштабируемой среде, исключает влияние человеческого фактора, а также повышает тестовое покрытие, снижает затраты и ускоряет выход продукта на рынок.
Хотя на старте стоимость автоматизированного тестирования обычно выше, чем у ручного, по мере продвижения проекта оно становится более выгодным.
Процессы функционального тестирования
Для проверки программного продукта на соответствие функциональным требованиям используется как ручное, так и автоматизированное тестирование.
Подготовка к тестированию начинается с анализа требований и написания тестовой модели. Далее готовится стенд для ручного тестирования и тестовые данные, проводятся сами тесты и составляется отчет. После этого стабильные и подтвержденные тесты передаются в автоматизацию. На этом этапе разрабатываются инструменты и скрипты для автоматизированного тестирования, настраиваются тестовый стенд и тестовые данные, производится запуск скриптов и отладка, в завершение готовится отчет.
При таком подходе проще планировать сроки работ. Каждым видом тестирования занимаются выделенные специалисты. Но есть и минусы. Основной из них — зависимость автоматизации от ручного тестирования. Автоматизаторам нужно время для погружения в контекст продукта, а для анализа результатов прохождения скриптов часто требуется привлечение специалиста по ручному тестированию. Кроме того, при увеличении ручного регрессионного набора нет времени на полные проверки.
Вот пример из практики. В одном из проектов на 20 разработчиков было выделено два специалиста по ручному тестированию, а автоматизация на старте не планировалась. При этом новая версия продукта выходила по итогам каждого спринта, раз в две недели. Использовались три тестовых стенда, в том числе один в контуре заказчика, причем проверка требовалась на каждом из них. В результате фактические сроки разработки оказались на полгода больше, чем в изначальном плане. Увеличилась и стоимость тестирования. За счет позднего расширения проектной команды и внедрения автоматизации затраты на тестирование выросли в полтора раза по сравнению с первоначальными расчетами.
Универсальное тестирование
В универсальном подходе нет четкого разделения команды на ручное и автоматизированное тестирование. Оно также начинается с анализа требований и написания тестовой модели. Далее готовятся инструменты автоматизации и пишутся скрипты, после чего специалисты занимаются подготовкой стенда и тестовых данных. Следующие шаги — проведение тестирования и запуск скриптов. И завершающий этап — подготовка отчета.
При таком подходе в архитектуру тестовой модели уже изначально заложены критерии для эффективной автоматизации. Автоматизаторам не требуется дополнительное время на погружение в контекст проекта. Кроме того, за счет совмещенной активности по ручному и автоматизированному тестированию сокращается время непосредственного проведения тестов.
Однако при универсальном тестировании нет выделенных специалистов на написание только скриптов, поэтому нужна постоянная балансировка времени и предъявляются более высокие требования к компетенциям сотрудников. Кроме того, на стадии технической реализации инфраструктуры тестирования зависимость от отдельного высококвалифицированного специалиста все равно остается.
При таком подходе привлекаются универсальные тестировщики, а также SDET-специалисты (Software Development Engineer in Test), занимающиеся разработкой инфраструктуры и софта для тестирования. В отличие от работы классического тестировщика SDET-специалист имеет доступ к исходному коду и знает, как работает приложение изнутри, а не только со стороны пользователя. Понимание технического стека системы позволяет проводить тестирование более эффективно.
Рассмотрим применение универсального тестирования на примере одного из проектов. В рамках него работы по тестированию были заложены еще на старте, а в процессы разработки добавлены этапы контроля качества. Новые сборки выходили еженедельно. Разработчик и заказчик использовали разную инфраструктуру. В результате удалось покрыть автоматизацией большее количество проверок, связанных со справочниками и чистотой данных, и выстроить CI/CD-процесс с контролем качества на этапе новой сборки. Получалось быстро реагировать на ошибки, возникающие на стенде заказчика. Примечательно, что итоговая стоимость проекта оказалась всего на 5% выше, чем без использования процессов контроля качества.
Таким образом, автоматизированное тестирование помогает оперативно выявлять проблемы при развертывании новых версий на различных стендах и сокращает сроки разработки. При этом есть возможность рассчитать целесообразность автоматизации. Повысить эффективность контроля качества можно с помощью внедрения тестирования еще на этапе разработки архитектуры и задействуя команду из универсальных тестировщиков и SDET-специалистов.
