[IT 회사 생활] 테스트 사양서

1. 테스트

​프로그램 코딩을 완료하고 릴리즈 전 실시하는 테스트

 오류 발생은 주로 요건 정의나 설계 단계에서 나타나며, 검출은 수용 테스트나 릴리즈 후에 실제 환경에서 많이 나타난다. 테스트를 소홀히 하면, 릴리즈 후 발생한 오류에 대해 유저에게 사과를 하거나 환불이 필요하다. 그리고 한 기업으로 손실, 신뢰가 없어지는 결과가 생긴다.

미리 계획이나 대책을 생각하고 테스트를 경시하지 말 것. 오류에 대한 비용을 생각해 볼 때, 릴리즈 후의 오류 비용은 단체 테스트의 오류 비용의 수백배의 비용이 든다.

<주요 테스트의 종류> ​1. 단체 테스트 (単体テスト) 2. 결합 테스트 (結合テスト) 3. 기능 테스트 (機能テスト) 4. 시스템 테스트 (システムテスト)(부하 테스트, 볼륨 테스트, 보안 테스트 등) 5. 시나리오 테스트 (受け入れテスト, シナリオテスト) 6. 운용 테스트 (運用テスト) 7. 리그레션 테스트 (リグレッションテスト)

 현장에 따라 '개발 엔지니어'가 테스트를 하거나 'QA엔지니어'가 테스트를 하는 경우가 있다. 단체 테스트는 개발자가 담당한다. 또 결합 테스트 이후의 테스트는 QA 엔지니어 혹은 QA테스터가 담당한다. 단체 테스트의 규칙이나 망라성은 개발과 QA가 함께 생각하는 것이 품질을 향상시키는 데에 중요하다. 함께 테스트의 의의를 재검토하는 것도 가능하다.

 특히 스마트업계에서는 요건기능 사양서가 없는 경우게 많아 소통이라는 점에서는 '기획', '개발' , '서포트', '운용'을 연계해 진행할 필요가 있다.

---

2. 테스트 사양서를 작성하고 테스트 케이스를 준비

​ '테스트 계획', '테스트 설계'를 하고 '테스트 사양서'를 작성한다. 당연히 '리뷰'도 필요하므로 견적에 추가한다.

​

1) 테스트 계획

- 어떤 테스트를 할 것인가 (테스트의 종류) 기능 테스트, 보안 테스트나 부하 테스트

- 어디까지 담보할 것인가

- 테스트를 중지할 경우나 재개할 기준 (실시 환경 설정 미비)

- 실행환경의 확인 (예) 테스트 환경 > Staging환경 > 실제 환경 순으로 확인할 것인가?

- 테스트 결과 ('OK', 'NG' 각각의 범위는 어디까지인가)

- 테스트 도구를 사용할 것인가 (사용하는 경우에는, 사용 메리트로 기재)

- 전체 스케줄 (정례 MTG나, 각 테스트 기간, 실시 담당자 등)

- 조직도 (프로덕트 매니저, QA 매니저, QA리더, QA 테스터를 명확하게 기록)

- 어떤 테스트 데이터를 준비할 것인가

- 사양 변경이나 FIX 결정의 대응

- 테스트 리스크 (리스트 발생 빈도, 중대도)와 대책 항목(리스크 레벨의 설정)을 정리

​

2) 테스트 설계

- 사용서에서 읽어 낼 수 있는 수준 (사양서가 있는 경우를 전제)

* 사양서가 존재하지 않는 경우, 어디까지 담보할 것인지에 대한 선을 그어 놓아야한다.

- 내부 구조를 이해하고 설계하는 레벨 (개발 경험이 있는 담당자)

- 테스트 경함자의 감이나 지식으로 부터 실행하는 탐색적 테스트 (테스트 담당자에게 의존)

​

3) 테스트 사양서

- 설계서를 토대로 테스트 케이스 준비한다.

- 쓸데 없는 케이스가 있는지 확인한다. 직교표나 Allpair법을 사용하여 필요한 케이스만 정리해둔다.

- 전제 조건을 반드시 기록한다.

- 대항목, 중항목, 소항목, 전제조건, 조작 방법은 알기 쉽도록 작성한다.

* 미리 형식(템플릿)을 사내에 공유해 두는 것이 좋다.

​

4) 단체 테스트, 종합 테스트, 시스템 테스트

테스트 자동화만으로는 모든 것을 테스트하기 어렵기 때문에 경우에 따라서는 수동 테스트가 되어버리기도 한다.

설계서의 동작뿐만 아니라 설계서에 기재하지 않는 부분도 테스트 케이스에 넣는다.

다음은 Web 브라우저 단위로 테스트, 버전 단위로 테스트한다.

​

* 참고자료

- 스마트폰 최신 기종 https://www.ktai-labo.com/device/

- 안드로이드 OS 점유율 http://smatabinfo.jp/os/android/index.html

- iOS OS 점유율 http://smatabinfo.jp/os/ios/index.html

- 브라우저 점유율 https://webrage.jp/

---

3. 테스트 준비 시트

​

1) 테스트 환경 준비

2) Android 검증용 단말기와 실행용 'apk 파일'

3) iOS 검증용 단말기와 실행용 'ipa 파일'

4) 오류에 대한 친자 티켓(親チケット)이 준비되어 있는가

* 親チケット란? 큰 작업을 여러 개의 작은 작업으로 세분화된 하위 티켓을 가지고 있는 티켓이다.

5) 테스트용 계정이 준비되어 있는가

6) 상태별 테스트 데이터 준비되어 있는가

7) 테스트 케이즈의 검토가 끝난 후 수정이 되어 있는가

8) 사용 WEB브라우저와 버전이 준비되어 있는가

