(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Как раннее тестирование интеграции способствует гибкой разработке

Источник: IBM

Новое - это хорошо забытое старое...

Будучи тестировщиком, я всем сердцем поддерживаю идею получения стабильно работающего кода в конце каждой итерации. Верите или нет, но много лет назад (около 20), задолго до появления концепции гибкой разработки ПО, я работала в компании, которая делала именно это. Две недели разработчики работали как сумасшедшие. Мы получали стабильную версию, выполняли ряд регрессионных тестов (ручных) и объявляли продукт готовым к тестированию. Группа тестирования приступала к работе и за две следующие недели выполняла все более и более сложное тестирование, в то время как разработчики в сумасшедшем темпе писали следующую стабильную версию.

Мы все находились рядом друг с другом, и система действительно довольно неплохо работала. Конечно, мы не отправляли промежуточные версии, и в них было достаточно ошибок. А заказчики не следили за каждой итерацией. У нас отсутствовал ключевой аспект гибкой разработки ПО, называемый time-boxing: стабильно работающий код, удовлетворяющий требованиям заказчика.

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

Гибкая разработка упирается в стену тестирования

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

Хорошо, скажете вы, а как насчет автоматизации? Разве это не основной принцип гибкой разработки? Выполнять разработку, управляемую тестированием (test-driven development - TDD)? Могут ли разработчики выдать какой-нибудь код без модульного тестирования? Если достаточно доказать, что промежуточная версия стабильна и работающий код удовлетворяет требованиям заказчика, почему мы находим так много дефектов, используя традиционные методы тестирования? Как определить соответствие кода требованиям заказчика ? Если группа разработчиков делает демонстрационную версию, какой она должна быть? Это полностью интегрированная демонстрация значения новой функциональной возможности в контексте всей системы? Чем сложнее система, тем больше вероятность отрицательного ответа.

Что происходит? Давайте разберемся. Прежде всего, у нас есть организация-разработчик, в которой внедрены гибкие методы разработки, но вы, возможно, заметили, что я упоминала "независимую" группу тестирования. Гуру динамичной разработки обычно рекомендуют иметь собственных тестировщиков. Гибкий процесс основан на командном подходе (от этого существенно зависит успех). Почему же нужна независимая группа тестирования? Потому что приложение является частью системы, которая слишком велика, чтобы включать в себя тестирование. Даже при наилучших намерениях, включая полную разработку через тестирование и модульное тестирование в сочетании с определенным уровнем комплексного тестирования (ручного или автоматического), группа разработки не может выполнять тестирование системы: интеграция всей системы, полномасштабная производительность, большая нагрузка, большие наборы данных, безопасность и т.д. Организационно имеется независимая группа тестирования, отвечающая за следующий уровень тестов, обычно с целью достижения экономии от масштаба посредством Test Centers of Excellence.

Все выглядит примерно так:

Рисунок 1. Тестирование интеграции отстает
Рисунок 1. Тестирование интеграции отстает

Увеличенная версия рисунка 1.

Время от времени тестировщик берет N дней на установку и настройку, только чтобы обнаружить, что одна из базовых функциональностей не работает. Мы называем обнаружение непригодной для использования версии полным выходом из строя (gross breakage), в котором на самом деле никто не виноват. Таким способом люди справляются со сложностью. Мы изучаем детали и становимся экспертами во все меньшем количестве областей, поскольку объем деталей, которым мы можем овладеть, ограничивает количество областей, которые мы можем глубоко освоить. Это определяет границы и места, где должна происходить передача из рук в руки.

Новый мир тестирования интеграции систем

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

Как бы все это упростить? Или сделать доступным для все более и более сложных гетерогенных систем, использующих возможности внешних систем всех видов, посредством SOAP, MQ, SOA и т.д.? Сегодня существуют средства виртуализации сервисов, позволяющие постоянно выполнять полное тестирование интеграции. Это позволяет уменьшить затраты аппаратных ресурсов и времени для настройки сложных гетерогенных систем, делая возможным выполнение тестов интеграции для каждой сборки. Если группа разработки внедрила непрерывную интеграцию, это означает тестирование интеграции каждой интегрированной сборки.

Рисунок 2. Виртуализация сервисов
Рисунок 2. Виртуализация сервисов

Виртуализация сервисов осуществляется путем записи событий в производственной среде или среде разработки и последующей интеллектуальной замены компонентов тестируемой сложной системы. Я предпочитаю представлять этот подход как виртуализацию сложности системы, выделяя изменяющиеся части, которые хочу протестировать. Такой подход хорошо работает во многих случаях, но особенно в случае, когда другие компоненты системы не меняются или меняются редко. Он хорошо согласуется с передовыми методиками тестирования - уменьшением числа меняющихся переменных от теста к тесту. В виртуализации сервисов есть несколько интересных моментов:

  • Виртуализация сложности системы способствует упрощению настройки среды тестирования.
  • Интеллектуальная виртуализация сервисов включает в себя сохранение текущего состояния, которое позволяет выполнять продвинутое тестирование, например, определять недоступность сервиса каждые X раз.
  • Управление тестовыми данными в виртуализированном сервисе дополняет пулы данных и корпоративные средства тестовых данных, например Optim.
  • Можно виртуализировать еще несуществующие сервисы.
  • Группы тестирования могут работать синхронно с группой разработки над одной и той же версией, поскольку настройка больше не является узким местом.

Таким образом, мы возвращаемся к гибкой разработке ПО и поставке стабильно работающего кода в конце каждой итерации. Это действительно новый мир, в котором тестировщики и разработчики могут согласованно работать над одним и тем же кодом в одно и то же время и действительно создавать качественный продукт. Технология Green Hat теперь включена в IBM Rational Test Workbench и IBM Rational Test Virtualization Server.



 Распечатать »
 Правила публикации »
  Обсудить материал в конференции IBM Rational/Telelogic - системный инжиниринг, управление требованиями, изменениями, жизненным циклом ИС, умное управление проектами »
Написать редактору 
 Рекомендовать » Дата публикации: 17.12.2012 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
Rational ClearQuest Floating User License
Rational ClearCase Multisite Floating User License
IBM Rational Functional Tester Floating User License
IBM RATIONAL Rose Enterprise Floating User License + Sw Subscription & Support 12 Months
IBM RATIONAL Quality Manager Quality Professional Authorized User Single Install License + Sw Subscription & Support 12 Months
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
СУБД Oracle "с нуля"
Все о PHP и даже больше
Новости мира 3D-ускорителей
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Разработка программ базы данных (38)
Написание прикладных компьютерных программ (базы данных) на заказ. Разработка корпоративных...
 
Беговая дорожка (1)
Купила беговую дорожку вот здесь https://4gym.com.ua/product/technogym-artis-run Очень классная,...
 
Отличается ли ДрифтКазино от беттинга? (12)
Друзья, давно заметил, что на Дрифте уже несколько месяцев во всю рекламируется и предлагается...
 
Как подключить файлы ost в отлуке (3)
Проблема в следующем . База почты (входящие, исходящие, удаленные, отправленные) и адресная...
 
Ищу программиста для написания программы (54)
Ищу программиста ,владеющего Вижуал Бэйсик и программированием в Экселе, для написания...
 
 
 



    
rambler's top100 Rambler's Top100