Смысл в том, что в системе разработок не всегда есть данные, на которых можно приличный тест провести.
Более-менее актуальные данные, скопированые с продуктива - в тестовой системе. Она по идее и служит для проведения полномасштабных тестов.
Если все создавать и тутже тестировать в системе разработок - то зачем вообще 3-ландшафтная система нужна.

тут уже полная непроходимость ...

4uva4ok
После пяти доработок в кволити на тебя начинают коситься, посли 10 могут спросить - а по пути ли тебе вместе с компанией дальше
Очень дисциплинирует, замечу.
И в разработках все тестируется.
И в кволити тестируется.
И потом список доработок согласовывается и оценивается, который отрабатывается за один раз и заново тестируется опять же пользователями, и ими же подтверждается или не подтверждается, что все работает ,как нужно.
Если пользователям отдать на тетсирование что-то совсем не то, что им нужно, то возникает два вопроса. Или ты темой совсем не владеешь, или пользователи не очень подготовлены.
Когда я тестирую что-то в разработках и у меня есть сомнения, я уточняю всегда у пользоввателей, которые обычно выделены на проект на 100%
И т.д. и т.п
Но да, думаю, для супер огромных проектов такая схема не совсем реальна. Возможно .есть что-то другое. Не берусь судить, потому что да, никогда не довелось работать на таких гигантах, как Газпром.
Какие-то у нас с вами разные представления / опыт, я смотрю
В общем, если голосовать за code review, то я полностью за Имея разные проекты и сравнивая, я могу утверждать, что с таким контролем и четкостью мне более эффективно и комфортно работать.

Если у Вас по-другому, то... как повезет.
Мне иногда не везет - иногда не хватает четкости, и контроля, и организованности

Я бы не стал квалификацию абапера/консультанта измерять количеством доработок. Очень много причин может быть - сложность разработки сама по себе, требующая поэтапного написания и тестирования, дополнительно возникающие требования от бизнеса, расхождение в понимании ТЗ и тд.

4uva4ok
Конечно. Разные ситуации бывают. У руководство это обычно понимает. И спрашивает ,что нужно сделать, чтобы все доработать. И т.д. И очень жестко все бывает.
Но с банковской выпиской, думаю, раз 10-20 гонять туда сюда мне бы вряд ли кто разрешил на текущем проекте просто так. Обычно в кволити все тестируешь и готовишь список доработок. СПИСОК. Никто не будет что-то одно ипсравлять и потом все по-новой делать
На текущем проекте есть одна супер программа, которую правили прямо уже... ну не знаю сколько раз. Ничего, все живы. Да, сложная программа.
И т.д. Все зависит от ситуации. Но, простите, когда есть тестовые данные нормальные, и список того ,что пользователи хотят исправить ,почему это не сделать за раз???

Сразу видно - допотопную рфебку мучаете на проектах

Вообще выписка - это только пример. Повторюсь, все зависит от ситуации. И очень сильно.
Но code review рулит!

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

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

А что по факту?
Консы забивают на тест - еще они будут напрягаться...
Есть кволити там юзеры данные вносят - на них и перекладывают.. Это ни фига не экономия - это тупая лень!
И желание чужими руками ... нахапать )))

А мне концепт с код ревью очень даже по душе! и работа с грамотным консом который свой хлеб отбивает на все 100% - милое дело!
Тогда все работает как часики...

А в биви ещё веселее - там нельзя сделать второй мандант по сути самого биви.
Так что предварительно тестируем в разработке (всё равно с теми же структурами нельзя сделать "маленькую тестовую структуру", особенно если ВБА завязан, а уж с ячейками тем более), а дальше уже Q - где и сами ещё раз тестируем, и заказчик смотрит. Ещё можно сделать 4х-системный ландшафт, но такой [s]гомосятины[/s]оригинальности я ещё не видела ни разу.
Зато видела, что люди делали 2х-системный ландшафт, разработка-продуктив. Заказчик тусил и в разработке обычно. Данные в разработку сливались из Q ЕРП. Или даже из продуктива, но ограниченно.