9) 테스트 툴 (Selenium, Jmeter, BrupSuite)가 준비되어 있는가

​

테스트 데이터를 얼마나 준비하면 좋을지에 대한 문제가 있다.

1) 올 페어 법과 직교표의 조합 (* 금칙 제외)

2) 테스트 데이터 툴을 사용 (예) PICT(Pairwise Independent Combinatorial Testing tool)

---

4. 테스트 설계 예

​

테스트 사양서 작성 전 설계 작성예이다.

테스트 레벨은 '어떤 종류의 테스트인가', 대상 화면은 '테스트 대상', 항목은 '테스트가 되는 객체'. 학인 항목은 '아래의 항목 실시 여부 중 O가 있는 항목'이다.

​

1) 프론트 엔드 확인

 이번 예는 '이름', '전화번호', '주소'의 설계이다. 확인항목은 아래에 작성된 확인 항목에 결합하여 테스트 사양서를 작성하는 형태가 된다. 테스트 사양서는 항목에 맞추어 'O'를 붙인 것만 작성한다.

확인 항목	실시 여부
maxlength 지정 (10문자가 maxlength로 지정한 경우, 9문자, 10문자가 입력 가능하며 11문자는 입력할 수 없다)	O
maxlength가 지정되어 있지 않은 경우	O
공백 문자	O
반각 문자 (ｱｲｳｴｵ、ｶｷｸｹｺ)	O
전각 문자 (あいうえお、かきくけこ)	O
기종의존 문자 (①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭⑮⑯⑰⑱⑲⑳：㍉㍍㌔㌘㌧㌦㍑㌫㌢：㍻㍼㍽㍾：ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩ)	O
소수점 (제 1 소수점 까지, 제 2 소수점 까지)	O
기호 문자 (〃 仝 ゝ ゞ 々 〆 ヾ ― ‐ ／ 〇 ヽ ＿ ￣ ¨ ｀ ´ ゜ ゛ ＼ § ＾ ≫ ￢ ⇒ ⇔ ∀ ∃ ∠ ⊥ ⌒ ∂ ∇ ≡ ∨ ≪ † √ ∽ ∝ ∵ ∫ ∬ Å ‰ ♯ ♭ ♪ ‡ ～ ′ ≒ × ∥ ∧ ｜ … ± ÷ ≠ ≦ ≧ ∞ ∴ ♂ ♀ ∪ ‥ ° ⊃ ⊂ ⊇ ∩ ⊆ ∋ ∈ 〓 〒 ※ ″)	O
마이너스 값	O
HTML 에스케이프 (<>&"')	O
JavaScript 내장 문자 (<>&"')	O
SQL 에스케이프 ('"%_％＿)	O
링크 표시, 링크 클릭 이동	​
버튼 표시, 버튼 클릭 이동	​
풀 다운 값, 라디오 버튼, 체크박스, 텍스트 영역	​
필수 항목 미입력 경우 결과	​
수 차례의 클릭의 경우 결과	​
수 차례 새로고침의 경우 결과	​
존재하지 않는 파라미터 전달	​
화면간 데이터 전달	​
상태에 의한 화면 표시 처리	​

 

2) 백 엔드 확인 (SQL, Linux 커맨드)

예를 들면 아래와 같다.

확인 항목	실시 여부
DataBase에 연결가능한가	O
유저와 관리자 역할 권한 확인	​
메일 자동 설정할 때의 cron 설정의 경로 확인 crontab -l	O
http 와 https의 프로토콜 확인	O
config 설정이 정확한지	​
에러 레벨이 적절한가	​
에러 발생시, Error.log 출력	O
jQuery의 버전 확인 (* 사용 라이브러리 확인)	O
php의 버전 확인, MySQL의 버전 확인 (* 버전에 따라 지금까지 사용가능한 함수가 사용이 불가능한 경우가 있으므로 확인할 필요가 있음)	​
메일 송신할 때, 송신로그 출력	​
저장 프로시저 확인	O
마스터 DB 덤프	O
MySQL 스레드 서버 확인	​

​

3) 테스트 사양서에의 입력

(1) 테스터가 알기 쉽도록, 테스트 상세나 전제조건 등을 준비

(2) 중요도 '고', '중', '저'와 테스트 구분 '정상계', '이상계'도 설정한다.

(3) 테스터는 기대치가 실측값과 맞는지 확인하고, 테스트 결과를 풀 다운에서 'OK' 'NG' 'PN'중 하나를 선택해 작성한다.

또한 에러관리표에도 기록한다.

- OK : 기대값과 실측값이 동일

- NG : 기대값과 실측값이 다름

- PN : 테스트 환경 미비나 테스트 케이스 자체를 실행할 수 없는 경우

(4) 버그 검출률이나 테스트 케이스 소화율을 산출할 수 있도록 한다. 여기에서는 Excel함수를 사용하여 집계를 편하게 한다.

​

테스트 사양서

​

테스트 시트

---

5. 테스트 사양서의 템플릿화

 ​안건이나 필요할 때 마다 작성하다 보면 작성 공정수나 리뷰 공정수가 늘어난다. 그러므로 전체의 기능의 템플릿을 진행하면 작성자 의존이 없어지고, 품질의 편중도 없어진다. 또한 템플릿을 버전 관리함으로써 어떤 기능이 어떤 버전으로 관리되고 있는지 쉽게 알 수 있다.

---

6. 오류의 기재

 ​테스트 케이스에는 테스트 결과 항목에서 NG가 선택. 재현 절차를 버그 관리 시스템에 등록한다. 일반적으로는 Jira나 Redmine, Backlog가 사용되는 경우가 많다.

---

참고자료

https://qiita.com/jun2014/items/cad7328978e709fe79f4