Кстати, совсем забыла...
Была ещё идея сделать автоматические тесты на прикладой api. Т.е. тестировать методы относительно общие, используемые при реализации многих бизнес-процессов. А логику бизнес-процессов проверять вручную, полагаясь на то, что какая-то базовая часть уже протестирована автоматическими тестами. Но , опять -таки, к сожалению, прикладной api не совсем состоялся, т.к. методы довольно уникальные и могут быть использованы при реализации одного бизнес-процесса. Но даже это если бы это было не так, то все равно остается вопрос, если автоматические тесты проходят, то с какой долей уверенности можо утверждать, что работает алгоритм бизнес-процесса? И как распределить время на создание автоматических тестов и тестирование вручную, если его постоянно не хватает? :(

Разработкой автоматизированных тестов в данном случае буду заниматься я . А проект на самом деле очень большой и длительный. Особенно, если учесть то, что не так уж много народа занимается его реализацией, разработкой , проектированием и внедрением. В общем-то, нам не всегда приходится многократно выполнять одни и те же тесты. Фактически дело обстоит так: тест повторяется только лишь в том случае, когда, скажем, результат расчета индексации был неправильный и программист исправил это. Тест повторяется для того, чтобы убедиться в том, что алгоритм отработал верно. Ну, ещё это касается случаев с рефакторингом - для того, чтобы убедиться, что этот замечательный процесс не привел к полной неработоспособности всей системы :) . Рассматривая все ту же индексацию могу сказать, что тест заключается именно в проведении индексации для договора со специфическими характеристиками. Поэтому фактически надо 1 раз зарегистрировать договор, а индексацию для договора с этими признаками можно производить сколько угодно раз. Но чем больше система, тем сложнее этот процесс. Например, какой-нибудь бизнес-процесс, который базируется на результатах индексации. Ситуация будет повторяться: надо будет зарегистрировать договор, произвести индексацию, а потом многократно выполнять тесты. Использовать 1 договор (или несколько) для всех тестов (для тестов по всем бизнес-процессов) так же не всегда целесообразно, т.к. например в одном бизнес-процессе важны характеристики договора, в другом - характеристики прибора учета, в третьем - наличие и время связи между тем же прибором учета и его показаниями, а ещё может быть схема электроснабжения, дата выставления платежного документа и т.д.. В общем - создать один или несколько универсальных договоров для тестирования всего - лучше застрелиться, чем потом разбираться, откуда взялась цифра в индексации у договора с сотней точек учета и,приборами учета с разными характеристиками и т.д. :) . Но даже такой подход является работоспособным в некоторой мере.
Самая главная беда, что есть тенденция к изменению описания самого бизнес-процесса. Изменился бизнес процесс - изменился результат теста - беда :( Изменяются даже те бизнес-процессы, которые считаются реализованными, поэтому если один бизнес-процесс опирается на результаты другого, то изменение первого - это смерть тестовых данных, уже загнанных в систему :( Видимо, в этом и есть самая главная проблема.
Можно, конечно, динамическ формировать тестовые данные в ходе выполнения автоматического теста, но в таком случае автоматический тест должен будет реализовать несколько бизнес-процессо только для того, чтобы подготовить тестовые данные для теста :unsure:
Что-то я разошлась :D

Прошу поделиться соображениями и опытом...
При реализации прикладного проекта на основе готового продукта (скажем так, что готовый продукт - это достаточно универсальная среда разработки и проектирования бизнес-процессов) возникает необходимость тестирования реализованных прикладных алгоритмов, которые выполняют прикладные специфические для данного проекта действия. Понимаю, что это достаточно расплывчато... :unsure:
Более подробно - среда разработки позволяет без программирования сделать визуальную настройку системы, динамически формировать формы, отображать списки, сделать настройку рабочего пространства, возможность использования атрибутов различных типов (дата, текст и т.д...), выполнить настройку модели данных без программирования и "ковыряния" в БД, т.е. настроить связи между прикладными сущностями, их множественость и т.д.. Тем не менее, для реализации прикладного проекта этого не достаточно :( Необходимо написать ещё кучу всякой всячины, которая присуща только данному проекту, ну, например, специфические расчеты для той отрасли, в которой реализуется проект (расчет потребления электоэнергии потребителем, расчет индексации, регистрация показаний промышленных потребителей и т.д.), надо в соответствии с проектом присвоить наименования сущностям (объекты типа "договор", "потребитель", "прибор учета" и т.д.), настроить специфические связи (например, точка учета электроэнергии связана с прибором учета) и т.д.. То, что касается настроечной части можно подвергнуть очень поверхностному тестированию и в основном проверить на соответствие здравому смыслу. Кроме того, если уж там, что и обнаружится, то это исправляется без перепрограммирования, это не очень трудоемко и несложно. Кроме того, контроль того, что касается настройки выполняет само ядро... :rolleyes:
Совсем по-другому обстоят дела с тем, что пишется программистами именно для этого прикладного проекта :(
Вот тут-то я и прошу совета. Дело в том, что, например, для тестирования расчета индексации необходима просто куча данных, которые можно получить только реализовав какие-то другие сценарии (регистрация договора для того, чтобы в процессе индексации знать признаки, которые влияют на ее расчет; проведение расчетов и выставление по ним платежных докуметов, их оплата и т.д. для того, чтобы иметь предмет индексации). В общем, если количество тестовых ситуаций для расчета индексации было не очень большим, то можно было бы реализовать поочередно каждый сценарий и только потом проверить индексацию. Но это слишком долго, а вариатов индексирования/неиндексирования очень много :( Это только лишь индексация, а бизнес-процессов в реализуемом проекте просто куча. Как их тестировать..??? Руками? Долго и не очень эффективно. Писать автоматические тесты? Как их писать и не будет ли сложность тестов превышать сложность реализуемых алгоритмов? Посоветуйте что-нибудь, может, у кого-нибудь есть опыт в решении подобных проблем...