워크플로우 예시
#

비지니스 로직 예시
#

워크플로우 예제를 만들기 위한 비지니스 로직 예시를 들어보겠습니다.

A사는 문서결재 업무를 워크플로우 기능을 이용해 구성하고 업무를 자동화하려 합니다.

A사의 문서결재 업무는 다음과 같은 조건이 충족되어야합니다.

문서는 작업중, 결재중, 승인됨, 재작업 의 상태를 가질 수 있습니다.
문서 결재가 모두 승인되면 문서는 승인됨 상태가 됩니다.
문서 결재가 진행중일 때 문서는 결재중 상태가 됩니다.
문서는 결재가 진행되기 전에는 작업중 상태입니다.
문서 결재가 반려되면 문서는 재작업을 통해 다시 문서 결재를 시작해야한다. 이 경우 상신자에게 재작업 임무가 주어지며 해당 재작업 임무를 완료하면 문서 결재가 다시 시작된다. 상신자에게 재작업 임무가 떨어질 때부터 재작업 임무를 완료하기 전까지 문서는 재작업 상태입니다.
문서 결재는 총 2개 단계의 승인자를 거쳐야하며 1단계는 매니저, 2단계는 최종 승인자로 구성되어있습니다.
문서 결재가 시작되면 1단계 승인, 2단계 승인을 거쳐 모든 단계에서 통과하면 문서 결재가 성공적으로 종료되며 승인됨 상태가 됩니다.
문서 결재를 올리는 상신자는 1단계 및 2단계에 어떤 승인자에게 문서를 결재받을것인지 직접 지정합니다.
문서 결재는 1단계 승인 진행 후 2단계 승인이 진행되는 선형적 방식으로 이루어집니다.
1단계의 매니저로부터 문서결재를 승인받지 못하면 해당 문서는 2단계인 최종 승인자에게 도달하지 못합니다.
1단계에 해당하는 매니저는 여러명이 될 수 있으며, 여러 매니저에게 승인을 받아야하는경우 모든 매니저에게 승인을 받아야 1단계 승인단계를 통과할 수 있습니다. 한사람의 매니저라도 해당 결재를 반려하면 1단계 승인을 받을 수 없습니다.
2단계에 해당하는 최종 승인자는 여러명이 될 수 있으며, 모든 최종 승인자에게 승인을 받아야 2단계 승인이 통과하고 문서 결재가 최종 승인되게 됩니다.
간단한 문서의 경우 2단계 승인자를 지정하지 않아도 되는 경우가 있습니다. 이 경우 1단계 승인자에 지정한 매니저에게만 승인받으면 문서 결재가 최종 승인됩니다.
모든 결재 프로세스에서 1단계 승인자에 할당된 매니저가 최소 한명 이상이 있다고 가정합니다.

워크플로우 작성 예시
#

위의 비지니스 로직 예시와 같이 문서 결재 시 고려해야하는 사항들을 글로 적으면 단계가 매우 복잡해 보입니다. 해당 비지니스를 순수 개발로 작성하고자 한다면 그 복잡도와 분량은 이루 말할 수 없을 것이며, 향후 수정, 개선내용이 있을 때 유지보수 측면에서 부담스러운 결과가 생길 수 있습니다.

워크플로우 기능은 복잡한 비지니스 로직을 순서도로 정리하여 복잡한 업무 프로세스를 쪼개어 관리할 수 있으며 업무 흐름을 직관적으로 만들어 기능의 변경, 순서의 변경 등이 있는 경우에도 편리하게 접근할 수 있습니다.

위의 비지니스 로직을 워크플로우 기능으로 만들어보겠습니다.

위의 그림은 위에서 예시로 설명된 비지니스 로직에서 충족되어야하는 모든 조건이 만족하는 간단한 워크플로우 입니다.

이와같이 워크플로우로 비지니스 로직을 구현했을 때 직관성이 향상되고 이해하기 편한 것을 알 수 있습니다.

하지만 해당 워크플로우의 동작을 검증하고자 할 때 모든 경로가 오류없이 정상적으로 돌아가는지 판단하기 위해서는 해당 워크플로우의 모든 경우의 수의 테스트 가 수행되어야 할 것입니다. 이 경우 육안으로 테스터가 모든 경우의 수를 정리하기에는 정확도 및 효율성 측면에서 많은 고민이 될 것입니다.

이를 해결하기 위해 다음 포스팅에서는 이번 포스팅에서 만든 워크플로우를 토대로 깊이 우선 탐색(DFS)를 적용하여 워크플로우의 테스트 케이스를 추출해보도록 하겠습니다.

워크플로우(순서도) 테스트케이스 추출 시도 - 이 글은 시리즈의 일부입니다.

부분 1: 워크플로우(순서도) 테스트케이스 추출 시도(1) - 깊이 우선 탐색(DFS, Depth-First Search) 알고리즘

부분 2: 이 글

부분 3: 워크플로우(순서도) 테스트케이스 추출 시도(3) - 깊이 우선 탐색(DFS, Depth-First Search) 알고리즘적용 예제2