Кто нить при разработке проводит тестирование всей конфы на появление регресс ошибок? И как оно выглядит/должно выглядеть в среде 1С? чо то часто у меня они стали появляться...

Что это: http://ru.wikipedia.org/wiki/Регрессионное_тестирование

Пока лень и многие моменты тестирования неясны...

нужно меньше костылей делать - тогда они реже вываливаться будут

(1)

(2) обычно валится не на костылях (если их и делаю, то максимально аккуратно с возможностью тут же удалить при более подходящем решении), а на изменении функционала под новые требования

это ж надо юнит-тесты писать по всему функционалу и гонять без конца... К 1С такие цацки прикручиваются через ж. и затраты велики. Может не окупиться.

Моя прога в которой веду проект позволяет автоматом создавать список тестов (по связанным с программными объектами вариантами использования) на основании проведенных работ за заданный период. Тестирование, правда, в настоящий момент ведется ручками.

Так то сценарное тестирование есть, но пока создашь один тест постареть можно...

все ясно с тестированием...

Используем в ограниченном объёме (только ключевые процессы, без которых бизнес остановится).
Технология - "Сценарное тестирование"+самописные тесты для специфических механизмов.

(11) и часто приходится править существующие сценарии? и вообще они быстро пишутся, если разобраться как следует?

(12) Нет, нечасто. Это ж ключевые процессы (заказ, отгрузка), там изменения в самом порядке выполнения действия не часто происходят.

(0) почему именно регрессионное? чем оно с технической т/з отличается от, скажем, модульного тестирования?

Давно хотел, даже создал аналогичную ветку когда-то: v8: v8: Экстремальное программирование и 1С. И хочется и колется...
мне там сказали: делай!

(8) мнэ... а можно увидеть примерчик такого списка тестов?

(15) и как успехи?

(14) можно сказать это проведение всех модульных тестов, которые когда либо были написаны для системы

(14) оно отличается идеологически - тестировать надо не точечно (то, что дорабатывалось/менялось), а всё подряд, причём часто.

И, в отличие от модульного тестирования, здесь обычно тестируется программа в целом, как "чёрный ящик".

(15) Бека вот тоже дочитываю =) сначала думал как бы недопускать регресс-ошибок, а вот теперь думаю в сторону как это все лучше быстро протестить

(20) ну вот, к этому и было (14)...

(14) + особенно применительно к учётным системам - надо проверять именно суммарный результат работы всех механизмов по-отдельности. А то получится, что каждый документ создаёт правильные движения, отчёт тоже работает правильно (по данным регистров), а вместе получается ерунда - потому что каких-то документов/обработок просто нет.