Уважаемы коллеги!
Как правильно организовать процесс тестирования системы после установки обновлений? Кто должен этим заниматься? Поддержка у нас малочисленная и полноценно протестировать систему нет возможности. Хотелось бы переложить часть данного процесса на заинтересованных пользователей, но не получается объяснить им необходимость тестирования до того как обновления попадут в продуктив. Возможно, существуют какие-то рекомендации SAP?

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

Возможно, я неправильно сформулировал вопрос. Я не пытаюсь решить данный вопрос техническими средствами. (Стратегия, наверное, неподходящее слово). Интересует методология. Пользователи считают, что тестированием должны заниматься только айтишники и то, что невозможно протестировать важные вещи для конкретных пользователей, их не волнует. В результате после обновления системы всплывают проблемы, которые приходится решать в пожарном порядке. Хотелось бы разработать положение о порядке работ связанных с обновлением. Кто, что должен делать? Или найти рекомендации SAP по этому вопросу. Я считаю, что пользователи должны участвовать в этом процессе, и если я прав, то в идеале, нужен какой-то авторитетный источник, на который можно было бы сослаться при разработке такого положения.

не беритесь вообще за enhacment-ы и support-ы пока не решите эти проблемы. У нас конечно тоже тестирование проводится не в полном объеме, но основные бизнес-процессы тестируются - делают это наши же айтишники по модулям. Если появляется новый функционал которого не было до обновления - привлекаются ключевые пользователи - и все это на уровне тестовой системы. На это время мы тупо перекрываем разработку и customizing т.к. состояние теста/разработки и продуктива разные. В таком случае все заинтересованы провести тестирование

Это и есть административная проблема. Вы должны суметь объяснить заказчику (даже при выполнении патчей на внутреннем проекте всегда есть заказчик, т.е. человек, который инициировал процесс установки патчей), что это его дело, тестировать результаты. Базис должен иметь очень веские причины, чтобы по своей инициативе ставить патчи на работающую систему.

Вот и объясняйте это людям. Это, как ни крути (c), административная проблема.

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

Спасибо, все понятно.

[quote="avlag"]
Базис должен иметь очень веские причины, чтобы по своей инициативе ставить патчи на работающую систему.
[quote]
...
C обновлением ядра - понятно, можно ссылаться на SAP support. А, можно поинтересоваться, какие Вы выдаёте руководителям причины для того, чтобы обновить пакеты базиса и ABAP......?

bdmalex
коллега, все довольно элементарно...
если следовать стратегии сап в части установки пакетов поддержки, то патчи НИКОГДА не рекомендуется ставить отдельно, т.е. те пакеты, которые являются базисными ставятся ТОЛЬКО в совокупности со всеми остальными (в терминологии сапа - стэком)...
при этом, как правило, никому и ничего дополнительно доказывать не надо
то же самое касается ядра...

по опыту, как правило 90% проблем решается установкой нот... очень редко базису необходимо исправлять что-то в системе для себя.

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

а вообще как часто приходится ставить патчи?
у нас руководитель проекта и большинство консультантов придерживаются политики как можно реже по мере необходимости
а HR группа наоборот: "воот, уже вышел такой-то патч, а у нас до сих пор древний". а ведь его же отдельно не поставишь ;-(

и вот интересно, какая политика накатывания патчей?

вот тут можно сослаться на рекомендации сап:) там довольно четко написано "2-4 times a year"? но более-менее внятного объяснения этому как обычно нет. или я плохо искал

HR - источник всех проблем
Видимо законодательство у нас такое. Во всяком случае я уже начинаю думать, что постоянные обновления, требуемые HR'ом могут служить не самой плохой причиной отделения их в собственную систему от основного проекта

Как раз HR можно патчить отдельно, не стэком, и смысл в этом есть - народ там работает активно, обновленные формы, новый функционал и т.д. нотами это все тянуть проблематично.
Ну а тестируют конечно консультанты по модулям, ну а потом конечные пользователи... в реальном времени

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

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