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

Какой составляете план тестирования, если составляете. Т.е. насколько детально, есть ли чек листы.

На какую теорию опираетесь

В данном случае интересно именно тестирование функционала (не нагрузочное и т.д.)

(0) контрольный список - от 10 до 100 шагов + эталонный отчет

теории одна - что написано в ТЗ, то и должно быть

(0) если в ТЗ не описан порядок приемочных испытаний, то тестируется в соответствии с требованиями к функционалу, описанным в ТЗ. Это для внутренней разработки.
Подписываться на ТЗ без порядка приемочных испытаний для внешнего заказчика - это плата за науку о том, что так делать нельзя.

хотя даже для внутренней разработки отсутствие сценария тестирования - это гарантия затяжного периода тестим-правим-тестим-правим после окончания всех китайских последних дэдлайнов...

А регрессионное тестирование кто проводит?

Тестирую с помощью юнит-тестов, они часто и в интеграционные тесты переходят, но так хоть иногда можно вовремя поймать регрессию.

еще рекомендую к вдумчивому куреню ГОСТ 34.603 "ВИДЫ ИСПЫТАНИЙ
АВТОМАТИЗИРОВАННЫХ СИСТЕМ". Должно натолкнуть на правильный ход мыслей

(4) расскажите, как вы пишете юнит-тесты на 1С?
мы делаем регрессию руками, точнее - руками тестировщика

(6) xUnitFor1C, пишу тесты внешними обработками, позволяет запускать тесты 8.3. Результаты тестов выгружаются xunit.xml формат, который уже дальше с помощью jenkins интерпретируется в красивые графики и прочую лабуду - типа отсылка по почте результатов, пинки отвественных.

(5) используете ГОСТ этот?

(7) А что у вас тестируется юнит-тестом? можете привести примеры?

(9) Экспортные процедуры.
Создание, проведение документов.
Проверка правильности заполнения реквизитов и т.д.
На че фантазии хватит то и проверяю.

Не проверяю как вывелся отчет и правильная ли там цифра по сравнению с прошлым кваратлом (разве что только открытие формы отчета и успешное формирование).

http://www.slideshare.net/AlexeyLustin/behave-onec-1-agile где-то 11 слайд, там как это уже в результате выглядит.

(10) ну т.е. это достаточно высокоуровневые процедуры?
наверное, это ближе к smoke-тестам?

(11) я бы сказал ближе к интеграционным. Тем более когда у тебя 10% доработок, а на остальное типовое решение, фиг напишешь тесты.
Если, ставишь целью модификацию конфигурации, то можно и тесты в конфигурацию впихнуть, но стоит ли овчинка выделки?

Опять таки, чем smocke отличаются от полных тестов, если unit тесты не писать полностью, тем более что все равно проверяешь частные случаи, это все варианты легко расписать когда "а+b=c".
И такая простая метрика "покрытие кода тестами", если у меня на весь добавленный код, будут написаны тесты и этот код будет покрыт тестами - это ведь лучше, чем вообще ничего.

(12) ок, понятно.
у меня на проекте обратная ситуация: есть свой не очень большой код, который запускается у достаточно большого количества клиентов в очень разных контекстах. Поэтому мы как раз пытаемся начать писать юнит-тесты в классическом понимании.

(13) mock реализовать в 1С вряд-ли получится.
Ну а что в принципе мешает объявить в модуле тестовые методы и уже по тестировать?