테스트 프로세스 개요 — 세 계층 프로세스, 활동별 산출물, 테스트 환경·데이터 준비

개념

왜 프로세스인가

앞 레슨들이 "어떻게 테스트하나"를 다뤘다면, 이 레슨부터는 "어떤 순서로, 무엇을 남기며 테스트하나"를 다룬다. 가이드는 프로세스가 필요한 이유를 네 가지로 든다.

• 선택이 많다. 명세 기반으로 할지 구조 기반으로 할지, 컴포넌트 테스트를 어떤 기준으로 끝내고 통합 테스트로 넘어갈지 결정해야 한다.
• 비용이 크다. 시스템 규모와 유형에 따라 다르지만 전체 개발 비용의 대략 30%~50% 를 테스트가 차지한다. 주어진 시간과 비용 안에서 효과를 내려면 체계가 필요하다.
• 평가해야 한다. 테스트에 든 비용과 그로써 얻은 품질 개선을 측정해, 테스트가 효과적이고 효율적이었는지 판단해야 한다.
• 개선해야 한다. 평가에서 찾은 미비점으로 다음 테스트를 더 낫게 만든다.

PPT식으로 줄이면 효율성 향상, 일관성 확보, 비용·일정 관리, 지속적 개선 이다.

세 계층 프로세스

ISO/IEC/IEEE 29119는 테스트 프로세스를 세 계층으로 나눈다. 위에서 아래로 갈수록 범위가 좁아지고 구체적이 된다.

┌ 조직 테스트 프로세스 ─────────────────────────────────────────┐
│  조직 테스트 명세 개발 → 활용 모니터링 및 제어 → 명세 갱신     │
└───────────────────────────────────────────────────────────────┘
        ▼ (정책·전략을 내려준다)
┌ 테스트 관리 프로세스 ─────────────────────────────────────────┐
│  테스트 계획  →  테스트 모니터링 및 제어  →  테스트 종료       │
└───────────────────────────────────────────────────────────────┘
        ▼ 테스트 활동 제어            ▲ 테스트 측정 / 메트릭
┌ 동적 테스트 프로세스 ─────────────────────────────────────────┐
│  테스트 설계 및 구현 · 테스트 환경 구축 및 관리                 │
│  테스트 실행 · 결함 보고                                       │
└───────────────────────────────────────────────────────────────┘

동적 테스트 프로세스의 네 활동과 산출물은 시험에 가장 자주 나오는 표다.

외우는 요령이 있다. 설계 및 구현은 "명세서"(앞으로 할 일을 정한다), 환경 구축은 "준비 보고서"(정한 대로 준비됐는지 알린다), 실행은 "로그"(한 일을 시간순으로 적는다), 결함 보고는 "보고서" 다. 이름의 꼬리만 보고도 어느 활동의 산출물인지 맞힐 수 있다.

두 화살표의 방향 — 정오표 항목

관리 프로세스와 동적 프로세스 사이의 화살표는 방향이 정해져 있다.

• 관리 → 동적 (아래로): 테스트 활동 제어. 관리자가 계획과 다르면 조치를 내린다.
• 동적 → 관리 (위로): 테스트 측정 / 메트릭. 실행 현장에서 숫자가 올라와 모니터링에 쓰인다.

옛 판 그림(11장 그림 11.19)에서는 이 두 라벨이 거꾸로 붙어 있었고, 정오표에서 위처럼 바로잡혔다. 논리로 생각하면 헷갈리지 않는다. 숫자는 일하는 곳에서 관리하는 곳으로 올라가고, 지시는 관리하는 곳에서 일하는 곳으로 내려간다.

동적 테스트 프로세스 안의 흐름

테스트 설계 및 구현
   ├─ 테스트 케이스·절차 명세서 ─────────────→ 테스트 실행 → 실행 로그 → 결함 보고
   └─ 테스트 환경·데이터 요건 명세서 → 테스트 환경 구축 및 관리 ──┘
                                        (준비 보고서)

설계 및 구현 활동이 두 갈래의 입력을 만든다. 케이스·절차는 실행으로, 환경·데이터 요건은 환경 구축으로 간다. 환경 구축이 끝나야 실행을 할 수 있다. 기본등급 범위에서 "테스트 설계 및 구현" 활동 자체는 일반등급 범위지만, 그 산출물 이름과 구성 항목 은 실행 활동의 입력이라 함께 알아 둔다.

설계 및 구현 산출물의 구성 항목

케이스 명세서의 식별자는 절차 명세서에서 케이스를 가리킬 때 쓰인다. 환경과 데이터의 식별자는 설계 명세서와 케이스 명세서에서 구체적인 환경·데이터를 가리킬 때 쓰인다. 이 연결이 끊기지 않아야 나중에 결함 보고서에서 "어느 케이스, 어느 절차, 어느 환경에서"를 정확히 적을 수 있다.

테스트 환경 구축 및 관리

이 활동의 목표는 주어진 요건대로 환경을 만들고 데이터를 준비해 테스트 실행을 지원하는 것 이다. 두 작업으로 이루어진다.

두 보고서의 구성은 같은 모양이다. 요약 (전체가 준비됐는지, 완료까지 얼마나 걸릴지)과 항목별 준비 상태 (요건을 충족했는지, 부족하면 원인·해결 방법·예정 완료 일자)다.

테스트 데이터 준비 에서는 요건을 만족하는 데이터를 확보한다. 같은 영상을 10K·20K· 30K 크기로 준비하라는 요건이 있으면 그대로 만든다. 데이터의 위치와 접근 방법 도 요건대로 맞춘다 — 파일이라면 정해진 위치에 정해진 접근 권한으로 둔다. 준비된 데이터가 요건을 충족하는지 검토하고, 크고 복잡한 데이터라면 자동 생성 도구나 자동 검증 도구를 쓸 수 있다.

테스트 환경 구축 에서는 요건에 명시된 규격의 하드웨어, 정해진 버전의 시스템 SW와 공존 SW, 외부 연동 시스템(또는 시뮬레이터), 테스트 도구를 준비한다. 시뮬레이터를 쓴다면 실제 연동 시스템과 비슷하게 동작하도록 설정하고, 이때 준비된 테스트 데이터가 쓰일 수 있다. 성능·신뢰성 테스트처럼 도구가 만든 데이터가 대상의 동작에 영향을 주는 경우 에는 데이터 요건을 만족하도록 도구를 설정한다. 구축이 끝나면 요건 충족 여부를 범용 도구나 자체 검증 프로그램으로 확인한다.

레벨별 테스트 환경 — 무엇이 실물이고 무엇이 대역인가

레벨이 올라갈수록 환경은 실제 운영에 가까워진다.

환경과 운영의 차이가 클수록 테스트에서 통과한 케이스가 운영에서 실패할 가능성이 커진다는 1장의 원칙이 여기서 실무 지침이 된다.

실무에서 왜 필요한가

신입이 처음 받는 일이 "테스트 환경 세팅"인 경우가 많은데, 이 일이 프로세스 안에서 독립된 활동이고 준비 보고서라는 산출물 이 있다는 것을 아는 사람은 드물다. "서버는 준비됐는데 결제 테스트 계정은 내일 나온다"는 상황을 메신저로만 공유하면 사라지지만, 데이터 준비 보고서의 "항목별 준비 상태"에 원인과 예정 일자로 남기면 테스트 일정 지연의 근거가 된다. 테스트 실행이 늦어졌을 때 "환경이 늦게 준비되었다"는 말을 문서로 증명할 수 있어야 한다.

데이터 요건의 초기화 필요 여부 와 보관 필요 여부 항목도 실무적이다. 매 실행 전에 원래 상태로 되돌려야 하는 데이터(재고 수량 같은 것)인지, 실행 후에도 결함 분석을 위해 남겨 둬야 하는 데이터인지를 미리 정해 두지 않으면, 결함이 났는데 그때의 데이터가 이미 덮어써져 재현할 수 없는 일이 생긴다.

세 계층 구조는 조직이 커질 때 쓸모가 있다. 프로젝트마다 계획서 양식과 종료 기준이 제각각이면, 그것을 조직 차원의 전략 명세로 끌어올려 공통화하는 것이 조직 테스트 프로세스의 일이다.

채용시장에서의 위치

국내 공공·금융 사업의 제안요청서(RFP)와 감리 체크리스트에는 테스트 산출물 목록이 거의 29119·IEEE 829 계열 이름으로 적혀 있다. 테스트 엔지니어로 투입되면 이 이름의 문서를 실제로 써서 내야 한다. 신입 면접에서 "테스트 산출물에 무엇이 있나요?"라는 질문을 받으면, 활동별로 묶어 "설계 및 구현에서는 명세서 다섯 개, 환경 구축에서는 준비 보고서 두 개, 실행에서는 실행 로그, 결함 보고에서는 결함 보고서와 추적 보고서"라고 구조적으로 답하면 준비된 사람으로 보인다.

실습 과제

과제 1 — 산출물 짝 맞추기

다음 산출물이 어느 프로세스의 어느 활동에서 나오는지 적는다.

