В очередной раз убедился, что тестировать лучше в манданте разработки. Не понимаю сторонников тестирования системы в той же инстанции, но в отдельном манданте. Типа данные не будут мешаться в разработческом манданте. А чего им там мешаться? Транспортами они не носятся, за исключением НСИ.
Зато проблем с отдельным мандантом хватает. Одна только забывчивость что-то перенести в него уже создает рассинхронизацию и проблемы на поиск виноватого. Зачем? Кроссмандантные разработки и настройки все равно сломают что тот, что другой мандант, если будет такой случай.
Я высказался 🙂
10 комментариев
metha
Принцип тестирования в разных мандантах development-систем простой: «разделяй и властвуй»? когда ты один в системе и ты можешь вспомнить что и когда ты настраивал то вопросов нет, а когда команда большая и настройки зачастую делаются в одних и тех же таблицах то тут как ни крути что-нить а другому консу порушишь… вот для этого и проводить тестирование надо в другом манданте… плюс еще такого решения как раз таки и в самоорганизации консультанта, если что-то настроил то донеси в целевую систему и не забудь задокументировать то что сделал….
VirVit
Как показывает практика не первого проекта, то 99% консультантов забывает переносить запросы.
Плюс документирование в России как правило делают в конце, когда продуктив сдали, смахнули пот и сели бумажки писать.
Хотя концептуально это неверно, тут соглашусь. Но мы пока не научились работать по планам.
metha
Вот именно, что организация работы консов должна быть в России через жесткое, порой даже брутальное, битье по башке, не одни работаем над проектом и ответственность за такую работу консов должен прежде всего нести РП или как минимум руководитель функциональной группой…
Calm
>>тут как ни крути что-нить а другому консу порушишь…
чем порушишь? тестовыми данными? 😯
Два конса делают одну и ту же настройку? Ну тогда конечно порушишь. Только тут и три манданта не помогут.
Поддерживаю, что первоначальное тестирование эффективнее делать в системе разработки.
metha
2Calm: говорилось о том что тестировать надо в !другом! манданте !той же системы разработки!… а порушить можно тупо вот так: возьмите себя и еще одного конса, откройте настройки категории сотрудников, настройте себе что нить, и в процессе теста одном и том же манданте системы разработки пускай другой конс Вашу категорию РУБАНЕТ неапрочь… :-))) потом удивляйтесь
metha
хотя с другой стороны смысл спорить?! в интернете всегда кто-то не прав, я вот тоже повелся
VirVit
На что ты повелся ?:)
metha
на то что посчитал что Calm не прав :-)), потому что он прав и ты прав, да и я сталкивался с тем что без отдельного манданта тестирования в системе разработки невозможно было обойтись, у меня во всех проектах базис сам его делал а руководство проекта заставляло его использовать для предварительных настроек
metha
… и вот еще что вспомнил, базис его делал для того чтобы бекапить каждый день, а бекап без прикладных данных содержащий только настройки и разработки всегда было легче подниматься нежели мандант со всем мусором которые консы хренячили
Fudo
мандант для тестирования приятен тем, что можно протестировать хотя бы сам перенос запросов, чтобы не нарваться на неожиданные ошибки при переносе в продуктив, на нем можно тестировать загрузку lsmw, когда в разработке уже что-то загружено и изменили какие-то требования и критерии+ его можно использовать для обучения юзеров.