Тестирование в манданте разработки

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

Зато проблем с отдельным мандантом хватает. Одна только забывчивость что-то перенести в него уже создает рассинхронизацию и проблемы на поиск виноватого. Зачем? Кроссмандантные разработки и настройки все равно сломают что тот, что другой мандант, если будет такой случай.

Я высказался 🙂

10 thoughts on “Тестирование в манданте разработки

  • Принцип тестирования в разных мандантах development-систем простой: “разделяй и властвуй”? когда ты один в системе и ты можешь вспомнить что и когда ты настраивал то вопросов нет, а когда команда большая и настройки зачастую делаются в одних и тех же таблицах то тут как ни крути что-нить а другому консу порушишь… вот для этого и проводить тестирование надо в другом манданте… плюс еще такого решения как раз таки и в самоорганизации консультанта, если что-то настроил то донеси в целевую систему и не забудь задокументировать то что сделал….

  • Как показывает практика не первого проекта, то 99% консультантов забывает переносить запросы.

    Плюс документирование в России как правило делают в конце, когда продуктив сдали, смахнули пот и сели бумажки писать.

    Хотя концептуально это неверно, тут соглашусь. Но мы пока не научились работать по планам.

  • Вот именно, что организация работы консов должна быть в России через жесткое, порой даже брутальное, битье по башке, не одни работаем над проектом и ответственность за такую работу консов должен прежде всего нести РП или как минимум руководитель функциональной группой…

  • >>тут как ни крути что-нить а другому консу порушишь…

    чем порушишь? тестовыми данными? 😯
    Два конса делают одну и ту же настройку? Ну тогда конечно порушишь. Только тут и три манданта не помогут.

    Поддерживаю, что первоначальное тестирование эффективнее делать в системе разработки.

  • 2Calm: говорилось о том что тестировать надо в !другом! манданте !той же системы разработки!… а порушить можно тупо вот так: возьмите себя и еще одного конса, откройте настройки категории сотрудников, настройте себе что нить, и в процессе теста одном и том же манданте системы разработки пускай другой конс Вашу категорию РУБАНЕТ неапрочь… :-))) потом удивляйтесь

  • хотя с другой стороны смысл спорить?! в интернете всегда кто-то не прав, я вот тоже повелся :mrgreen:

  • на то что посчитал что Calm не прав :-)), потому что он прав и ты прав, да и я сталкивался с тем что без отдельного манданта тестирования в системе разработки невозможно было обойтись, у меня во всех проектах базис сам его делал а руководство проекта заставляло его использовать для предварительных настроек

  • … и вот еще что вспомнил, базис его делал для того чтобы бекапить каждый день, а бекап без прикладных данных содержащий только настройки и разработки всегда было легче подниматься нежели мандант со всем мусором которые консы хренячили

  • мандант для тестирования приятен тем, что можно протестировать хотя бы сам перенос запросов, чтобы не нарваться на неожиданные ошибки при переносе в продуктив, на нем можно тестировать загрузку lsmw, когда в разработке уже что-то загружено и изменили какие-то требования и критерии+ его можно использовать для обучения юзеров.

Добавить комментарий