예전에 인턴하면서 프로젝트해서 만든 자료인데 공유하고 싶어서 올립니다. 한국어로된 자료가 별로 없더라구요. 많은 레퍼런스 보고 만든 문서인데 혹시 필요하신분 있으면 참고하세요. 물론 이건 표준이고 현실에서는 표준을 따르지 않을 때도 많습니다. 프로젝트마다 테스트 강도를 조절하는 것이 좋다고 생각합니다.

1. 표준 테스트 프로세스 & 메뉴얼
작성자
최신 업데이트 날짜 2019.04.17
분량 30 page

2. 2 / 30
문서의 목적
1. 테스트 프로세스 표준화
2. PM, 테스팅 수행자에게 테스트 프로세스 & 매뉴얼 제공
3. Biz Case별, 상황별 테스팅 매뉴얼 제공

3. 3 / 30
서문. 문서의 목적
1. 표준 테스트 프로세스 –V모델 기반
1.1 요구 분석
1.2 시스템 설계
1.3 구조 설계
1.4 상세 설계
1.5 코딩
1.6 단위 테스팅
1.7 통합 테스팅
1.8 시스템 테스팅
1.9 인수 테스팅
2. 테스트 상황별
2.1 유지보수 테스트
2.2 비기능 테스트 수행
2.3 단기간(3일 이하) 테스팅
2.4 테스트 아웃소싱을 주는 경우
※ 별첨
목차

4. 1. 표준 테스트 프로세스

5. 5 / 30
1. 표준 테스트 프로세스
표준 테스트 프로세스 모형 – V모델 기반
(각 단계들이 이분법적으로 나누어지지 않습니다. 교집합부분이 존재합니다.)
시스템 설계
인수 테스트
구조 설계
(상위, 아키텍처)
통합 테스트
모듈 설계
(하위, 상세)
단위 테스트
코딩
시스템 테스트
요구 분석
요구 확인
설계
모듈 확인
인터페이스 확인
기능 확인
인터페이스 디자인

6. 9 / 30
1. 요구사항 분석
표준 테스트 프로세스
해야할 일 1. 요구 분석 명세서 작성 (V모델 특성상 추 후 변경이 어려우므로 확실히 마무리 짓기)
(필요에 따라 사용자 요구 사항1) + 시스템 요구 사항 명세서2)를 분리해서 작성한다.)
2. 테스트 정책서 확인
4. 총괄 테스트 계획서 작성(테스트 계획서 템플릿 참고)
5. 인수 테스트 계획서(또는 인수 테스트 시나리오 목록 작성)
6. (인수) 테스트케이스 명세서 작성
7. 리뷰 활동 (동료 리뷰, 검토 회의)
필요 산출물 1. 요구 분석 명세서
2. 총괄 테스트 계획서
3. 테스트 케이스 명세서
참고사항 1. 결함 유입을 비용대비 효율적으로 방지하기 위해서 리뷰하는 것 추천
3. 잘 만든 요구 분석 명세서의 6가지 특징(1. 완전성 2. 명확성 3. 일관성 4. 추적 가능성 5. 변경 용이
성 6. 검증 가능성)을 고려하여 만든다.
1) 사용자 요구사항 명세서 : 사용자 입장에서의 설계도면 (일반인이 이해할 정도의 용어 사용, UI 차원의 기능)
2) 시스템 요구사항 명세서 : 개발자 입장에서의 설계도면, 구체적인 기술적인 용어, 전문적인 표현을 사용

7. 10 / 30
표준 테스트 프로세스
2. 시스템 설계
해야할 일 1. 사용자 요구사항, 시스템 요구사항을 보고 UI, 시스템 설계 (기술스택, DB, 서버, 언어 등 논리적 설계 위주)
2. 테스트 설계 기법 정의 후 시스템 테스트케이스 명세서 작성(또는 시스템 테스트 시나리오 목록 작성)
3. 비기능 요구사항 명세서가 있는 경우 비기능 테스트 계획.
4. 리뷰 활동 (동료 리뷰, 검토 회의)
필요 산출물 1. (시스템) 테스트 케이스 명세서 또는 시스템 테스트 계획서.
2. 리뷰 문서
참고사항 1. 동적 테스팅 설계 기법 종류 : 동등 분할, 경계값 분석, 결정 테이블, 상태 전이, 유스케이스, 페어와이즈, 경험기반
테스팅 등

