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

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

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

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

Модульное тестирование

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

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

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

Приемочное тестирование

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

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

Интеграционное тестирование

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

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

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

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

• В нефункциональных требованиях к приложению должно быть явно выделено и описано требование по тестируемости, с тем, чтобы выбираемые технологии, платформы и инструменты позволяли выполнять автоматизацию тестирования.
• Архитектура приложения должна быть модульной или разделенной по слоям, с тем, чтобы каждый слой мог быть протестирован независимо от остальных. Например, распространенная архитектура MVC (model view controller) - хорошо тестируема на каждом уровне и вы можете применить все современные практики по автоматизации тестирования.
• Тестами должны быть покрыты практически все участки вашего приложения. В этом вам поможет методика test driven development (TDD). Суть методики заключается в том, что тесты (модульные или приемочные) создаются перед тем, как реализуется логика приложения. Таким образом, заранее продумывается контракт, интерфейсы со стороны внешнего пользователя (например, другой программы или класса).

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile