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

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

VirVit 10 комментариев
Заметки на полях

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

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

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

10 комментариев

metha

Август 1, 2011 в 11:21 дп

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

 

VirVit

Август 1, 2011 в 11:25 дп

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

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

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

 

metha

Август 1, 2011 в 11:26 дп

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

 

Calm

Август 1, 2011 в 3:02 пп

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

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

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

 

metha

Август 1, 2011 в 5:04 пп

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

 

metha

Август 1, 2011 в 5:06 пп

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

 

VirVit

Август 1, 2011 в 5:10 пп

На что ты повелся ?:)

 

metha

Август 1, 2011 в 5:19 пп

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

 

metha

Август 1, 2011 в 5:21 пп

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

 

Fudo

Июль 10, 2015 в 12:25 пп

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

 

Вы должны быть авторизованы, чтобы оставить комментарий.