1. 테스트 데이터 준비 보고서
2. 조직 테스트 전략 명세서
3. 테스트 실행 로그
4. 테스트 현황 보고서
5. 테스트 환경 요건 명세서
6. 결함 추적 보고서

과제 2 — 데이터 준비 보고서 써 보기

로그인 기능 시스템 테스트를 위해 다음 데이터가 필요하다고 하자. 정상 계정 10개, 잠긴 계정 2개, 비밀번호 만료 계정 1개. 그중 비밀번호 만료 계정은 인증 서버 설정 문제로 아직 못 만들었다. "요약"과 "항목별 준비 상태"로 데이터 준비 보고서를 다섯 줄 안팎으로 써 본다. 미준비 항목에는 원인·해결 방법·예정 일자를 넣는다.

과제 3 — 연습 문제 (4지선다)

1. 29119의 테스트 프로세스 중 특정 프로젝트가 아닌 조직 전체에 적용되는 명세서를 개발·관리하는 것은? ① 조직 테스트 프로세스 ② 테스트 관리 프로세스 ③ 동적 테스트 프로세스 ④ 테스트 종료 프로세스
2. 테스트 환경 구축 및 관리 활동의 산출물은? ① 테스트 환경 요건 명세서 ② 테스트 환경 준비 보고서 ③ 테스트 실행 로그 ④ 테스트 계획서
3. 테스트 관리 프로세스와 동적 테스트 프로세스의 관계로 옳은 것은? ① 동적 프로세스가 관리 프로세스에 활동 제어를 보낸다 ② 관리 프로세스가 동적 프로세스에 메트릭을 보낸다 ③ 관리 프로세스가 동적 프로세스의 활동을 제어하고, 동적 프로세스에서 측정·메트릭이 올라온다 ④ 둘은 서로 정보를 주고받지 않는다
4. 테스트 데이터 요건 명세서의 구성 항목이 아닌 것은? ① 초기화 필요 여부 ② 보관 필요 여부 ③ 담당자 ④ 결함 심각도

자가 체크리스트

• 테스트 프로세스가 필요한 이유를 셋 이상 말하고, 테스트가 개발 비용의 약 30~50%를 차지한다는 점을 안다
• 조직·관리·동적 세 계층의 범위와 하는 일을 구분할 수 있다
• 조직 테스트 명세서가 정책 명세서와 전략 명세서로 나뉜다는 것을 안다
• 관리 프로세스의 세 활동과 각 산출물(계획서·현황 보고서·종료 보고서)을 말할 수 있다
• 동적 프로세스의 네 활동과 산출물 열 개를 짝지을 수 있다
• 관리 → 동적은 활동 제어, 동적 → 관리는 측정·메트릭이라는 방향을 안다
• 테스트 케이스 명세서와 절차 명세서의 구성 항목을 말할 수 있다
• 환경 구축 및 관리의 두 작업과 준비 보고서의 구성(요약, 항목별 준비 상태)을 말할 수 있다

흔한 실수

환경 요건 명세서를 환경 구축 활동의 산출물로 고르기. 요건(무엇이 필요한가)은 설계 및 구현이 정하고, 환경 구축은 준비 결과를 보고한다. "요건 명세서"와 "준비 보고서"의 짝을 갈라 둔다.

화살표 방향을 옛 판대로 외우기. 메트릭은 위로, 제어는 아래로다.

결함 추적 보고서가 29119 표준 문서라고 단정하기. 가이드는 결함 추적 보고서를 쓰도록 하지만, 그 문서는 ISO/IEC/IEEE 29119-3 표준에는 들어 있지 않다고 따로 밝힌다(레슨 7). 표준 문서 목록을 묻는 문제에서 함정이 될 수 있다.

테스트 계획을 동적 프로세스로 분류하기. 계획은 관리 프로세스의 활동이다. 동적 프로세스는 계획서를 입력으로 받아 실제 테스트를 한다.

참고 자료

• 한국정보통신기술협회, 『소프트웨어 테스트 전문가(CSTS) 가이드』 개정판 — 11장 11.1절, 13장 13.3~13.4절. 정오표 18·19번(그림 11.19 화살표) 반영
• ISO/IEC/IEEE 29119-2:2021 — Test processes — 조직·관리·동적 세 계층 프로세스의 정본
• ISO/IEC/IEEE 29119-3:2021 — Test documentation — 테스트 산출물 문서의 구성
• 이 커리큘럼 안: 모듈 8 레슨 3·4·5 「조직 테스트 프로세스」「관리 테스트 프로세스」「동적 테스트 프로세스」, 모듈 8 레슨 6 「표준 산출물 문서 따라가기」, 모듈 7 레슨 2·3 「테스트 데이터 관리」「테스트 환경 관리」