8. 11 / 30
표준 테스트 프로세스
3. 구조 설계
해야할 일 1. 구조를 설계한다. (모듈 간 인터페이스 위주)
2. 테스트 케이스 설계 기법 정의 후 통합 테스트 케이스 명세서 작성
3. 통합 테스트 계획서 작성(또는 통합테스트 시나리오 목록 작성)
4. 리뷰 활동 (동료 리뷰, 검토 회의)
필요 산출물 1. 통합 테스트 케이스 명세서
2. (선택) 통합 테스트 계획서(테스트 케이스 량이 많으면 필요하다)
3. 리뷰 문서
참고사항 1. 아키텍처, 데이터, 인터페이스, 사용자 인터페이스를 설계하는 단계
2. 정적 테스팅 기법(분기 커버리지, 구문 커버리지, 기본 경로 테스팅 등)

9. 12 / 30
표준 테스트 프로세스
4. 상세(모듈) 설계
해야할 일 1. 단위 테스트 케이스 명세서 제작
2. 단위 테스트 계획서(또는 단위 테스트 시나리오 목록 작성)
3. 리뷰 활동 (동료 리뷰, 검토 회의)
필요 산출물 1. (단위) 테스트 케이스 명세서
(또는 테스트 시나리오)
2. (선택)단위 테스트 계획서
2. 리뷰 문서
참고사항 1. 모듈, 자료구조, 알고리즘 설계를 하는 단계이다.

10. 13 / 30
표준 테스트 프로세스
5. 코딩
해야할 일
1. 코드 리뷰를 한다.(다른 리뷰 포함)
2. 정적분석도구를 사용한다.(문제의 소지가 될 만한 부분 미리 제거)
3. 리뷰 활동 (동료 리뷰, 검토 회의)
필요 산출물 1. 리뷰 문서
참고사항
1. 이 단계에서는 주로 테스팅보다 디버깅을 수행합니다.
2. 테스트 주도 개발(TDD)방식의 개발일 경우 테스트 코드 작성을 병행합니다.
요즘 테스트, 품질의 중요성이 증대되면서 TDD방식 개발하는 경우가 많아지고 있습니다.
3. 자동 정적 분석 도구로 오픈소스인 Sonaqube 추천 // 자금여유가 있다면 유료 툴 사용도 추천합니다.
품질을 올리는데 도움이 됩니다.
4. Git_Pull request 같은 수동 코드 리뷰 도구를 사용해도 좋습니다.

11. 14 / 30
표준 테스트 프로세스
6. 단위 테스트
해야할 일
1. 단위 테스트 케이스 명세서 실행 및 측정 + 이슈 관리 문서 작성
2. 단위 테스트 코드 작성
3. 단위 테스트 품질 목표 달성 확인
4. 리뷰 활동 (동료 리뷰, 검토 회의)
5. 구조 기반 테스팅(구문, 분기, 조건 커버리지 등)
필요 산출물
1. 단위 테스트케이스 명세서 & 이슈 관리 문서
2. 단위 테스트 결과 보고서
참고사항
1. 구조 기반 테스팅을 주로 한다.
(기법 종류 : 구분, 결정, 조건, 다중 조건 커버리지, 제어 흐름 테스팅, 기본 경로 테스팅 등)
- 정적 분석 툴을 이용할 수도 있다.
2. 테스팅 대상은 주로 컴포넌트, 객체 , 클래스, 프로그램 등 이다.
3. 각 모듈들을 독립적으로 평가한다.

12. 15 / 30
표준 테스트 프로세스
7. 통합 테스트
해야할 일
1. 통합 테스트 케이스 명세서 실행 및 측정
2. 이슈(인시던트) 관리 문서 작성
3. 모듈을 통합하는 과정 중에 발생하는 결함 제거
4. 통합 테스트 품질 목표 달성 확인
5. 리뷰 활동 (동료 리뷰, 검토 회의)
필요 산출물
1. 통합 테스트 케이스 명세서 & 이슈 관리 문서
2. 통합 테스트 결과 보고서
참고사항
1.. 모듈간 인터페이스 테스트
2. 모듈이 잘 결합되었는지 확인하는 것이 주요 목표

