Вход

Клонируют не только овечек, или опять о тестовых средах

21.08.2012 12:54 15 4 315 просмотров
Наш мир развивается по законам диалектики. Не является исключением и процесс тестирования в ИТ. Изначально вполне нормальным явлением была ситуация, когда тестирование не проводилось. Нет, оно, конечно, проводилось разработчиками программного обеспечения, но не более того. «Слова джентльмена» обычно было достаточно для того, чтобы начать внедрение и эксплуатацию. Конечно, были опасения и проводился ряд мероприятий для того, чтобы обеспечить корректность работы нового решения в условиях реальной эксплуатации. Контролировалась достоверность получаемого результата. В условиях ограниченности ресурсов такая проверка программного обеспечения осуществлялась в основном силами клиента. Со временем нагрузка на пользователей становилась больше, системы сложнее, а ошибки в реальной эксплуатации происходили все чаще. Возникла насущная потребность системной организации процесса тестирования.

Первые коммерческие банки в России стали появляться в начале 90-х годов. На процесс развития ИТ в банках оказал сильное влияние финансовый кризис 1998 года, который совпал по времени с переходом на новый план счетов. Финансовых ресурсов в это время было мало, программное обеспечение стоило дорого, резервов аппаратных ресурсов практически не было. Несмотря на трудности, в том числе и значительное сокращение ИТ-специалистов, функциональное тестирование в банках проводилось в полном объёме. Оно выполнялось достаточно медленно, привлекались все имеющиеся ресурсы службы поддержки, технологи и специалисты профильных подразделений. Шли годы, бизнес набирал силы. Кризис завершился. Банки стали покупать новое программное обеспечение. Потребовалась его интеграции с уже имеющимся программным обеспечением банка. Процесс тестирования усложнился. Банки были вынуждены закупать специальное программное обеспечение для автоматизации этого процесса. Появились самостоятельные подразделения тестирования, оно стало более качественным. Все эти обстоятельства привели к повышению требований к тестовым стендам. В условиях ограниченного финансирования реализация этой задачи была возложена на плечи системных администраторов. Учитывая то, что резервное копирование и восстановление систем в случае сбоя обеспечивали сотрудники службы поддержки, то было вполне логичным решением – поручить создание тестовых стендов этим специалистам.

Следующим витком развития процесса тестирования стало создание виртуальных серверов приложений и баз данных. Процесс наладился, объёмы тестирования увеличились. Значительные результаты в оптимизации используемых вычислительных ресурсов была достигнуты благодаря их виртуализации. На этом можно было бы радостно поставить жирную точку, но…. На пути тестирования стали возникать новые проблемы. Диалектика, ничего с этим не поделаешь.

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

Впоследствии часть этих задач была тем или иным способом решена силами собственных ИТ-департаментов банков, но часть остаётся по ряду причин ещё нерешённой. Ускорить устранение проблем, остро стоящих перед подразделением тестирования, возможно совместными усилиями специалистов банка и системных интеграторов. Специалисты «Техносерва» подготовили техническое решение, которое позволяет устранить перечисленные выше проблемы, а также максимально автоматизировать процессы создания и учёта тестовых сред. Буду рад обсудить с читателями этого портала проблемы, которые возникают у них при реализации процесса тестирования, и поделиться возможными вариантами решения выявленных проблем.

Комментарии 15

Александр Ильиных  (detlst)
#
Цитата
Специалисты «Техносерва» подготовили техническое решение, которое позволяет устранить перечисленные выше проблемы, а также максимально автоматизировать процессы создания и учёта тестовых сред

Уважаемый Александр, жизнь богата непредсказуемостями и огромной вариабельностью. Один банкир при создании нового банка сделал ставку на тестирование интернетбанка его пользователями, несмотря на то, что разработчики имели в арсенале множество программно- аппаратных средств для тестирования и отладки. Мне и моим коллегам- пользователям этого интернетбанка- посчастливилось участвовать в процессе "народного" тестирования этого продукта.
Думаю, наши замечания и предложения были полезны, ибо никакой разработчик тест- систем и собственно программных продуктов не в состоянии предусмотреть все многообразие ситуаций, которые возникают при различных аспектах использования этого продукта.
Alex  (BankCoda)
#
Конечно чем больше людей привлечено к тестированию - тем качественнее будет результат.
У профессиональных разработчиков есть бетиа версии, которые может протестировать практически каждый желающий.
Но не все согласятся быть подопытными кроликамт.
И приведенный вами пример говорит о выборе владельца не только способа тестирования, но и доработки функционала. А это, согласитесь, две большие разницы.
Александр Ильиных  (detlst)
#
Цитата
пример говорит о выборе владельца не только способа тестирования, но и доработки функционала. А это, согласитесь, две большие разницы.

