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

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

Автоматизация тестирования с использованием agile-подхода в действии

  • Запрос от тестировщика. Одна команда завершила радикальное усовершенствование продуктивности инсталляционного тестирования – на 300%+улучшение производительности тестирования пакетов проходящих тестирование в команде. Оно было начато, когда тестировщики начали жаловаться на количество затрачиваемого времени для восстановления образов Macintosh для тестирования. Тим-лидер привел в команду программиста-консультанта, который поработал с тестировщиками для перепроектирования процесса около двух недель. Консультант подобрал несколько инструментов, которые могли бы помочь, и были схожи как на Windows, так и на Macintosh. Команда тестировщиков использовала комбинации инструментов, некоторые купили, а некоторые уже имелись в наличии. Команда работала сообща, чтобы решить проблему, но сторонний разработчик послужил катализатором и помог таки решить задачу совместно. Важно отметить, что команда планировала использовать Rational Robot (на стороне Windows) для автоматизации процесса, но решила, что этот инструмент не подходит для работы. Я расспрашивал одного тестировщика о том, как нововведение помогло ему в каждодневной работе, и он был полон восхищения от новой системы. Процесс был полностью сфокусирован и управляем потребностями тестировщиков (по сути, потребностями бизнеса),  и основывался на совместной работе программистов и тестировщиков.
     
  • Проверка инсталляции. Я установил продукт на свой компьютер. Он почти сразу спрашивает разрешения на поиск обновлений (как и ожидается) и скачивает последнюю версию с Интернета. Неожиданно она начинает сбоить каждый раз, когда я пытаюсь запустить ее. После нескольких перезагрузок я опять скачиваю из Интернета это приложение и переустанавливаю его. Проблема исчезает.  Возникает вопрос: существует ли инструмент, позволяющий тестировщику сообщить, был ли продукт установлен в систему успешно? В данной ситуации следует ответ - нет.   Было бы слишком сложно разработать такой инструмент. Наличие же его сделало бы тестирование инсталляции немного быстрее и намного более достоверным. Также, если бы тестировщики в процессе тестирования периодически сталкивались с какими-либо инсталляционными проблемами, они могли бы запустить инструмент для проверки инсталляции, чтобы убедиться, не был ли продукт испорчен. Одна из задач разработчика автоматизированных тестов на пути решения этой сложной задачи – это попробовать исследовать такие периодически возникающие баги. Автоматизация тестирования с использованием agile-подхода может увеличить вероятность того, что о важных ошибках будет сообщено своевременно.
     
  • Дампер баз данных. Работая консультантом на одном проекте, я услышал, что продукт использует сервер баз данных Microsoft Access. Мне тут же пришла мысль, что можно написать Perl-скрипт, который будет сохранять состояния базы данных (делать снапшоты), и это может быть использовано для тестов. Используя примеры со справочника по Perl, я написал данный скрипт за одну-две минуты. Я обнаружил, что некоторые данные в базе данных представлены в двоичном формате, который моя библиотека Perl ODBC не может прочитать, но большинство я мог легко получить. Я продемонстрировал скрипт своему клиенту, и показал, как его можно использовать для создания серии диагностических состояний во время тестирования, или как он может быть приспособлен для тестового инструмента, который автоматически обнаруживает  определенные виды проблем с базой данных.  

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

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

    В этом примере показано, как могут возникать спонтанно идеи при сотрудничестве разработчиков автоматизированных тестов и тестировщиков. Это также пример восприятия автоматизации тестирования в широком смысле (анализ покрытия, упрощения автоматической рассылки сообщений) в отличие от терминологии только «тест-кейсов».
  • 10 минут с Одним Тестировщиком. Я сел рядом с тестировщиком, чтобы посмотреть, как он тестирует свой продукт. Он только лишь начал устанавливать продукт, когда я заметил, что он инсталлирует его без использования инструмента для проверки, что все нужные файлы корректно установятся. Итак, я показал ему InCtrl5, инструмент с открытым кодом, который делает снапшоты системы до и после определенных событий, и создает отчет об изменениях в файлах и записях реестра. Мы начали использовать это приложение.  Затем он показал мне проблему, которую собирался исследовать. Вероятно, окно скрывалось за другим, в то время как оно должно быть спереди. Его версией было то, что окно на заднем плане получало какое-то сообщение об изменении фокуса окна, которое и переводило его на передний план не вовремя. Тестировщик поинтересовался, не знаю ли я инструмента, который мог бы протестировать эту гипотезу. Я тут же подумал о Spy++, приложении, отслеживающем сообщения Windows. Оно поставляется совместно с Visual C++. (Разработчики автоматизированных тестов должны выделять часть своего времени для ознакомления с различными видами инструментов и того, где их можно взять или приобрести). Мы начали ознакомление с Visual C++. В итоге тестировщик попросил одного из разработчиков показать нам Spy++. Мы получили`не только инструмент, но также и интересную беседу о том, чем этот инструмент может, а чем не может нам помочь в исследовании.

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

Переход к автоматизации тестирования с использованием agile-принципов:

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

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