Автоматизация тестирования с использованием Agile-подхода. Часть 1


(Mykhailo Poliarush) #1

Часть 1Часть 2Часть 3Часть 4


Резюме


Данная статья описывает подходы Agile-разработки к автоматизации тестирования в средних и крупных проектах.


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


Принципы автоматизации тестирования


При планировании систематичной и продуктивной автоматизации тестирования, полезно будет помнить о нижеследующих принципах. Они были сформулированы исходя из опыта многих инженеров и менеджеров по автоматизации тестирования, на протяжении последних 15 лет. Некоторые из них я подробно объяснил в своей статье «Test Automation Snake Oil» и в моей книге «Lessons Learned in Software Testing».



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

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


    1. Генератор тестов (генератор данных и скриптов). Инструменты автоматизации могут создавать специальные данные, например, произвольные электронные письма, или наполнять базу данных, или генерировать комбинации параметров и данных, которые нам необходимы при тестировании;

    2. Конфигурации системы. Инструменты могут сохранять или воссоздавать параметры системы, устанавливать систему в определенное состояние, или создавать, или восстанавливать «образы» жестких дисков;

    3. Симуляторы. Инструменты могут симулировать подсистемы или условия среды (окружения), которые не доступны (или временно недоступны) для тестирования, либо слишком дорогие, чтобы использовать их в реальности;

    4. Выполнение тестов (среда и тестовые скрипты). Инструменты могут управлять тестируемым приложением самостоятельно, или симулировать работу пользователя с графическим интерфейсом приложения, или обходя графический, использовать альтернативный тестируемый интерфейс;

    5. Исследование. Инструменты могут показать то, что осталось бы невидимым для людей. Они могут статично анализировать продукт, парсить файлы с логами, или проводить мониторинг параметров системы.

    6. «Детекторы»(оракулы). Под детектором подразумевается любой механизм для определения успеха или неудачи. Инструменты могут выявлять определенные виды сбоев в продукте.

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

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

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

  4. Тестовых инструментов очень много и они очень разнообразны
    Большинство людей, особенно менеджеров, считают, что тестовые инструменты – это только то, что представлено на рынке как «инструменты для тестирования». Зачастую они достаточно дорогие. Но, на самом деле, почти все можно использовать в качестве тестовых инструментов, и многие утилиты, которые продаются для совсем других целей, могут оказаться очень полезными для тестирования. Некоторые такие утилиты бесплатные, некоторые поставляются в репозиториях для разработчиков. Ресурсы, которые я использую:

    1. Универсальная библиотека MSDN;

    2. Все средства для разработки ПО от Microsoft (в них всегда включены полезные утилиты);

    3. Наборы для исправлений несовместимостей (compatibility toolkit) от Microsoft (www.microsoft.com);

    4. Web-основанные ресурсы для тестирования web-приложений (HTML checker, анализаторы доступности);

    5. Resource Kit от Microsoft (доступен от Microsoft);

    6. Скриптовые языки (например, Perl, Ruby, TCL) и связанные с ними библиотеки;

    7. Открытые хранилища программного обеспечения (http://download.com);

    8. Приложения для мониторинга операционной системы (http://sysinternals.com);

    9. Приложения для тестирования с открытым кодом (http://opensourcetesting.org);

    10. Программы-шпионы для экспериментальных тестов (www.spectorsoft.com);

    11. Случайные разработки (бывает, что кто-то в свободное время взял и уже разработал необходимую утилиту). 

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

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

Часть 1Часть 2Часть 3Часть 4