Новое - это хорошо забытое старое...
Будучи тестировщиком, я всем сердцем поддерживаю идею получения стабильно работающего кода в конце каждой итерации. Верите или нет, но много лет назад (около 20), задолго до появления концепции гибкой разработки ПО, я работала в компании, которая делала именно это. Две недели разработчики работали как сумасшедшие. Мы получали стабильную версию, выполняли ряд регрессионных тестов (ручных) и объявляли продукт готовым к тестированию. Группа тестирования приступала к работе и за две следующие недели выполняла все более и более сложное тестирование, в то время как разработчики в сумасшедшем темпе писали следующую стабильную версию.
Мы все находились рядом друг с другом, и система действительно довольно неплохо работала. Конечно, мы не отправляли промежуточные версии, и в них было достаточно ошибок. А заказчики не следили за каждой итерацией. У нас отсутствовал ключевой аспект гибкой разработки ПО, называемый time-boxing: стабильно работающий код, удовлетворяющий требованиям заказчика.
Несмотря на распространение концепции гибкой разработки со всеми ее достоинствами, сегодня изменилось не так уж и много. Чтобы выполнить сложные тесты, независимые группы тестирования все равно выбирают промежуточную версию для тестирования во время следующей итерации. Мы по-прежнему сталкиваемся с проблемой синхронизации тестирования и разработки одного и того же кода. И по-прежнему идем на компромиссы, определяя стабильно работающий код , удовлетворяющий требованиям заказчика.
Гибкая разработка упирается в стену тестирования
Появление гибкой разработки с ее концепцией "сделали, сделали, сделали" подняло новую проблему. Разработчики чувствуют, что тестировщики посягают на их "жажду скорости". Тестировщики обнаруживают дефекты кода уже после того, как разработчики ушли вперед. По крайней мере, на моей старой работе было именно так. Разработчики не говорят, что прошло уже две недели и сейчас они заняты чем-то другим. Но если в тестах обнаруживаются фундаментальные проблемы, действительно ли они "сделали, сделали, сделали"? Похоже, что-то не так.
Хорошо, скажете вы, а как насчет автоматизации? Разве это не основной принцип гибкой разработки? Выполнять разработку, управляемую тестированием (test-driven development - TDD)? Могут ли разработчики выдать какой-нибудь код без модульного тестирования? Если достаточно доказать, что промежуточная версия стабильна и работающий код удовлетворяет требованиям заказчика, почему мы находим так много дефектов, используя традиционные методы тестирования? Как определить соответствие кода требованиям заказчика ? Если группа разработчиков делает демонстрационную версию, какой она должна быть? Это полностью интегрированная демонстрация значения новой функциональной возможности в контексте всей системы? Чем сложнее система, тем больше вероятность отрицательного ответа.
Что происходит? Давайте разберемся. Прежде всего, у нас есть организация-разработчик, в которой внедрены гибкие методы разработки, но вы, возможно, заметили, что я упоминала "независимую" группу тестирования. Гуру динамичной разработки обычно рекомендуют иметь собственных тестировщиков. Гибкий процесс основан на командном подходе (от этого существенно зависит успех). Почему же нужна независимая группа тестирования? Потому что приложение является частью системы, которая слишком велика, чтобы включать в себя тестирование. Даже при наилучших намерениях, включая полную разработку через тестирование и модульное тестирование в сочетании с определенным уровнем комплексного тестирования (ручного или автоматического), группа разработки не может выполнять тестирование системы: интеграция всей системы, полномасштабная производительность, большая нагрузка, большие наборы данных, безопасность и т.д. Организационно имеется независимая группа тестирования, отвечающая за следующий уровень тестов, обычно с целью достижения экономии от масштаба посредством Test Centers of Excellence.
Все выглядит примерно так:
Рисунок 1. Тестирование интеграции отстает
Время от времени тестировщик берет N дней на установку и настройку, только чтобы обнаружить, что одна из базовых функциональностей не работает. Мы называем обнаружение непригодной для использования версии полным выходом из строя (gross breakage), в котором на самом деле никто не виноват. Таким способом люди справляются со сложностью. Мы изучаем детали и становимся экспертами во все меньшем количестве областей, поскольку объем деталей, которым мы можем овладеть, ограничивает количество областей, которые мы можем глубоко освоить. Это определяет границы и места, где должна происходить передача из рук в руки.
Новый мир тестирования интеграции систем
Ладно, хватит о проблемах. Если вы читаете эти слова, значит, это ваш мир. Возможно, вы пытаетесь решить проблемы тем же способом, каким как минимум трижды пыталась решить их и я, добавляя в процесс компоновки возможность выполнения более сложного тестирования, чем то, которое обычно включается в сборку, т.е. модульные тесты. Вы создаете полностью автоматизированный план установки и настройки сборки, проверки и конфигурирования инструментальной среды тестирования, включения набора автоматизированных тестов и выдачи результатов.
Как бы все это упростить? Или сделать доступным для все более и более сложных гетерогенных систем, использующих возможности внешних систем всех видов, посредством SOAP, MQ, SOA и т.д.? Сегодня существуют средства виртуализации сервисов, позволяющие постоянно выполнять полное тестирование интеграции. Это позволяет уменьшить затраты аппаратных ресурсов и времени для настройки сложных гетерогенных систем, делая возможным выполнение тестов интеграции для каждой сборки. Если группа разработки внедрила непрерывную интеграцию, это означает тестирование интеграции каждой интегрированной сборки.
Рисунок 2. Виртуализация сервисов
Виртуализация сервисов осуществляется путем записи событий в производственной среде или среде разработки и последующей интеллектуальной замены компонентов тестируемой сложной системы. Я предпочитаю представлять этот подход как виртуализацию сложности системы, выделяя изменяющиеся части, которые хочу протестировать. Такой подход хорошо работает во многих случаях, но особенно в случае, когда другие компоненты системы не меняются или меняются редко. Он хорошо согласуется с передовыми методиками тестирования - уменьшением числа меняющихся переменных от теста к тесту. В виртуализации сервисов есть несколько интересных моментов:
- Виртуализация сложности системы способствует упрощению настройки среды тестирования.
- Интеллектуальная виртуализация сервисов включает в себя сохранение текущего состояния, которое позволяет выполнять продвинутое тестирование, например, определять недоступность сервиса каждые X раз.
- Управление тестовыми данными в виртуализированном сервисе дополняет пулы данных и корпоративные средства тестовых данных, например Optim.
- Можно виртуализировать еще несуществующие сервисы.
- Группы тестирования могут работать синхронно с группой разработки над одной и той же версией, поскольку настройка больше не является узким местом.
Таким образом, мы возвращаемся к гибкой разработке ПО и поставке стабильно работающего кода в конце каждой итерации. Это действительно новый мир, в котором тестировщики и разработчики могут согласованно работать над одним и тем же кодом в одно и то же время и действительно создавать качественный продукт. Технология Green Hat теперь включена в IBM Rational Test Workbench и IBM Rational Test Virtualization Server.