Хороший программный продукт- непрерывно развивающийся и добавляющий новый функционал. Что плохого в тестировании вновь вводимого функционала? Понятно, что разработчик производит отладку и тестирование и лишь после этого выкладывает бета- версию. Но, как показала практика, даже после длительного тестирования разработчиком опытные тестеры- пользователи продукта практически всегда обнаруживают какие- либо замечания. Кто-то считает таких людей "подопытными", а кому-то процесс тестирования доставляет удовольствие. Все люди разные.
Михаил  (mih@)
#
Цитата
Один банкир при создании нового банка сделал ставку на тестирование интернетбанка его пользователями

Мне вот тоже довелось поучаствовать в таком мероприятии. Только тестирование было скорей не "народное", а "рабочее". То есть всех сотрудников обязали: тестируем интернет-банк; все замечания, пожелания туда-то...
Полтора года мучений и вот продукт "уже" показали клиентам. "Сырой", "кривой"... зато сами!
Здесь смысл-то, как раз в том, чтобы во время тестирования собрать профессиональную проектную команду: представителей и ИТ, и бизнеса, вообщем привлекать тех специалистов и экспертов, которые так или иначе связаны с работой системы.
Иначе получим: например, где-то перевод с карты на карту занимает несколько минут, а где-то сутки...
Sterh_fb  (Sterh_fb)
#
Уважаемый Александр, жизнь богата непредсказуемостями и огромной вариабельностью. Один банкир при создании нового банка сделал ставку на тестирование интернетбанка его пользователями, несмотря на то, что разработчики имели в арсенале множество программно- аппаратных средств для тестирования и отладки.
Александр, Вы читайте то что пишется, "народное" тестирование применимо к интерфейсу продукта, не более, речь идет совсем о другом...
Александр Горшков  (technoserv)
#
Sterh_fb, спасибо за поддержку. Немного дополню Ваш комментарий.
Народное тестирование в банке возможно только в продуктах, предлагаемых внешним клиентам. А таких продуктов очень ограниченное число: клиент-банк, интернет-банк, контакт центр. Может еще 1-2 - и все.
Михаил  (mih@)
#
Александр, сомнительно как-то выглядит "народное" тестирование, даже в ограниченном числе продуктов. Согласен, что какие-то замечания будут дельными, но сколько их будет из общей массы?
Да и потом, "обкатывание" на клиентах, может дорого стоить банку, если обнаружится серьезный изъян, можно и какую-то часть клиентов потерять. На моей практике, подобного рода тестирование сводилось банально к интерфейсу, в данном случае, согласен со Sterh_fb
Александр Горшков  (technoserv)
#
Михаил, согласен, что тестировать должны профессионалы, или как минимум обученные люди.
Что толку в тестирование, если тысяча пользователей будут проверять один и тот же бизнес процесс, например, оплату за телефон, и ни кто не проверит налоговые платежи?
Кто подготовит программу те тирования?
Как будет организовано нагрузочное тестирование?
Народное тестирование чем-то напоминает программы с открытым кодом.
Участников много, а результат не предсказуем.
Георгий Дорохов  (Netmould)
#
Отвечу из опыта (для внутренних продуктов, но все может быть применимо и к клиентским), по специфическим для тестовых стендов проблемам.
1. Нет описания (или фрагментарное) сервисов, предоставляемых IT (по-другому - не описаны бизнес-процессы). Из этого следует целый ряд проблем, с разной степенью решаемости (к примеру, сложности с построением инфраструктуры аналогичной промышленной для конкретного тестирования).
Решения однозначного наверное нет - можно запустить проект по описанию процессов, однако при низкой эффективности работ (когда это решается силами внутреннего IT) процессы будут изменяться быстрее, чем их будут описывать. Жаль, что это мало кто понимает, все смотрят на нулевую стоимость данного подхода (которая на самом деле не нулевая).
2. Нет механизма выгрузки/загрузки определенного набора данных для систем, участвующих в тестировании. Критично, когда имеем дело с большим объемом. Пример из жизни - у некой системы загружаемые данные за день представляли собой 1000+ текстовых файлов (выгрузки из разных систем) с разными масками, разными структурами, невозможностью загрузить руками все файлы сразу и общим объемом под 400 Гб.
Решение - затрудняюсь ответить. Разработка механизма, позволяющая провести загрузку во все системы за один день? Для CRM + АБС + все интегрированные системы? Это будет проект примерно такого же уровня, что и внедрение единого хранилища данных smile:).
3. Слабая организация самого процесса тестирования на орг. уровне. Когда вместо экземпляров сред мы имеем просто набор тестовых систем и тестовой шины, непонятно как интегрирующихся друг с другом (а часто вообще "на лету") - это очень плохо. Когда мы к этому добавляем отсутствие ответственного за среды, отсутствие механизмов контроля и мониторинга, когда у всех есть администраторские привилегии на эти системы - это конец.
Решение - мне кажется, что простыми орг. мерами (назначение ответственного) тут не отделаешься. Надо внедрять общепринятые процессы разработки ПО (раз уж мы этим занимаемся), внедрять релиз-менеджмент, и т.п., и наверное что-то еще.
4. Ну и наверное последнее - это отсутствие необходимых знаний (нет методик, или людей которые их знают, слабые бизнес/системные аналитики которые пишут плохие документы и т.п.). Эта проблема порождает наибольшее количество ошибок в ходе эксплуатации (и формирует первичное мнение заказчика о качестве предоставленной услуги), остальные три в основном просто замедляют (в крайнем случае - останавливают) процесс разработки.
Решение - тут все просто. Обучать существующих, нанимать новых людей с успешным опытом и знаниями, внедрять методики. К сожалению, на это в IT департаментах обращают внимание в самую последнюю очередь...