13. 16 / 30
표준 테스트 프로세스
8. 시스템 테스트
해야할 일 1. 시스템 테스트 케이스 명세서 실행 및 측정.(시스템 테스트 계획서 기반)
2. 이슈(인시던트) 관리 문서 작성
3. 필요에 따라서 비기능 테스트를 수행.
4. 시스템 테스트 품질 목표 달성 확인
5. 리뷰 활동 (동료 리뷰, 검토 회의)
필요 산출물 1. 시스템 테스트 케이스 명세서 & 인시던트 관리문서
2. 시스템 테스트 결과 보고서
참고사항 1. 시스템의 기능과 비기능이 정상 작동하는지 확인하는 단계입니다.
2. ‘환경특정 장애’ 리스크를 최소화하기 위해 가능한 범위에서 실제 사용 환경 또는 이와 유사한 환경에서 수행해야합
니다.
3. 모든 모듈을 통합한 후에 하는 테스트.
4. 블랙박스 테스팅 하기에 적합한 단계
5. 탐색적 테스팅과 명세기반 테스팅을 함께 쓰는 것이 좋습니다.

14. 17 / 30
표준 테스트 프로세스
9. 인수 테스트
해야할 일 1. 요구 분석 명세서와 일치 하는 지 확인 (인수 테스트 케이스 명세서 실행 및 측정)
2. 이슈 관리 문서 작성
4. 인수 테스트 품질 목표 달성 확인
5. 인수테스트가 끝나면 사용자에게 인계하고 프로젝트 종료한다.(표준 평가 도구 사용)
6. 완료 보고서 작성
7. 리뷰 활동 (동료 리뷰, 검토 회의)
필요 산출물 1. 인수 테스트 케이스 명세서 및 이슈 관리 문서
2. 인수 테스트 결과 보고서
참고사항 1. 결함을 찾는 것이 주 목적이 아님(알파, 베타 테스트 제외)
인수 테스트 종류 1. 사용자 인수 테스팅 : 요구사항 충족 되었는지 확인
2. 운영 인수 테스팅 : 백업/복원 테스팅
3. 계약 및 규제 인수 테스팅 : 계약상의 인수 통과 조건 준수하는 지 체크
정부지침, 법률, 안정 규정 등을 준수해서 개발되었는지 체크
4. 알파(alpha) 및 베타(beta) 테스팅 : 전자는 내부에서 테스트, 후자는 클로즈 베타, 오픈 베타가 있음

15. 2. 상황별 테스트 프로세스 & 매뉴얼

16. 19 / 30
2.1 유지보수 프로젝트
유지 보수 테스팅 매뉴얼 -> 주로 2가지 테스팅을 위주로 한다.
확인 테스트 𝟏)
회귀(리그레이션) 테스
트2)
1) 확인 테스트 : 수정을 한 부분이 정상 작동하는 테스트
2) 리그레션 테스트: 수정한 부분 근처에 사이드 이펙트가 발생하지 않았는지 확인하는 테스트
회귀 버그는 프로그램 변경 중 뜻하지 않게 발생함.
(블랙박스, 화이트박스 테스팅 모두 적용 가능)
회귀 테스트
확인 테스트

17. 20 / 30
2.2 비기능 테스트
품질 특성을 확보 -> 기본적으로 실시해야 하는 비기능 테스트 종류(7가지)
성능
테스트
부하
테스트
스트레스
테스트
사용성
테스트
유지보수
테스트
신뢰성
테스트
이식성
테스트

18. 21 / 30
2.2 비기능 테스트 종류별 간략 설명
비기능 테스트 종류 설명
1. 성능 테스팅
1. SW의 성능을 측정하기 위한 테스트 절차
2. 수치화된 성능 목표를 설정 하고 그 목표를 달성했는지 확인
2. 부하 테스팅 1. 임계치의 한계에 도달할 때까지 SW에 부하를 서서히 증가시켜서 나타나는 현상을 테스트
3. 스트레스 테스팅
1. 요구사항의 한계 성능을 초과시킬 경우 어떤 현상이 나타나는지 테스트
2. 한계를 초과한 후에 정상적으로 돌아오는 지 확인합니다.
3. 저자원으로 설정한 후에 테스팅
4. 사용성 테스팅
1. 사용자가 SW제품을 얼마나 잘 편리하게 사용할 있는지 측정
2. 사용성을 측정할 지표 설정
5. 유지보수 테스팅
1. 시스템의 변경 또는 변경된 환경이 운영 중인 시스템에 미치는 영향력에 대한 테스팅
2.주로 확인 테스팅, 리그레이션 테스팅 수행
6. 신뢰성 테스팅 1. 특정 환경에서 지정된 기간 동안 오류 없는 이 발생할 확률 측정
7. 이식성 테스팅 1. SW구성요소 또는 응용 프로그램을 한 환경에서 다른 환경으로 이동할 수 있는 용이성

