Постановка задачи

Одной из неотъемлемых частей любой ECM-системы является управление бизнес-процессами, или workflow.

Бизнес-процессы в каждой отдельной организации имеют множество нюансов. Они постоянно изменяются вследствие изменений внутри организации, изменений законодательства и т.д. Поэтому дешевле и логичнее к разработке бизнес-процессов привлекать либо аналитиков, либо программистов, специализирующихся на бизнес-логике. А значит, создание и изменение бизнес-процессов должно быть максимально простым и удобным.

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

Это диктует некоторые требования, которые предъявлялись к движку бизнес-процессов:

• Процессы должны разрабатываться на основе высокоуровневых блоков. Примером такого блока может быть создание задания на согласование документа, старт подзадачи, выполнение произвольного куска кода и т.д.
• При изменении схемы процесса нужно обеспечить возможность конвертации уже запущенных процессов на новую версию схемы.

При разработке новой версии движка бизнес-процессов мы решили попробовать Windows Workflow Foundation (далее WF).

Разработчики хотят делать понятные и удобные программные продукты.
Но для нас и консоль, и горячие клавиши — вполне понятный и удобный интерфейс:

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

Раньше мы тестировали пользовательский интерфейс в процессе опытной эксплуатации (это когда новая версия устанавливается в нашей компании). У этого метода нашлись недостатки:

• Пользователям некогда оформлять замечания к продукту. Особенно если это касается удобства использования программы, а не функционала.
• Не понятно, насколько интуитивен интерфейс. Можно, конечно, проводить опросы, но они обычно малоинформативны.
• Замечания поступают слишком поздно. У разработчика остается меньше времени на их исправление.

Бороться с этими недостатками мы решили с помощью коридорного тестирования. Здесь мы хотим поделиться своим опытом.