Наверное пока хватит, извините что в этой теме делюсь опытом и решениями, но может вы что-то посоветуете по описанным проблемам, отличное от моих вариантов решения?
Александр Горшков  (technoserv)
#
Георгий, для меня очень важен личный опыт учатников проектов.
Проект по созданию тестовых стендов предполагает внедрение бизнес-процессов по их созданию и управлению тестовыми средами. Процесс тестирования - это отдельная тема с отдельной организацией бизнес-процессов. Внедрение создания тестовых сред предполагает организацию описания всех параметров настроек и интеграции с взаимосвязанными програмами.

Большенство описаных Вами проблем решаются созданием отдельного подразделения тестирования. В рамках этого подразделения должен быть реализован учет тестовых сред и распределение прав доступа.
Георгий Дорохов  (Netmould)
#
Ну, в общем-то даже аргументацию и процесс реорганизации можно отдать на аутсортинг. Уверен, что грамотный пресейл способен "продать" идею о создании/реорганизации подразделения тестирования (и как нагрузка - предоставить свое решение по организации тестовых стендов. Главное - правильно подать проблему и способ ее решения (за годы работы создалось впечатление, что большинство "доморощенных" CIO просто не понимают, насколько увеличиваются затраты на IT без работающего процесса тестирования). И очень хорошо иметь за плечами пару сработавших проектов с выкладками и графиками - тем более, что цифры действительно должны внушать уважение.
Александр Горшков  (technoserv)
#
Конечно можно многое передать внешнему подрядчику, но это другая тема и, опасаюсь, если я ее буду развивать, то меня опять обвинят в рекламе:).
Alex  (BankCoda)
#
Александр, спасибо за исторический экскурс, но на мой взгляд весьма важными является еще и организационные вопросы.
Организация взаимодействия между подразделениями в процессе проведения тестирования, контроль качества, обеспечение безопасности и т.д.
Не предлагаю обсуждать этот вопрос в блоге, скорее эта тема для форума, но с статье этот вопрос не отменен.
Александр Горшков  (technoserv)
#
Alex, разделяю вашу точку зрения.
Кто уже пытался реализовать процессы тестирования или создания тестовых сред, тот отлично понимает, что без качественной организации этих процессов положительного результата добиться не получится.
A A  (NC_)
#
А кто-то обходится совсем без тестирования. smile:)
Комментарии и отзывы могут оставлять только зарегистрированные пользователи.
Авторизуйтесь или зарегистрируйтесь.

Популярные сообщения

Оплата ЖКХ
С 1 декабря в Платежном кабинете Системы «Город» доступна оплата всех жилищно-коммунальных услуг без комиссии! Осуществить платеж по услуге «Оплата
10
Olympic athletes from Russia
Все ! Надоело ! Сегодня бросил пить и встал на лыжи . В стране мало "чистых" спортсменов . До Олимпиады время есть . Может на что и сгожусь . Ит мой спик
0
Рынок нефти 11 декабря
Нефть сдержанно корректируется на фоне данных о росте числа нефтяных буровых установок в США. Статистика от Baker Hughes в очередной раз зафиксировала
0
Почему Ребалансировка важна
Оставайтесь в стороне от рыночных колебаний и придерживайтесь своего долгосрочного инвестиционного план, ежегодно балансируя свой портфель. Убрав эмоции
0

Новые сообщения

  • Рынок нефти 14 декабря
    Нефтяные цен незначительно корректируются после снижения накануне. Рынок негативно оценил еженедельный отчет Минэнерго США. Несмотря на то, что запасы
  • Рынок нефти 13 декабря
    Нефть сдержанно плюсует в ходе утренних торгов после выхода данных от API о снижении запасов нефти в США по итогам недели. Статистика отразила сокращение
  • Рынок нефти 12 декабря
    Brent обновила 2,5 летние максимумы. Во второй половине понедельника оператор трубопровода Forties Pipeline в Северном море сообщил об остановке подачи
  • Почему Ребалансировка важна
    Оставайтесь в стороне от рыночных колебаний и придерживайтесь своего долгосрочного инвестиционного план, ежегодно балансируя свой портфель. Убрав эмоции
  • Почему глобальная диверсификация имеет значение
    За последние несколько лет некоторые инвесторы начали подвергать сомнению достоинства глобального распределения активов. Они задаются вопросом, оправдывают