19. 22 / 30
2.3 단기간 테스팅
단기간(3일 이내)에 테스팅을 마쳐야 하는 경우
탐색적 테스팅
체크리스트
Ex) 15년 한솔개발모바일앱 프로젝트
테스트 강도를 낮추면 기회비용으로 품질이 떨어지는 것은 불가피하다는 점을 인지합니다.
(+ 체크리스트 : 간소화된 TC라고 볼 수 있음)

20. 23 / 30
2.3 단기간 테스팅
탐색적 테스팅 메뉴얼
사용하는 경우
- 테스트케이스 명세서를 만들 시간이 없을 때
- 경험 기반 테스팅을 수행하고 싶은 경우
- 명세 기반 테스팅으로 발견하지 못한 결함을 발견하고 싶을 때(살충제 패러독스1) 해결)
관련 템플릿 탐색적 테스팅_템플릿.xlsx
사용방법
1. 테스트 차터 작성(테스트 계획표 요약 형태)
2. 테스트 노트 작성(테스트컨디션(테스트 아이디어) 구상)
3. 탐색적 테스팅 시작(별도의 테스트 케이스 없이 자신의 경험적 판단, 직관으로 자유롭게 테스트)
4. 테스팅 도중에 발생한 인시던트(이슈)를 인시던트 관리 문서 sheet에 기입
참고사항
1. 테스팅 경험이 많지 않다면 효율이 떨어질 수 있습니다.
2. 테스터의 직관에 허점이 많으므로 되도록이면 명세 기반 테스팅과 병행하는 것 추천
1) 살충제 패러독스 : 동일한 테스트를 반복하면 결함을 찾기 힘듬, 테스트 방법 다양화가 필요.

21. 24 / 30
2.3 단기간 테스팅
체크리스트 메뉴얼
사용하는 경우 1. 빠르게 핵심 기능의 정상 작동여부를 확인하고 싶은 경우
2. 테스트케이스를 쓸 시간이 없는 경우
관련 템플릿 체크리스트.xlsx
사용방법 1. 체크할 항목을 기입한다.
2. 체크리스트를 수행한다. 통과하면 Pass, 실패하거나 문제의 소지가 있
다면 Fail을 입력한다. 적용할 수 없는 경우 N/A을 입력한다.
참고사항 1. 질문 형식은 Pass가 나오면 정상작동, Fail 나오면 비정상 작동으로
판단할 수 있게 포지티브 질문형식으로 만듭니다.
예를 들어 “로그인이 정상작동하는가? O, “로그인이 작동하지 않는다
“ X // 전자의 질문 방식을 사용.

22. 25 / 30
2.4 테스팅 아웃소싱 주는 경우
품질이 중요변수인 프로젝트 테스팅 전문업체에 아웃소싱하는 것이 좋은 선택지
가 될 수 있음
참고 ) 3가지 테스팅 서비스를 한 곳에서 제공하는 경우가 대부분입니다. 한 곳에 외주를 주면 됩니다.
아웃 소싱을 주기로 결정한 경우
1차적으로 자사 내부 테스트 프로세스 수행 후 2차로
아웃소싱 테스팅 과정으로 들어가는 것이 효율적
삼성, LG전자, 현대자동차 등 일부 대기업은 품질 향상을 위해 대부분의 프로젝트에 테스
팅 아웃소싱 시행중
분류1
정적 테스팅
(화이트박스 테스팅)
참고 업체
1. 스패로우
2. 와이즈 스톤
3. 인피닉
분류2
동적 테스팅
(블랙박스 테스팅)
참고 업체
1. 와이즈 와이어즈
2. 테스트이앤씨
3. 티벨
분류3
보안 테스팅
참고 업체
1. 스패로우
2. 와이즈 스톤
3. 코드 마인드

23. 26 / 30
※ 테스트 프로세스 단계별 툴 추천.
소프트웨어 공학 포털 SW개발도구
http://www.sw-eng.kr/member/00000000000000032236/Cms/BoardView.do
위의 이미지는 자료의 일부.
더 많은 툴을 보려면 아래 링크 클릭
영역 PNS 에 추천하는 툴 이유
CI 툴 Jenkins
1. 대중적
2. 무료
3. 성능 좋음
자동 정적 분석 도구(C++,
java etc)
Sonarqube
1. 무료
2. 성능 괜찮음
VCS Git
1. 대중적
2. 성능 괜찮음
수동 정적 분석 도구 Git – Pull Request 1. 성능 괜찮음
BTS Redmine, Jira
1. 레드마인은 무료
2. 지라는 가격대비 성능이
좋음(세계 점유율 60%)