Anna Turunova, ну я и не против что 80-90% на любом проекте должно быть оттестировано, каким бы проект крупным или сложным не был и мы так же собираем список операций для интеграции модуля FI с FM, причем именно в введении одного общего списка с аналитиками обоих модулей чаще всего и проблема. Но практически с самого начала дискуссии я пытаюсь донести что подобрать оставшиеся 10-20% неучтенных операций в сложных и крупных проектах более реальнее на ОЭ/ОПЭ, привлекая при этом разработчика в командировку, а не взаимодействуя с ним на удаленке (что приводит к более медленному решению проблем), чем на Настройке и разработке разобрать все 100% операций.


В общем согласен качество всегда лучше когда до ОЭ все протестируешь, но на большом проекте это выливается в такие сроки, деньги, человеческие ресурсы, что на них даже Газпром не подпишется. Хотя я тоже был бы только двумя руками за то чтобы все операции протестировать до ОЭ/ОПЭ.
На небольшом проекте работал по удаленке с разработчиком, который живет сейчас в Вальдорфе (переехал когда то туда), очень хорошо взаимодействие прошло, но его уровень квалификации очень высокий. Сейчас коллегам приходится работать по удаленке с разработчиками К1/К2 доходит до того что данные тестового примера предоставленные в спеке, эти удаленные разработчики, выводят как результат работы программы и нужно письменно до них каждый глюк доводить и разжевывать - сидели бы рядом, тестили бы вместе и экономили кучу времени. Так вот квалифицированных разработчиков, с которыми на удаленке работать эффективно, даже просто в обычном режиме, процентов 20 и наберется от общего количества разработчиков. А что говорить об исправлениях которые нужно делать когда времени на порядок меньше? Для доработки разработок, которые возникают при выявлении 10-15% операций на ОЭ/ОПЭ считаю как раз привлечение разработчика очень критично для экономии времени на доработку, т.к. его на ОЭ/ОПЭ на устранение обнаруженной ситуации в разы меньше чем на Настройке и тестировании. Сейчас у нас идет этап перехода к запуску на нем конечно по максимуму разработки будем дорабатывать и по замечаниям, данным во время предварительных испытаний, и по тому что сами дообследовали, но на ОЭ/ОПЭ все равно какой то процент не выявленных операций наберется и будем брать с собой разработчиков и наши разработчики, как и РП не против.
В общем тоже не вижу больше смысла в продолжении дискуссии на эту тему. Все уже высказались и все точку зрения друг друга поняли, так что дальше только переливать из пустого в порожнее.

Да, конечно, в течение проекта всё еще сильно изменится. Однако смысл в ревью в самом начале проекта есть: он помогает согласовать стандарты программирования на проекте.
Практика показывает, что гораздо дешевле получается, если в первые дни проекта "главный босс по разработкам" от заказчика смотрит на творения абаперов и делится своими понятиями о прекрасном. Гораздо печальнее проведение аудита уже вылизанных программ перед самым подписанием актов и заключение "переделать структуру пакетов, переименовать большую часть объектов разработки, изменить стиль расширений, здесь пакетник заменить на бапи, а здесь используйте наш z-класс для логгирования и т.д.". По идее это все должно регулироваться регламентом, но в реальности он охватывает 10-20% (и разумеется каждый заказчик думает, что у него - самая лучшая документация). Так что предпочитаю ревью в начале и аудит в конце

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

а ерп тоже 4х-ландшафтным было? Или из теста ерп в оба теста бв?

Да вот, любопытно стало.
Тогда, в продолжение любопытства, а для чего именно задействованы?

Извиняюсь, не совсем внимательно читал, что вы с коллегами именно о бв говорили, я имел в виду ERP часть. BW 4х ландшафтного я сам не встречал.