개념
ERP 시험이 어려운 진짜 이유
ERP·그룹웨어 같은 기업 업무 소프트웨어를 처음 맡은 QA 가 공통적으로 겪는 일이 있다. 화면 수는 많지 않은데 케이스가 끝없이 늘어난다. 이유는 화면의 문제가 아니다. 한 버튼의 동작이 여러 조건의 조합으로 결정되기 때문 이다.
[전표 수정 버튼을 눌렀을 때 무슨 일이 일어나는가]
회계기간이 열려 있는가 / 전표의 승인 상태는 무엇인가 / 내가 작성자인가
내 권한 등급은 무엇인가 / 전표가 다른 문서를 참조하고 있는가
결산 진행 중인가 / 회계연도가 넘어갔는가조건 7개가 각각 2~4개 값을 가지면 조합은 수백 개다. 화면 하나에 대해서다. 이것을 케이스로 나열하면 관리할 수 없고, "주요한 것만" 골라 쓰면 무엇을 뺐는지 설명할 수 없다. 그래서 이 도메인에서는 결정표(decision table) 가 선택이 아니라 기본 도구다.
기법 자체는 레슨 s1-m03-l03 에서 다뤘다. 이 레슨은 그 기법을 ERP 의 세 가지 단골 규칙 — 마감, 전표 승인, 권한 분리 — 에 적용하는 절차 와, 결정표로 풀리지 않는 부분 (시간·구조 변경의 회귀)을 다룬다.
결정표로 옮기는 절차
업무 규칙은 처음부터 표로 오지 않는다. 사규·회계 규정·담당자의 말로 온다. 그것을 표로 옮기는 순서는 이렇다.
1. 규칙 문장을 모은다 규정 문서 + 담당자 인터뷰 + 기존 시스템 동작
2. 조건과 결과를 분리한다 "~인 경우"는 조건, "~한다/~할 수 없다"는 결과
3. 조건의 값 범위를 확정한다 참/거짓인가, 열거형인가, 구간인가
4. 표를 채운다 조건 조합 × 결과
5. 빈칸을 찾는다 규정에 없는 조합 = 담당자에게 물어야 할 질문
6. 모순을 찾는다 같은 조합에 다른 결과 = 규정끼리 충돌
7. 규칙을 병합한다 결과가 같고 조건 하나만 다른 행 → 그 조건은 무관
8. 케이스로 전개한다 병합 후 남은 행 = 최소 케이스 집합5번과 6번이 이 작업의 진짜 산출물이다. 케이스를 얻는 것보다, 규정에 없는 조합과 규정끼리 충돌하는 지점을 찾아내는 쪽이 값이 크다. 그것은 개발이 시작되기 전에 나와야 하는 질문이고, ERP 구축 사업에서 가장 비싼 결함이 정확히 거기서 나온다.
7번의 병합은 케이스 수를 줄이는 장치다. 표를 다 채운 뒤 결과가 같은 행들을 모아 "이 조건은 이 결과에 영향을 주지 않는다"를 확인하면, 그 조건은 해당 구간에서 무관 처리(-)할 수 있다.
수백 행이 수십 행으로 줄어들고, 줄어든 근거가 표에 남는다. 검수에서 "왜 이 조합은 시험하지 않았는가"를 물으면 표를 보여 주면 된다.
마감 — 세 개의 날짜를 구분한다
마감은 ERP 시험에서 가장 자주 틀리는 영역이고, 틀리는 이유는 대개 하나다. 날짜가 하나가 아닌데 하나로 생각하기 때문 이다. 최소한 셋을 구분해야 한다.
| 날짜 | 무엇인가 | 시험에서의 의미 |
|---|---|---|
| 회계일(전표일자·귀속일) | 이 거래가 어느 기간에 귀속되는가 | 마감 판정의 기준. 사용자가 입력한다 |
| 입력일(등록일시) | 시스템에 언제 기록되었는가 | 마감 후 소급 입력 탐지의 근거 |
| 시스템일(서버 현재 시각) | 지금 몇 시인가 | 마감 시각 도달 판정, 배치 실행 기준 |
이 셋이 어긋나는 조합이 결함의 서식지다. 회계일은 열린 기간이지만 시스템일이 마감 시각을 지난 경우, 회계일은 닫힌 기간인데 입력일이 마감 전인 경우(마감 직전에 임시 저장해 둔 전표), 회계일이 직전 회계연도인 경우 — 전부 따로 시험해야 하는 상황이다. 화면에서 날짜 하나만 바꿔 가며 시험하면 이 조합들이 통째로 빠진다.
마감 경계값은 다음 축으로 설계한다.
[회계일 축] 마감 기간 직전 마지막 날 / 마감 기간 첫날 / 마지막 날 / 다음 기간 첫날
회계연도 마지막 날 / 다음 회계연도 첫날
[시각 축] 마감 시각 1분 전 / 정각 / 1분 후 (마감이 시각 단위로 걸릴 때)
[상태 축] 가마감(임시) / 본마감 / 마감 해제 후 / 결산 확정 후
[행위 축] 신규 등록 / 수정 / 삭제 / 승인 / 승인 취소 / 조회·출력상태 축의 "마감 해제 후"가 자주 빠진다. 마감은 되돌릴 수 있는 기관이 많고, 되돌린 뒤의 동작이 원래 열린 기간과 같은지 다른지는 규정에 따라 다르다. 해제 권한자, 해제 이력 기록, 해제 후 입력된 전표의 식별 가능성까지 시험 대상이다.
또 하나 놓치기 쉬운 것이 마감이 걸리는 대상의 범위 다. 전표 입력만 막히는지, 그 전표를 참조하는 다른 업무(지급·정산·보고서 재집계)도 같이 막히는지가 시스템마다 다르다. 마감 상태에서 업무 흐름 전체를 한 번 통과시켜 보는 시나리오 를 반드시 넣는다.
전표 승인 단계 — 상태와 권한이 곱해진다
전표는 결재선을 따라 상태가 바뀐다. 상태 전이 자체는 상태 전이 시험(레슨 s1-m03-l03)으로 다루고, 여기서는 상태 × 권한 × 기간 의 곱을 결정표로 다룬다.
| 조건 | 값 |
|---|---|
| 전표 상태 | 임시저장 / 결재요청 / 부분승인 / 최종승인 / 반려 / 취소 |
| 행위자 | 작성자 / 중간 승인자 / 최종 승인자 / 제3자(같은 부서) / 제3자(다른 부서) / 관리자 |
| 회계기간 | 열림 / 가마감 / 본마감 |
| 행위 | 수정 / 삭제 / 승인 / 반려 / 회수 / 조회 |
6 × 6 × 3 × 6 = 648 조합이다. 여기서 결정표의 병합이 힘을 발휘한다. 실제로는 이런 식으로 묶인다.
· 본마감 상태에서는 행위자·전표 상태와 무관하게 조회만 가능
→ 6 × 6 × 1 × 6 = 216 조합이 한 행으로
· 최종승인 이후의 수정·삭제는 행위자와 무관하게 불가 (취소 후 재작성만)
→ 다시 큰 덩어리가 한 행으로
· 반려 상태의 전표는 작성자만 수정 가능
· 회수는 "결재요청 상태이고 아직 아무도 승인하지 않은 경우"에만병합 후 남는 행은 대개 20~40개다. 648 → 30 은 감이 아니라 표로 증명된 축소 이고, 이 표가 그대로 케이스 목록이 된다.
표를 만들다 보면 규정에 답이 없는 칸이 반드시 나온다. 예를 들어 "부분승인 상태에서 작성자가 회수하면 이미 승인한 중간 승인자의 승인은 어떻게 되는가", "가마감 상태에서 결재 진행 중인 전표는 마감 대상인가". 이런 칸이 담당자에게 가져가야 할 질문 목록 이고, 대부분 개발도 정하지 못한 채로 두었던 부분이다.
권한 분리와 조합 폭발 줄이기
권한 분리(SoD, Segregation of Duties) 는 한 사람이 거래를 만들고 스스로 승인하지 못하게 하는 통제다. ERP 에서는 전표 작성과 승인, 지급 요청과 지급 실행, 마스터 데이터 변경과 거래 입력 같은 쌍이 대표적이다. 이 통제를 시험하려면 "같은 사람이 두 역할을 동시에 가질 수 있는가"와 "가졌다면 시스템이 막는가"를 나눠 봐야 한다.
[권한 분리 시험의 두 층]
1. 부여 단계 금지된 역할 조합을 한 계정에 부여하려 할 때 경고·차단되는가
이미 부여된 계정을 탐지하는 점검 기능이 있는가
2. 실행 단계 부여돼 있더라도 자기가 만든 전표를 자기가 승인하는 행위가 막히는가
대결(위임) 설정을 통해 우회되지 않는가2번의 마지막 줄이 실전에서 가장 자주 뚫리는 지점이다. 직접 승인은 막혀 있는데 위임 설정을 자신에게 걸면 통과되는 경우가 드물지 않다.
권한 조합은 폭발하기 쉽다. 역할 20개, 조직 계층 4단계, 업무 유형 10개면 나열이 불가능하다. 줄이는 방법은 세 가지다.
첫째, 역할을 등급으로 묶는다. 개별 역할이 아니라 "판정에 영향을 주는 속성"으로 추상화한다. 전표 수정 권한 판정에 실제로 쓰이는 속성이 (작성자 여부, 결재선 포함 여부, 관리자 여부, 소속 조직 일치 여부) 넷뿐이라면, 역할 20개가 아니라 속성 4개의 조합만 보면 된다. 이 추상화가 맞는지는 개발 담당자와 확인해야 한다 — 코드가 실제로 무엇을 보고 판정하는지가 근거다.
둘째, 조합 기법을 쓴다. 속성이 여러 개이고 상호작용이 2개 조합 수준에서 대부분 드러난다면 페어와이즈(레슨 s1-m03-l05)로 케이스를 줄인다. 다만 권한은 리스크가 큰 영역이므로, 금지 조합(반드시 막혀야 하는 조합)은 페어와이즈에 맡기지 말고 전수로 넣는다. 허용 쪽은 줄이고 금지 쪽은 줄이지 않는 것이 원칙이다.
셋째, 부정 케이스를 우선한다. 권한 시험에서 값이 큰 것은 "권한이 있는 사람이 할 수 있다"가 아니라 "권한이 없는 사람이 할 수 없다" 다. 후자는 화면에서 버튼을 숨기는 것으로 충족되지 않는다. 버튼을 숨겼더라도 요청을 직접 보내면 서버가 막는지 확인해야 한다. 이 확인이 빠진 권한 시험은 검수에서 통과해도 운영에서 사고가 난다.
시간과 구조가 바뀌는 사건 — 회귀의 진짜 대상
ERP 에는 기능 변경이 없어도 동작이 달라지는 순간이 있다. 회계연도 전환 과 조직개편 이다. 둘 다 연 1회 수준으로 드물게 일어나서 시험이 거의 되지 않고, 일어나면 광범위하게 깨진다.
회계연도 전환. 이월 처리(잔액·미결 전표·예산), 전기 조회, 연도 표기, 채번 규칙(연도가 들어간 전표번호의 초기화), 회계연도를 넘나드는 조회·보고서, 그리고 전년도 마감 이후의 수정 요청 처리 경로가 대상이다. 시험 방법은 하나뿐이다 — 시스템 일자를 이동시킨 시험 환경에서 실제로 전환을 수행해 본다. 이것이 가능한 환경을 미리 준비해 두는 것이 이 항목의 핵심이고, 준비는 레슨 5 의 시험 환경 구성에서 다룬다.
조직개편. 부서 신설·폐지·통합·분할, 소속 이동, 상위 조직 변경이 일어난다. 영향이 나타나는 곳은 결재선(폐지된 부서를 경유하는 결재선), 권한(이동한 사용자의 기존 권한 잔존), 과거 데이터 조회(그때의 조직으로 보이는가 지금의 조직으로 보이는가), 집계·보고서(조직 기준 합계의 기간 비교), 그리고 진행 중 문서다.
[조직개편 회귀 — 최소 시험 집합]
1. 개편 시점에 결재 진행 중이던 문서가 계속 흘러가는가
2. 폐지된 부서를 결재선에 포함한 신규 문서 작성이 막히는가
3. 이동한 사용자의 이전 부서 권한이 회수되는가
4. 개편 전 기간의 보고서가 개편 전 조직 기준으로 조회되는가 (또는 규정대로 재편성되는가)
5. 조직 기준 집계의 전기 대비 비교가 성립하는가
6. 사용자 소속 변경 이력이 남아 과거 문서의 작성 부서를 판정할 수 있는가4번과 5번은 규정을 먼저 확인해야 판정할 수 있다. 과거 데이터를 그때의 조직으로 볼 것인지 현재 조직으로 재편성해 볼 것인지는 기관 정책이고, 둘 다 "맞는" 답이다. QA 가 판정 기준 없이 시험하면 정상 동작을 결함으로 올리게 된다.
실무에서 왜 필요한가
ERP 구축·고도화 사업에서 QA 의 가치가 가장 크게 드러나는 시점은 시험 실행이 아니라 요구사항 정제 단계 다. 결정표를 그려 빈칸과 모순을 찾아내면, 그 질문들이 설계 확정 전에 처리된다. 같은 질문이 통합 시험에서 나오면 이미 만들어진 로직을 고쳐야 하고, 운영 후에 나오면 데이터를 고쳐야 한다. 비용 차이가 자릿수 단위다.
케이스 수를 설명할 수 있다는 점도 실무적이다. 공공·대기업 사업에서는 "몇 건을 시험했는가"와 "왜 그만큼인가"를 둘 다 요구받는다. 결정표 기반으로 병합해 얻은 케이스 집합은 축소의 근거가 표에 남아 있어서 그대로 설명이 된다. 감으로 고른 케이스 목록은 그 질문에 답하지 못한다.
마지막으로 마감과 조직개편은 운영 사고의 단골 이다. 구축 사업의 시험 범위에서 빠지기 쉬운데, 빠지면 첫 결산이나 첫 인사 발령 때 터진다. 그 시점에는 이미 사업이 끝나 하자 판정 논쟁이 따라붙는다(모듈 56 레슨 3). 구축 단계에서 시험 환경과 함께 이 항목들을 계획에 박아 두는 것이 가장 싸다.