영향력 있는 컨설턴트이자 저자인 톰 디마르코는 프로젝트 관리에 관한 이 소설을 통해 소프트웨어 개발팀의 생산성에 어떤 요인이 영향을 미치는지 묘사한다. 스텝 구성, 인원 선발, 일정 압력, 나쁜 보스, 조직 내의 갈등 등 현실 프로젝트에서 벌어질 수 있는 이야기가 소재다.
거대 통신회사에서 정리해고된 주인공 '톰킨스'를 통해 소프트웨어 개발의 모든 문제가 결국은 '사람' 문제이며, 올바른 사람을 찾고, 사람들의 일을 조율하고, 적절한 동기를 부여하며, 팀을 건전하게 구성. 유지. 결속하는 것이 모든 프로젝트의 성공 요인이라고 말한다.
저자 : 톰 디마르코
Tom DeMarco. 소프트웨어 개발 프로젝트 관리, 조직 관리에 대한 명쾌하고, 위트 있는 글로 세계 각국의 IT 관련 종사자들에게 지명도를 확보하고 있는 저자이자 컨설턴트이다.
87년 출간된 그의 저서 『Peopleware』는 소프트웨어 개발에서 사람이 가장 중요함을 제기해 프로젝트 관리자의 필독서로 자리 잡았고, 2003년에는 프로젝트 리스크 관리에 관한 새로운 시각을 제시한 『Waltzing With Bears』로 주목을 받고 있다.
역자 : 김덕규
건국대학교 전자계산학과를 나왔고, 1976년 고려대학교 정보전산원 근무를 시작으로, 삼성전자 특수개발실을 거쳐, 2004년 현재 삼성 SDS에서 국방 프로젝트 관련 컨설턴트 역을 수행하고 있다. 번역한 책으로 『소프트웨어 프로젝트 생존전략』이 있다.
역자 : 류미경
호주 뉴캐슬대학교에서 커뮤니케이션을 전공했다. 쿨소프트 코리아와 컴포넌트비젼에서 마케팅 업무를 담당했고, 2004년 현재 프리랜서로 일하고 있다.
공역한 책으로 『eXtreme Programming Installed-XP 도입을 위한 실전 입문』, 『소프트웨어 프로젝트 생존 전략』이 있다.
목차
옮긴이 서문
서문
등장인물
1. 기회 타진
2. 칼브퍼스와의 대결
3. 실리콘 벨리엣
4. CD-ROM 공장
5. NNL
6. 세상에서 가장 위대한 프로젝트 관리자
7. 직원 채용
8. 저명한 리졸리 박사
9. 예비역 육군장군 마르코브
10. 압둘 자미드
...
테스팅과 리뷰에 의하여 결함(defect)를 발견하는 효과는 독립적인 테스터를 이용하여 향상시킬 수 있다. 독립의 조건은 다음과 같다.
▪ 개발 팀들 내의 독립적인 테스터들 ▪ 프로젝트 관리나 경영진에 보고하는 조직 내의 독립적인 테스트 팀이나 테스트 그룹 ▪ 업무 조직, 사용자 커뮤니티, 그리고 IT로 부터 독립적인 테스터들 ▪ 사용성 테스터, 보안 테스터, 또는 (표준과 규약에 대하여 소프트웨어 제품을 인증하는) 인증 테스터들과 같이 특정 테스트 목적을 위한 독립적인 테스트 전문가 ▪ 조직의 외부 또는 아웃소싱된 독립적인 테스터들
일반적으로 규모가 크고, 복잡하거나 안전에 민감한 프로젝트를 위해서는, 독자적인 테스터들에 의한 다양한 테스트 레벨을 갖는 것이 최선이다. 개발 스텝은 특별히 낮은 레벨에서의 테스팅에 참가할 수 있다. 그러나 그들의 객관성의 결여는 때때로 그들의 효과를 제한한다. 독립적인 테스터들은 테스트 프로세스와 규칙을 요구하고 정의할 수 있는 권한을 가질 수 있지만, 이 프로세스 관련 규칙은 단지 관리자 명령이 있을때에만 주어질 수 있다.
독립의 장점은 다음을 포함한다.
▪ 독립적인 테스터들은 다른 여러가지 결함을 찾으며, 편향되지 않는다. ▪ 독립적인 테스터는 명세와 시스템의 구현 동안에 사람들이 만들어 놓은 가정들을 검증할 수 있다.
약점은 다음을 포함한다.
▪ 개발팀으로부터 고립된다. (완전히 독립적으로 다루어진다면) ▪ 독립적인 테스터들은 최적 체크 포인트로써 병목지점이 될 수 있다. ▪ 개발자들은 품질에 대한 책임감을 잃어 버린다.
테스팅 작업은 특정 테스팅 역할을 담당하는 사람에 의하여 행하여 질 수도 있고, 프로젝트 매니저, 품질 관리자, 개발자, 비지니스와 도메인 전문가, 인프라 스트럭쳐 운영자 또는 IT 운영자와 같은 다른 역할의 누군가에 의하여 행하여 질 수도 있다.
5.1.2 테스트 리더와 테스터의 임무
이 요약서에서는 테스트 리더(test leader)와 테스터의 두 개의 테스트 역할에 대하여 다룬다. 이러한 두 역할을 담당하는 사람들에 의하여 수행되는 액티비티와 작업은 프로젝트와 제품 내용, 역할(roles)내의 사람들과 조직에 따라 다르다.
때때로 테스트 리더는 테스트 매니저(test manager) 또는 테스트 코디네이터(test coordinator)로 불린다. 테스트 리더의 역할은 프로젝트 매니저, 개발 관리자, 품질 보증 관리자 또는 테스트 그룹의 관리자에 의하여 수행될 수 이 있다. 규모가 큰 프로젝트에서는 테스트 리더와 테스트 매니저, 두 가지의 역할이 존재할 수 있다. 일반적으로 테스트 리더는 섹션 1.4에서 정의된 것 같이 테스팅 액티비티와 작업을 계획 및 모니터하고 통제한다.
일반적인 테스터 리더의 임무(tasks)는 다음을 포함한다.
▪ 테스트 전략과 계획을 프로젝트 매니저와 다른 사람들과 함께 기획한다. ▪ 프로젝트에 대한 테스트 전략과 조직에 대한 테스트 정책을 작성하고 리뷰한다. ▪ 통합 계획과 같은, 다른 프로젝트 액티비티에 대하여 테스팅 측면에서 이바지한다. ▪ 테스트의 수행 방법 선택, 테스팅의 시간, 노력 그리고 비용의 평가, 자원의 획득, 테스트 레벨, 주기, 방법 그리고 목표의 정의와 부가 사항 관리 계획을 포함하여 - 테스트 내용과 예상되는 위험을 고려하여 테스트 계획을 세운다. ▪ 테스트의 명세, 준비, 구현과 실행을 초기화하고, 실행을 모니터, 통제한다. ▪ 테스트 결과와 진행에 기반한 계획을 적용하고 (때때로 상태 보고서로 문서화된다.), 문제를 보완하기 위하여 필요한 모든 행동을 취한다. ▪ 추적성을 위하여 테스트웨어(testware)의 적절한 환경 관리사항을 설정한다. ▪ 테스트 프로세스 측정을 위한 적당한 특성(metrics)을 소개하고 제품과 테스팅의 품질을 평가 한다. ▪ 무엇이 어느 정도로 어떻게 자동화 될 것인지를 결정한다. ▪ 테스트 지원 도구를 선택하고 테스터의 도구 사용에 대한 모든 훈련을 구성한다. ▪ 테스트 환경의 구현에 대한 결정을 한다. ▪ 테스트 일정을 잡는다. ▪ 테스팅 동안에 수집된 정보에 기반한 테스트 요약 보고서를 작성한다.
일반적인 테스터의 작업은 다음을 포함한다.
▪ 테스트 계획을 리뷰하고, 기여한다. ▪ 테스트 가능성(testability)를 위하여 사용자 요구사항과 명세, 그리고 모델을 분석하고, 리뷰하고, 평가한다. ▪ 테스트 명세를 생성한다. ▪ 테스트 환경을 설정한다.(때때로 시스템 관리자와 네트웍 관리자와 함께 협의한다.) ▪ 테스트 데이터를 준비하고 획득한다. ▪ 모든 테스트 레벨의 테스트를 구현하고, 테스트를 실행하고 로깅하여, 결과를 평가하고, 예상되는 결과로 부터의 유도사항을 문서화한다. ▪ 요구되는 테스트 관리자, 또는 관리 도구, 그리고 테스트 모니터링 도구를 이용한다. ▪ 테스트를 자동화시킨다. (개발자나 테스트 자동화 전문가에 지원을 받을 수 있다.) ▪ 컴포넌트와 시스템의 성능을 측정한다.(가능하다면) ▪ 다른 사람들에 의하여 개발된 테스트들을 리뷰한다.
테스트 분석, 테스트 디자인, 특정 테스트 종류나 테스트 자동화를 담당하는 사람들은 자신이 맡은 역할 분야에서 전문가일 수 있다. 테스트 레벨, 제품과 프로세스에 관련된 위험에 따라 다양한 사람들이 어느정도의 독립성을 가지며 테스터의 역할을 맡을 수 있다. 일반적으로 컴포넌트와 통합 레벨에서의 테스터는 개발자가 될 것이며, 승인 테스트 단게의 테스터는 비지니스 전문가나 사용자가 될 것이다. 그리고 운영 승인 테스팅에대한 테스터는 운영자가 될 것이다.
5.2 Test planning and estimation
5.2.1 테스트 계획 (Test planning) (K2)
이 장은 개발, 구현 단계에 있는 과제의 테스트 계획 목적과 유지보수 액티비티들에 대해 설명한다. 계획은 프로젝트 계획이나 마스터 테스트 계획(master test plan), 그리고 시스템 테스팅과 승인 테스팅과 같은 각 테스트 레벨에 대한 분리된 테스트 계획으로 문서화 될 수 있다. "소프트웨어 테스트 문서화를 위한 표준"(IEEE829)에서 테스트 계획의 문서화에 대한 개괄적인 내용을 다루고 있다.
계획은 조직의 테스트 정책, 테스팅의 범위, 목표, 위험, 제약사항, 임계치(criticality), 테스트 가능성, 그리고 자원의 가용성(availability)에 영향을 받는다. 프로젝트와 테스트 계획이 더 많이 진행될수록 계획에 포함시킬수 있는 더 많은 정보가 이용가능해지며, 더욱 구체화 된다.
테스트 계획은 계속진행되는 활동이며, 모든 개발 주기 프로세스와 액티비티에서 수행된다. 테스트 액티비티로부터의 피드백은 변경되는 위험을 인식하는데 사용되며, 계획을 조절할 수 있게 한다.
5.2.2 테스트 계획 액티비티 (Test planning activities) (K2)
테스트 계획 액티비티는 다음을 포함할 수 있다.
• 테스트 레벨과 항목 그리고 종료 특성을 포함한 전체적인 테스팅(테스팅 전략)의 접근 방식을 정의한다. • 소프트웨어 수명 주기 액티비티(software life cycle activities)에 테스팅 액티비티를 통합하고 구성한다. : 취득(acquisition), 공급(supply), 개발(development), 운영(operation), 그리고 유지보수(maintenance) • 무엇을 테스트 할 것인지, 어떤 역할이 테스트 액티비티를 수행할 것인지, 언제 그리고 어떻게 테스트 액티비티가 행하여 질 것인지, 어떻게 테스트 결과를 평가할 것인지, 그리고 언제 테스트를 종료할 것인지(종료 특성)을 결정한다. • 여러가지 정의된 작업에 대한 자원을 할당한다. • 테스트 문서화를 위한 수량, 세부 레벨, 구조와 템플릿을 정의한다. • 테스트 준비와 실행, 결함(defect)의 해결과 위허, 이슈사항을 모니터링하고 통제하기 위한 특성들을 선택한다. • 재현 가능한 테스트 준비와 실행을 지원하기 위한 충분한 정보를 제공하기 위한 테스트 프로시져의 세부 레벨을 설정한다.
5.2.3 종료 특성 (Exit criteria) (K2)
종료 특성(Exit criteria)의 목적은, 한 테스트 레벨이나 마지막이나 테스트 셋이 특정 목표를 달성 했을 때와 같이, 언제 테스팅을 중단 할 것인가를 정의하는 것이다.
일반적인 종료 특성을 구성하는 것은 다음과 같다.
• 코드, 기능 또는 위험의 커버리지와 같은 측정치의 완벽함 • 결점의 조밀도 또는 신뢰성 측정치의 평가 • 비용 • 고쳐지지 않은 결함이나 특정 영역에 대한 테스트 커버리지의 부족과 같이 잔여하는 위험 • 시장 적기 출시(time to market) 같은 것에 기반한 일정
5.2.4 테스트 평가 Test estimation (K2)
테스트 효과의 측정을 위한 두가지 방법이 이 요약서에서 커버된다.
• 전형적인 값들(typical values)에 기반하거나 유사한 프로젝트 또는 특성의 구성요소(metrics of former)들에 기반한 테스팅 효과의 평가 • 이러한 작업(tasks)의 소유자나 전문가에 의한 작업의 평가(estimating the tasks) 테스트 효과가 평가되면, 자원이 결정될 수 있으며 일정이 조정될 수 있다.
테스팅 효과는 다음에 포함되는 여러가지 요소에 의존할 수 있다.
• 제품의 특성(Characteristics of the product) : 명세와 테스트 모델을 위하여 사용되는 다른 정보의 품질, 제품의 크기, 문제 영역의 복잡성, 신뢰성과 보안에 대한 요구사항, 그리고 문서화에 대한 요구사항 • 개발 프로세스의 특성들(Characteristics of the development process): 조직의 안정성, 사용되는 도구, 테스트 프로세스, 포함된 사람들의 기술, 그리고 시간의 압박 • 테스팅의 결과물 (Outcome of testing): 결함의 갯수와 요구되는 재작업의 분량
5.2.5 테스트 방법 (테스트 전략) (Test approaches(test strategies)) (K2)
테스트 방법이나 전략을 구분하는 한가지 방법은 다량의 테스트 디자인 작업이 시작되는 시점에 기초로 하는 것이다.
• 예방적인 방법, 테스트가 가능한 빨리 설계되는 경우 • 반응적인 방법, 테스트 디자인이 소프트웨어나 시스템이 생산된 후에 나오는 경우 일반적인 방법이나 전략은 다음을 포함한다. • 분석적인 방법, 가장 큰 위험 영역으로 부터 유도된 테스팅과 같은 위험 기반 테스팅처럼 • 모델 기반 방법, 실패 비율(신뢰성 향상 모델과 같은)이나 사용량(운영 프로파일)에 대한 통계적인 정보를 사용하는 확률적인 테스팅 • 계통적인 방법, 실패 기반(추측되는 에러와 결함 공격을 포함하는), 체크 리스트 기반, 그리고 품질 특성 기반의 • 프로세스 또는 표준 준수 방법, 산업에 특화된 표준이나 여러가지 기민한 방법론에 의하여 특화된 것 같은 • 동적이고, 발전적인 방법. 테스팅이 미리 계획한 것보다 이벤트에 더욱 반응적이고, 실행과 평가가 동시 작업일 경우, 예비적인 테스팅과 같은 • 회귀-반대 방법, 기존 테스트 자료, 기능적인 회귀 테스팅의 확장된 자동화, 그리고 표준 테스트 슈트를 재사용하는 것을 포함하는 것과 같은
예를 들어, 위험 기반의 동적 접근 방법과 같이 여러가지 방법들이 조합될 수 있다.
테스트 방법의 선택은 다음을 포함하는 내용이 고려되어야 한다.
• 프로젝트 실패의 위험, 제품에 대한 위험과 사랑, 환경, 회사에 대한 제품 실패의 위험 • 제안된 기술, 도구와 방법에 대한 사람들의 기술과 경험 • 테스팅 노력의 목적과 테스팅 팀의 임무 • 개발 프로세스에 대한 내부적인 규약과 외부적인 규약과 같은 규약 측면 • 제품이나 비지니스의 본질
▪ Testability 평가 - 완결성(Completness) - 테스트에 필요한 모든 것이 다 있는가? - 주요 기능성(Primary functionality) 주요 기능이 잘 동작하는가? ▪ Pre-test 대상 - 테스트 대상 (object) : SW, HW, Prototype, etc - 테스트 인프라 : 입력값 생성기, 출력값 분석기, 시뮬레이터, 테스트 장비, 등
◆ 테스트 결과 분석(Test Result Analysis)
▪ 실제 테스트 결과와 예상 결과와 비교 ▪ 비교 결과의 차이점이 생긴 원인 분석 1. 테스트 (케이스) 결함 - 테스트 실패가 어플리케이션 결함이 아닌 테스트 케이스 자체에 결함이 있는 경우 - 스크립트, 시나리오, 수행상의 오류, 잘못된 테스트 데이터 또는 입력 오류 2. Application 결함 - Documentation (Specification) 결함, SW결함, HW결함, Procedure결함,
Installation 결함 3. Application context error - User Error - 테스트 환경과 관련된 SW 에러(OS, DBMS)
5.3. Test progress monitoring and control
5.3.1 테스트 진행사항 모니터링 (K1)
테스트 모니터링의 목적은 테스트 액티비티에 대한 피드백과 가시성을 주는 것이다. 모니터되어야하는 정보는 수동이나 자동으로 수집될 수 있으며, 커버리지와 같은 종료 특성을 측정하기 위하여 사용될 수 있다. 또한 특성(metrics)들은 계획된 일정과 예산에 대한 진행상황을 평가하기 위하여 사용된다. 일반적인 테스트 특성(metrics)은 다음을 포함한다.
• 테스트 케이스 준비에서 작업된 퍼센티지(또는 준비된 테스트 케이스의 준비된 퍼센티지) • 테스트 환경 준비에서 작업된 퍼센티지 • 테스트 케이스 실행(e.g 수행된/수행되지 않은 테스트 케이스의 숫자, 패스된/실패된 테스트 케이스의 숫자) • 결함 정보(e.g 결함 조밀도, 발견된 결함과 고쳐진 결함, 실패 비율, 재테스트 결과) • 요구사항, 위험 또는 코드의 테스트 커버리지 • 제품에 대한 테스터의 주된 확신 • 테스트 마일스톤의 일정 • 테스트 비용, 다음 결함을 발견하는 혜택이나 다음 테스트를 실행하는 비용을 포함하는,
5.3.2 테스트 보고 (K2)
테스트 보고는 다음을 포함하는 테스팅 결과에 대한 정보를 요약하는 것에 관심을 갖는다.
• 언제 종료 특성을 만족했는가와 같은 테스팅 기간 동안에 무슨일이 있어났는가? • 미래의 액션에 대한 충고와 결정을 지원하기 위한 남겨진 결함의 평가, 연속된 테스팅의
경제적인 혜택, 눈에 띄는 위험, 그리고 테스트 된 소프트웨어에 대한 확신의 레벨과 같은 분석된 정보와 특성들
특성들은 테스팅 동안에 수집되어야 하고, 테스트 마지막에 평가하기 위하여 수집되어야 한다.
• 테스트 레벨에 대한 테스트 목적의 타당성 • 수행된 테스트 방법의 타당성 • 테스팅 목적 측면에서의 테스팅의 효과
5.3.3 테스트 통제 (K2)
테스트 통제는 수집되고 보고된 정보와 매트릭의 결과로서 취해진 모든 지침이나 올바른 행동을 묘사한다. 액션들은 모든 테스트 액티비티를 커버할 수 있으며, 다른 소프트웨어 수명주기 액티비티나 작업에 영향을 줄 수 있다.
테스트 통제 액션의 예는 다음과 같다.
• 정의된 위험이 발생할 때 테스트를 다시 우선 순위화 한다. (e.g 늦게 인도된 소프트웨어) • 테스트 환경의 가용성이 원인이된 테스트 일정의 변경 • 구축시 승인에 앞서 개발자에 의하여 다시 테스트 되어야 하는 수정을 요하는 항목 특성(entry criterion)의 설정
▪ 단순한 결함 이외의 측정해야 할 다른 것들이 존재 ▪ 순간 포착류 측정치 보다는 경향을 리포팅 ▪ 리포트의 영향력(impact)을 높이기 위해 리포트 양을 제한 ▪ 리포팅의 일관성 유지 ▪ "측정"의 의미를 설명 - 당연하다고 가정하지 말것 ▪ 쉽게 구분되는 색 이용 ▪ 일관성 있는 Look and Feel ▪ 빨간색은 "위험"을 의미함 ▪ 누적된 총계는 경향(Trends)을 찝어 나타내줌 ▪ 중요한 것은 내용(Content)임
5.4 Configuration management (K2)
구성관리의 목적은 프로젝트와 제품 수명주기(product life cycle)를 통하여 시스템이나 소프트웨어의 산출물(컴포넌트, 데이터 그리고 문서)을 통합하고, 유지하는 것이다.
테스팅에서 구성 관리는 다음을 보장하는 것을 포함할 수 있다.
• 테스트웨어의 모든 항목들은 정의되고, 버전 컨트롤되고, 변경에 대한 추적이 가능하고, 다른 항목들과 연관될 뿐만 아니라, 개발 항목들과도 연관되어 있기에 테스트 프로세스 동안의 추적성은 유지될 수 있다.
• 모든 정의된 문서와 소프트웨어 항목은 테스트 문서에서 명확하게 참조된다.
테스터들은 구성관리를 통해서 테스트된 항목, 테스트 문서들, 테스트들과 테스트 업무를 정확하게 정의햘 수 있다.
테스트 계획 동안에, 구성 관리 절차와 하위구조(도구)가 선택되고, 문서화되며, 구현되어야 한다.
5.5 Risk and testing
위험이란 발생 가능한 이벤트, 장애, 위협을 가리키며, 이것으로 인한 의도되지 않은 결과 즉, 잠재적 문제도 위험 이라고 할 수 있다. 위험의 레벨은 불리한 이벤트의 발생 가능성과 (불리한 이벤트의 결과로 나타나는 손해의)영향에 의하여 결정될 것이다.
5.5.1 프로젝트 위험(Project risk) (K1,K2)
프로젝트 위험이란 프로젝트 목표 달성을 위한 프로젝트의 특성의 주위에 있는 위험들이다.
• 공급자 이슈사항 - 서드 파티 제품의 실패(failure) - 계약상의 문제
• 조직적인 요소(Organizational factors) - 기술과 직원의 부족 - 개인적인 훈련 문제 - 다음과 같은 정치적인 문제 + 테스터들의 필요사항과 테스트 결과를 전달하는 것에 의사소통의 문제 + 테스팅과 리뷰에서 발견된 정보를 처리하는 것에 대한 실패
(e.g 테스팅 동안에 발견된 결함 값을 인정하지 않음) - 테스팅이나 테스팅의 예상치에 대한 부적당한 태도
• 기술적인 이슈사항 _ 올바른 요구사항을 정의하는 문제 _ 주어진 기존의 제약을 만족할 수 있는 요구사항의 확장 _ 디자인, 코드 기르고 테스트의 품질
이러한 위험들을 분석하고 관리하고, 완화시키고자 할 때, 테스트 매니저는 제대로 확립된 프로젝트 관리 원칙을 따라야 한다. "소프트웨어 테스트 문서화를 위한 표준"(IEEE 829)에는 테스트 계획시 위험과 우발상황에 대해서 언급되어야 한다는 것을 약술 하고 있다.
5.5.2 제품 위험 (K2)
소프트웨어나 시스템에서의 잠재적인 실패 영역(불리한 미래 이벤트나 위협)은 제품의 품질에 대한 위험으로 다음과 같은 제품 위험으로 알려져 있다.
• 에러 경향이 있는 소프트웨어의 처리 • 개인이나 회사의 손해의 원인이 될 수 있는 소프트웨어/하드웨어의 잠재성 • 빈약한 소프트웨어 특성들(e.g 기능성, 보안성, 신뢰성, 가용성 그리고 성능) • 의도한 기능을 수행하지 않는 소프트웨어
위험은 어디에서 테스팅을 시작하고 어디에 더 테스팅을 해야 하는지를 결정하는데 사용된다. 테스팅은 좋지 않은 효과가 일어나는 위험을 줄이거나, 좋지 않은 효과의 영향을 줄이기 위하여 사용된다.
제품 위험은 프로젝트의 성공에 대한 특별한 종류의 위험이다. 위험을 통제하는 액티비로서 테스팅은 심각한 결함 제거의 효과와 우발적인 계획의 효과를 측정함으로써 남은 위험에 대한 피드백을 제공한다.
위험에 기반한 테스팅 방법은 프로젝트의 초기 단계에서 시작시, 제품 위험의 수준(level)을 줄이는 선행적인(proactive) 기회를 제공한다. 이것은 제품 위험의 정의를 포함하고 테스트 계획, 명세, 준비와 테스트들의 실행을 지도하는데 사용한다. 위험 기반 접근 방법에서, 정의된 위험은 다음을 하는데 사용될 수 있다.
• 사용되어야 하는 테스트 기법을 정의한다. • 수행되어야 하는 테스팅의 범위를 결정한다. • 가능한 한 쉽게 심각한 결점을 발견하기 위한 시도시에 테스팅의 우선순위를 정한다. • 위험을 줄이기 위하여 사용될 수 있는 모든 비 테스팅 액티비티를 결정한다.
위험 기반 테스팅은 위험과 이러한 위험을 처리하기 위해 요구되는 테스트 레벨을 결정하기 위한 공통의 지식과 프로젝트 이해당사자의 식견을 이끌어낸다.
제품 실패의 변경을 최소화하는 것을 보증하기 위하여, 위험 관리 액티비티는 다음을 위한 정제된 방법을 제공한다.
• 무엇이 잘못될 수 있는지(위험)를 평가한다. (그리고 정식 기반(regular basis)에 대한 재평가를 한다.) • 어떤 위험을 처리하는 것이 중요한지 결정한다. • 이러한 위험을 처리하기 위한 액션을 적용한다.
추가적으로, 테스팅은 새로운 위험의 확인을 지원할 수 있으며, 어떤 위험이 줄어야 되는지를 결정하는데 도움이 될 수 있다. 그리고 위험에 대한 불확실성을 줄일 수 있다.
5.6 Incident management (K3)
테스팅의 목적중 하나가 결함을 발견하는 것이기 때문에, 실제 결과와 예상되는 결과 사이의 불일치 사항들(discrepancies)은 부가 사항으로 로그되어야 할 필요가 있다. 부가 사항은 문제의 발견과 분류로 부터 해결방법의 수정과 확인까지 추적 되어야 한다. 모든 부가 사항이 완벽하게 관리되기 위해서, 조직은 분류을 위한 프로세스와 규칙을 만들어야 한다.
부가 사항은 개발, 리뷰, 테스팅 혹은 소프트웨어 제품의 사용중에 발생할 수 있다. 부가 사항은 코드나 동작 시스템내에서, 개발 문서, 테스트 문서 또는 도움말과 같은 사용자 정보나 설치가이드 같은 모든 종류의 문서에서 발생할 수 있다.
부가 사항 보고는 다음의 목적을 가져야 한다.
• 개발자들과 다른 관련자들에게 문제를 정의, 분리, 수정 할 수 있게 하는 피드백을 제공한다.
• 테스트 하는 시스템의 품질과 테스트의 진행사항을 추적하는 수단을 테스트 리더에게 제공한다. • 테스트 프로세스 향상에 대한 아이디어를 제공한다.
만약 부가사항이 고려된다고 알려졌다면, 테스터나 리뷰어는 일반적으로 다음의 정보를 로그한다.
• 문제 발생 일자, 발생 조직, 승인과 상태 • 범위, 심각도와 부대사건의 우선순위 • 참조, 문제를 나타내는 테스트 케이스 명세의 확인을 포함하는
부가 사항 보고의 세부 사항은 다음을 포함 할 수 있다.
• 예상되는 결과와 실제 시간 • 부가 사항이 발견된 날짜 • 소프트웨어나 시스템의 확인 또는 구성 항목 • 부가 사항이 관찰된 소프트웨어 또는 시스템 수명주기 프로세스 • 해결이 가능한 예외사항(anomaly)에 대한 설명 • 이해당사자 관심의 영향 정도 • 시스템의 영향에 대한 심각도 • 수정에 대한 긴급도/우선순위 • 부가 사항의 상태(e.g open(개방), deffed(연기), dupplicate(복사), waiting to be fixed(수정 대기), fixed awaiting confirmation test(수정후 확인 테스트 대기중) 또는 close(종료)) • 히스토리 변경, 부가사항을 고립, 수정, 그리고 수정을 확인하기 위한 측면에서 프로젝트 팀의 멤버에 의하여 취해진 액션의 시퀀스와 같은
부가사항 보고의 구조는 "소프트웨어 테스트 문서화를 위한 표준"(IEEE829)에서 커버하고 예외 보고라 불린다.
1. 결함 발견 : - 테스터의 의해 결함 보고 2. 결함 분배 : - 담당자에게 결함 분배(자동 분배) 3. 결함 수정 : - 개발자에 의해 결함 수정 4. 결함 확인 : - 보고자 및 관리자에 의해 결함 수정 확인 5. 결함 종료 : - 결함이 수정되었을 경우 결함 종료 6. 다시 1번으로..
◆ 인시던트(or 결함) 리포트 고려사항
▪ 구조화 ▪ 재현 ▪ 격리 : 디버그하지는 않음 ▪ 일반화 : 가능한 영향(damage)를 예측 ▪ 비교 : to 이전 버전 등 ▪ 문제점 요약 ▪ 압축된 내용 ▪ 의미 명확화 : 개발자의 이해를 돕기 위함 ▪ 중화 : 개발자를 비난하지 않도록 ▪ 검토 : 잘못된 결함 보고 또는 수준 낮은 (bad) 보고 방지
이 책은 프로그램이 실행될 때 일어나는 내부 동작원리를 익혀 더욱 효율적인 프로그래밍이 가능하도록 방향을 제시하였다. 특히 한권으로 CPU의 구조부터 OS 내부 동작원리까지, 프로그래밍의 가장 깊은 곳의 원리부터 상위 원리까지 순차적으로 학습할 수 있도록 했다. C에 대해서는 어느 정도 기초 지식이 있는 독자층을 주로 염두에 두고 쓰여진 책이다. 따라서 단순히 문법만 터득하여 기능적으로 구현하는 프로그램이 아니라 동작의 본질을 이해하고 프로그램을 제작할 수 있도록 하였다.
크게 세 3파트로 구성되어진 이 책에서는 CPU와 고급언어에 대해, 마지막 장에서는 운영체제의 역할과 그 구성에 대해 설명해 두었다. 이론과 실전의 연결이 가능하도록 교차되는 내용을 싣고자 노력하였다.
저자 : 한세경
한양대학교 전기컴퓨터 공학부를 졸업하고, 서울대학교 전기공학부에서 제어 및 임베디드 시스템을 전공하여 현재 SK(주) 기술원에서 근무하고 있다.
학부 1학년 때부터 삼성 소프트웨어 멤버쉽 활동을 시작한 이후 각 IT분야에서 다양한 개발 경험을 축적하였으며 4개국어에 능통할 정도로 자기 개발에 철저하다. 또한 현재 레이스 선수로 활동하는 열혈 바이크 매니아이다
목차
Part1. CPU와 친해지기 - 누구나 알기 쉬운 CPU의 구조
1장. 0과 1의 세상
2장. 논리회로
3장. 조합 및 순차 논리회로
4장. 컴퓨터의 두뇌 - CPU
5장. CPU의 필수 도구 - 레지스터와 클럭
6장. CPU의 언어 - 인스트럭션
7장. 실전 인스트럭션 셋 - MIPS
8장. 실전 CPU 설계 - MIPS의 데이터 경로
9장. 쉴틈없이 일하라 - 파이프라이닝
Part2. 인간의 말을 배운 컴퓨터 - 아무도 알려주지 않는 C의 비밀
10장. 컴파일러의 등장
11장. 변수의 정체
12장. 메모리 나누기 - 코드, 데이터, 스택, 힙
13장. 함수가 호출되기까지
Part3. 프로그램의 정부 - 운영체제(OS)
14장. OS의 정체
15. OS와 친해지기 - 핵심 OS 요소
16. OS 속 들여다 보기 - OS의 내부 동작 원리
4.1 Identifying test conditions and designing test cases
테스트 조건(test conditions)과 테스트를 설계하는 것은 여러 단계로 구성된다.
• 테스트 조건을 정의함으로써 테스트를 설계하는 것 • 테스트 케이스를 명세하는 것 • 테스트 절차 (test procedure)를 명세하는 것
프로세스는 문서가 거의 없는 매우 비형식적인 것에서 부터 매우 형식적인 것까지(이것은 다음 섹션에서 설명될 것이다.) 여러가지 방법으로 수행될 수 있다. 형식성의 레벨은 다음과 같은 테스팅 내용에 따라 다르다. - 테스팅 조 직, 테스팅과 개발 프로세스의 성숙도(maturity), 시간 제약, 관련된 사람들
테스트 설계(test design) 동안에, 테스트 조건을 정의하는 것과 같이 무엇을 테스트 할지 결정하기 위하여, 테스트 기반이 되는 문서들을 분석한다. 테스트 조건은 하나 또는 그 이상의 테스트 케이스로 검증될 수 있는 항목(item)이나 이벤트로서 정의된다.(e.g 기능, 트랜잭션, 품질 특성 또는 구조 적인 요소)
테스트 조건에서 역으로 명세와 요구사항으로 추적성(traceability)을 만드는 것은 요구사항이 변경되었을 경우의 영향 분석과 과 테스트 셋에 대하여 결정되어야 하는 요구사항 커버리지 분석을 모두 가능하게 한다. 테스트 설계 동안에 ,상세한 테스트 기법은 여러가지 고려 사항 가운데 정의된 위험에 기반하여 구현된다.
테스트 케이스 명세 동안에, 테스트 설계 기법에 의하여 테스트 케이스 들과 테스트 데이터가 개발되고 상세하게 서술된다. 테스트 케이스는 입력 값의 집합(set of input values), 실행 선행조건(execution preconditions), 예상 결과(expected results) 그리고 실행 후조건(execution post-conditions)으로 구성되며, 어떤 테스트 조건(들)을 커버하기 위하여 개발된다. "소프트웨어 테스트 문서화를 위한 표준"(Standard for Software Test Documentation) (IEEE 829)는 테스트 디자인 명세와 테스트 케이스 명세의 내용을 설명한다.
예상결과는 반드시 테스트 케이스 명세의 일부분으로 제공되어야 하며 , 출력, 테이터와 상태의 변경사항, 그리고 테스트의 또다른 결과를 포함하여햐 한다. 만약 에상 결과가 정의되지 않는다면, 그럴듯해 보이지만 잘못된 결과가 올 바른 것으로 판단 될 수 있다.
테스트 케이스는 실행가능한 순서로 작성된다.; 이것이 테스트 절차(test procedure) 명세이다. 테스트 절차(또는 수동 테스트 스크립트) 명세는 테스트 실행에 대한 액션의 시퀀스를 명세한다. 만약 테스트가 테스트 실행 도구를 이용하여 실행된다면, 액션의 시퀀스는 테스트 스크립트(이것은 자동화된 테스트 절차이다.)안에 명세 된다.
테스트 절차나 스크립트가 누눈가에 의하여 수행될 때, 다양한 테스트 절차들과 자동화된 테스트 스크립들은 테스트 절차나 자동화된 테스트 스크립트의 순서를 정의하는 테스트 실행 스케줄을 구성한다. 테스트 실행 스케쥴은 회귀 테스트(regression test), 우선 순위화(prioritization), 그리고 기술적이고 논리적인 의존관계(dependencies)와 같은 요소들을 고려해야 한다.
4.2 Categories of test design techniques (K2)
테스트 설계 기법의 목적은 테스트 조건(test conditions)과 테스트 케이스(test cases)를 정의하는 것이다.
테스트 기법의 고전적인 분류 방법은 블랙 박스 테스트와 화이트 박스 테스트로 표기하는 것이다. 블랙 박스 기법(명세 기반 기법으로도 불린다)은 컴포넌트나 시스템에 대하여 내부적인 구조에 대한 참조없이, 기능과 비기능 모두 테스트 기반 문서의 분석에 기반하여, 테스트 조건과 테스트 케이스를 유도하고 선택하는 방법이다. 화이트 박스 기법(구조적 혹은 구조 기반 기법으로 불린다.)은 컴포넌트나 시스템의 내부적인 구조의 분석에 기반한 방법이다.
대부분의 기법들은 명확하게 하나의 범위에 속한다. 나머지들은 하나 이상의 범주 요소를 갖는다. 이 요약서에서는 블랙 박스 기법으로는 명세 기반이나 경험 기반 접근 방식을 말하며, 화이트 박스 기법으로는 구조 기반 방식을 말한다.
명세 기반 기법(Specification-based techniques)의 일반적인 특징은 다음과 같다.
• 소프트웨어나 소프트웨어 컴포넌트의 모델들은, 형식적이건 비형식적이건 모두 풀어야 할 문제의 명세를 위해 사용된다. • 이러한 모델로 부터 테스트 케이스들은 체계적으로 유도될 수 있다.
구조 기반 기법(Structure-based techniques)의 일반적인 특징은 다음과 같다.
• 소프트웨어가 어떻게 구성되었는가에 대한 정보, 예를 들어 코드와 디자인은 테스트 케이스들을 유도하는데 사용된다. • 소프트웨어 커버리지 범위는 존재하는 테스트 케이스로 측정할 수 있다. 커버리지를 증가시키기 위해서 더 많은 테스트 케이스들이 규칙적으로 유도될 수 있다.
경험 기반 기법(Experience-based techniques)의 일반적인 특징은 다음과 같다.
• 경험과 지식이 있는 사람들이 테스트 케이스를 추출한다. - 테스터, 개발자, 사용자와 여러 이해 당사자(stakeholders)의 소프트웨어, 소프트웨어의 사용과 환경에 대한 지식 - 있음직한 결함(defect)과 분포에 대한 지식
▪ 명세기반 기법 - 일반적으로 공식적/비공식적 모델이 명세화를 위해 사용됨 - 테스트 케이스를 모델로부터 체계적으로 도출 - 문서기반
- Equivalence Partitioning, Boundary value analysis, Decision table testing, State transition testting, Use case testing
▪ 구조기반 기법 - SW 코드나 설계 등 구조를 보여주는 정보로부터 테스트 케이스 도출 - 소프트웨어의 커버리지 정도가 기존 테스트 케이스로부터 측정되고 커버리지를 늘리기 위하여 추가적 테스트 케이스가 체계적으로 도출
▪ 경험기반 기법 - 테스터, 개발자, 사용자 등의 지식활용 - 발생가능한 결함과 그 분포 등에 대한 지식 - 문서화 필요
4.3 Specification-based or black-box techniques
4.3.1 동등 분할 (Equivalence partitioning) (K3)
소프트웨어나 시스템의 입력은 비슷한 행위를 가지는 그룹으로 나뉘어지며 같은 그룹에 속하는 입력들은 같은 방법으로 처리 된다. 동등 분할(또는 분류)은 유효한 데이터와 유효하지 않은 데이터, 예를 들어 거부되어야 하는 값들에서 발견 될 수 있다. 분할(partitions)들은 결과, 내부적인 값들, 시간에 관련된 값들(e.g 이벤트 전후의), 그리고 인터페이스 파라미터(e.g 통합 테스팅 동안의)에 대하여도 정의된다. 테스트는 분할들을 커버할 수 있도록 설계되어야 한다. 동등 분할(EP)은 모든 레벨의 테스팅에 적용이 가능하다.
기법으로써의 동등 분할은 입력과 출력 커버리지를 얻기 위하여 사용될 수 있다. 이것은 사람을 통한 입력, 인터페이스를 통한 시스템에 대한 입력, 또는 통합 테스팅에서의 인터페이스 파라미터들에 적용될 수 있다.
4.3.2 경계값 분석 (Boundary value analysis) (K3)
각각의 동등분할의 경계에서의 행위는 더욱 잘못될 경우가 많다. 따라서 경계(boundaries)들은 결함(defect)을 포함할 것 확률이 높은 테스팅 영역이다. 분할 부분의 최대값과 최소값이 분할된 부분의 경계값이다. 유효한 분할 부분의 경계값은 유효한 경계값이다. 마찬가지로 유효하지 않은 분할 부분의 경계값은 유효하지 않은 경계값이다. 테스트는 유효한 경계값과 유효하지 않은 경계값 모두를 커버하도록 설계될 수 있다. 테스트 케이스를 설계할 때, 각각의 경계에 대한 값이 선택되어야 한다.
경계값 분석은 모든 단계의 테스트에 적용될 수 있다. 이것은 일반적으로 적용하기 쉬우며, 결함(defect)를 발견하는 능력이 높다.; 자세한 명세는 도움이 된다.
이 기법은 종종 동등 분할의 확장으로 간주된다. 그리고 인간에 의한 입력은 물론, 시간이나 테이블 경계들에 대한 입력에도 사용될 수 있다. 또한 경계값은 테스트 데이터 선택을 위하여 사용될 수도 있다.
4.3.3 의사결정 테이블 (Decision table testing) (K3)
의사결정 테이블(decision table)은 논리적인 조건을 포함하고 있는 시스템의 요구사항을 찾아내고, 내부적인 시스템의 설계를 문서화하는 좋은 방법이다. 의사결정 테이블들은 시스템이 구현해야 하는 복잡한 업무규칙(bisiness rule)을 기록하기 위하여 사용할수도 있다. 명세가 분석되고, 시스템의 조건과 동작(actions)이 정의된다. 입력 조건과 행위는 대부분의 경우 true나 false 모두를 가질 수 있는 방법(Boolean)으로 지정된다. 의사결정 테이블은 트리거 조건, 모든 입력 조건들에 대한 true, false의 조합, 그리고 각각의 조건의 조합에 대한 결과 행위를 포함한다. 테이블의 각 컬럼은 규칙과 연관된 행위의 실행의 결과로 나타나는 조건들의 유일한 조합을 정의하는 업무규칙(bisiness rule)과 관련이 있다. 일반적으로 의사결정 테이블 테스팅에 사용되는 커버리지 표준은 일반적으로 트러거 되는 조건들의 모든 조합을 커버하는 것을 포함하는 각 컬럼마다 하나의 테스트 케이스를 갖는 것이다.
의사결정 테이블 테스팅의 강점은 테스팅 동안에 실행되지 않을 수 있는 조건들의 조합을 만들어낸다는 것이다. 의사결정 테이블 테스팅은 몇가지 논리적인 결정들에 의존하는 소프트웨어의 동작(action)때의 모든 상황에 적용 할 수 있다.
4.3.4 상태 전이 테스팅 (State transition testing) (K3)
시스템은 현재의 조건이나 이전 히스토리(시스템의 상태)에 의존하는 각기 다른 결과를 보여줄 수 있다. 이러한 시스템의 측면은 상태 전이 다이어그램으로 보여질 수 있다. 상태 전이 다이어그램은 테스터가 시스템을 시스템의 상태, 상태들 사이의 전이, 상태의 변화(트랜잭션)을 일으키는 입력이나 사건 그리고 이러한 트랜잭션의 결과가 될 수 있는 행위의 관점에서 보는 것을 가능하게 한다.
테스트시의 시스템 상태 또는 객체들은 분리 될 수 있고, 식별이 가능해야 하며, 그 수가 제한된다.상태 테이블은 상태와 입력 사이의 관계를 보여주고, 무효화 될 가능성이 있는 트랜잭션을 강조하여 보여줄 수 있다. 테스트는 전형적인 상태의 시퀀스를 커버하고, 모든 상태를 커버하고, 모든 트랙잭션을 실행하고, 특정 트랜잭션의 시퀀스를 실행하거나 유효하지않은 트랜잭션을 테스트 하도록 설계 될 수 있다.
상태 전이 테스팅은 일반적으로 기술적인 자동화와 임베디드 소프트웨어 산업분야에서 더 많이 사용된다. 그러나, 이러한 기법은 특정 상태를 갖는 비지니스 객체의 모델링이나 화면 형식의 대화형 플로우 테스팅(testing screen-dialog flows)(e.g 인터넷 응용 프로그램이나 업무 시나리오)에 대해서도 역시 적용가능하다.
4.3.5 유스케이스 테스팅 (Use case testing) (K2)
테스트들은 유스케이스나 업무 시나리오에서 명세 될 수 있다. 유스케이스는 시스템 사용자에 대하여 가치있는 결과를 생산하는 시스템과 사용자를 포함하는 액터들 사이의 상호작용을 묘사한다. 각각의 유스케이스는 유스케이스가 성공적으로 작동하기 위하여 만족시켜야 하는 선행조건(preconditions)을 가진다. 각각의 유스케이스는 관찰 가능한 시스템의 상태와 결과를 가진 후행조건(post-conditions)으로 종료된다. 일반적으로 유스케이스는 하나의 주된(i.e 가장 있음직한) 시나리오와 때때로의 분기점들을 갖는다.
유스케이스는 실제로 있음직한 시스템의 사용을 통하여 "프로세스 흐름(process flows)"을 묘사한다. 따라서 유스케이스에서 유도된 테스트 케이스들은 시스템 실사용 동안의 프로세스 흐름내에 존재 할 수 있는 결함들(defects)을 발견하는데 유용하게 사용된다. 유스케이스는 종종 시나리오로서 언급되며, 고객/사용자가 참여하는 승인 테스트를 설계하는데 매우 유용하다. 유스케이스는 개별적인 컴포넌트 테스팅에서는 볼 수 없는 여러가지 컴포넌트의 간섭과 상호작용이 원인이 되는 커버되지 않는 통합적인 결함(integration defects)를 고치는데 도움이 된다.
명세서를 테스트 하는 것은 정적 블랙박스 테스트에 해당한다. 명세서를 테스트하는 것은 명세서에 대한 개괄적인 검토를 하는 첫번째 단계와 명세서에 대한 세부적인 검토를 하는 2단계로 나눌수 있다.
[명세서에 대한 개괄적인 검토]
명세서에 대한 개괄적인 검토는 당장에 버그를 찾아내는 것이 아니라 넓은 범위에서 명세서의 근본적인 문제나 간과한 부분, 누락된 부분을 찾아내는 것이다. 이러한 조사는 소프트웨어의 역할에 대한 이해를 돕는다. 이 단계에서의 가이드라인은 다음과 같다.
• 사용자 입장에서 생각하라. 고객의 요구사항을 이해하는 것은 중요하다. 이러한 요구사항을 이해한 다음에 테스트를 하여야한다. 추측은 금물이다. 이해하지 못한 부분이 있다면 반드시 이해하도록 노력해야 한다. • 존재하는 표준과 지침을 조사하라. - 존재하는 표준과 지침으로는 회사내의 용어 및 관례, 업계의 요구 사항, 정부 기준(특히 국방 관련), GUI, H/W 및 네트워크 표준 • 유사한 소프트웨어 검토 및 테스트 - 이 작업은 테스트 상황과 접근법을 생가해 보는데 도움을 준다.
[명세서에 대한 세부적인 검토]
제품 명세에 대한 고수준의 검토가 끝나면 제품의 종류와 어떤 외부적 요소가 설계에 고려되었는지 이해가 될 것이다. 이 정보를 참고하여 좀 더 자세한 테스트를 할 수 있다.
• 일반적으로 잘 만들어진 명세서는 다음의 속성을 가진다. - 완결성, 정확성, 정밀함, 명백함, 일관성, 연관성, 실행 가능성,코드의 배제, 테스트 가능성 - 이러한 속성을 충족시키지 않는 부분이 버그이며, 이는 보고의 대상이 된다. • 명세서를 검토하는 동아나 명세에 쓰여진 용어 역시 적절한가를 검토해야 한다. 명세서에서 명확히 정의되어 있는 경우는 문제가 되지 않지만 모호한 경우는 버그로 생각해야 한다.
동적 블랙박스 테스트
코드의 세부 사항에 대한 통찰 없이 소프트웨어를 테스트하는 것이 동적 블랙 박스 테스트이다. 이 경우 고객이 사용하는 것처럼 프로그램을 실행하기 때문에 동적이며, 작동 방법에대해서는 모르는 상태이기 때문에 블랙 박스 테스트이다. 일반적으로 동작 테스트라고 불리며, 효과적으로 수행하기 위해서는 소프트웨어의 역할에 대한 정의 즉 요구사항 문서 또는 제품 명세서가 필요하다. 여기서는 소프트웨어 내부에서의 동작은 알 필요가 없이 입력에 대한 출력 만을 알면된다.
[통과 테스트 (Test to Pass)와 실패 테스트 (Test to Fail)]
통과 테스트의 경우 소프트웨어가 최소한 작동한다는 사실이 확인되어야 한다. 여기에서는 소프트웨어의 성능은 시험하지 않는다. 따라서 가장 단순하고 간단한 테스트 케이스만을 적용하여 테스트한다. 테스트 케이스를 설계하고 실행할 때 항성 성공 테스트를 먼저해야 한다. 보통의 상황에서 소프트웨어가 지정된 대로 작동한다는 것을 확실히 확인한 다음에는 예외 상황 즉, 정도를 벗어난 극단적인 방법으로 소프트웨어를 취급하여 버그를 찾아야 한다. 실패 테스트는 소프트웨어의 일반적인 약점을 조사하기 위하여 전략적으로 선택된 케이스들이다.
[동등분할 (Equivalence Partitioning)]
동등 분할의 목표는 가능한 테스트 케이스의 수를 테스트하기에 충분하게 작고 처리하기 쉬운 수로 축소하는 것이다. 단 테스트 케이스의 수를 줄이려고 노력하는 동등 분할 작업을 너무 많이 하다보면 버그를 발견할 수 있는 테스트를 생략할 가능성이 있다. 또한 동등 분할은 주관적이다. 따라서 다른 작업자들이 분할을 검토하여 충분히 소프트웨어를 테스트 할 수 있는지를 판단해야 한다.
▪ Input/output space를 유한개의 상호 독립적인 집합(mutual disjoint subset)들로 나누어 관리 ▪ 등가 집합을 만든 후 각 등가집합의 원소 중 하나의 대표값을 선택하여 testcase를 선정한다. ▪ Weak Equivalence Class Testing : 등가집합의 각각에 대하여 하나의 대표값을 이용하여 test case 구성 ▪ Strong Equivalence Class Testing : 각 domain의 등가 집합들 사이의 조합으로 나타낼 수 있는 모든 경우의 수를 고려
[데이터 테스팅 (Data Testing)]
소프트웨어에 대한 간단한 견해는 데이터와 프로그램 영역으로 나누는 것이다. 데이터를 소프트웨어로 테스트하는 경우 사용자가 입력하는 정보, 얻게 되는 결과, 소프트웨어 내부의 모든 중간 결과가 정확하게 취급되는지 확인하게 된다. 복잡한 프로그램을 테스트 할 수 있게 만들어주는 비결은 경계 조건, 하위 경계조건, 잘못된 데이터 등 몇몇 개념에 기초한 동등 분할에 의하여 테스트 사례의 수를 줄이는 것이다.
▪ 테스트 대상 시스템의 입력 혹은 출력 영역의 경계 값에 초점을 맞추어 테스트 케이스 도출
▪ 경계조건(Boundary Condition) : 한 소프트웨어가 성능의 한계점에서도 잘 동작한다면 보통의 상황에서도 잘 동작할 것이다. 경계조건의 유형으로는 숫자, 속도, 문자, 위치, 장소, 크기, 양 등이 있으며, 동등 분할에 어떤 데이터를 포함할 지 결정했다면 경계에 해당하는 데이터를 선택하는 것이 좋다. ▪ 하위 경계 조건(Sub-Boundary Conditions) : 소프트웨어 내부에 있는 어떤 경계는 최종 사용자에게 나타나지 않지만 소프트웨어 테서트의 확인이 필요한 경우가 있다. 이것을 하위 경계 조건 또는 내부 경계 조건이라 한다.
[상태 테스팅 (State Testing)]
소프트웨어 테스터는 프로그램의 상태와 상태 사이의 전환 과정을 테스트해야 한다.
▪ 소프트웨어의 논리적 흐름 테스팅 : 소프트웨어의 상태와 논리적 흐름을 테스트하는 것은 동일한 문제로 모든 상태를 테스트하는 것은 간단한 프로그램을 제외하고는 불가능하다. 이런 경우 먼저 상태 도표를 만들어야 한다. 상태 도표에는 소프트웨어가 처할 수 있는 고유한 상태, 한 상태에서 다른 상태로 전환하는 입력 또는 상태, 상태가 입력 또는 선택될 때의 조건과 해당 출력 설정이 포함되어야 한다. 도표가 만들어졌다면 많은 수의 가능성을 작업 가능한 크기의 테스트 케이스로 다음 기준을 참고삼아 축소해야 한다.
- 각 상태를 최소한 한 번 거친다. - 가장 흔하고 많이 쓰이는 상태 사이의 변환을 테스트 한다. - 상태에 이르는 거의 사용되지 않는 경로를 테스트한다. - 모든 오류 상태를 확인하고 오류 상태에서 원래대로 돌아오는지 확인한다. - 무작위로 상태 변환을 확인한다.
▪ 실패 상태 테스트 : 이 경우는 소프트웨어가 장애를 일으키는 테스트 케이스를 찾는 것으로 다음의 경우이다.
- 경쟁 상태 및 잘못된 타이밍 - 반복, 스트레스, 부하 테스트
이 경우 고려해야 하는 사항으로는 다음의 두가지 사항이 있다.
- 팀의 프로그래머 또는 프로젝트 매니저는 소프트웨어를 파괴하려는 당신의 노력에 우호적이지 않다. - 프로그램을 열고 닫는 수많은 반복 작업을 수행하는 것이 불가능할지도 모른다.
▪ 이벤트, 액션, 활동, 상태, 상태, 상태전환 사이의 관계를 검증하는 테스팅 기법(모든 상태/이벤트 조합을 커버-both legal and illegal) ▪ 시스템/소프트웨어 상태기밥 행위가 명세된 내용과 일치함을 검증 ▪ 상태기반 시스템의 결함은 상태, 상태전환, 가드, 이벤트 결함 등으로 분류 ▪ 결함은 "구현이 잘못된 경우"와 "명세가 잘못된 경우"가 존재 ▪ 테스팅 절차 1. 상태-이벤트 테이블 구성 2. 전환 트리 구성 3. Legal 테스트 스크립트-테스트 케이스 구성 4. Illegal 테스트 스크립트-테스트 케이스 구성 5. 테스트 스크립트-가드 구성 ▪ 모델상의 결함(Faults in model) -• 초기 상태 누락 -• 가드(guards)가 "전환" 대신 상태에 표기 -• 가드의 중복 -• ... 인스펙션, 정적 분석(도구)로 결함 발견 ▪ 구현상의 결함(Faults in implementation) -• Extra/missing/corrupt state -• 액션이 틀리거나 누락 -• 스니크 패스(Sneak paths); 트랩 도어(trap doors).. -• ... 테스트 만이 결함을 발견하는 방법 • 테스트 스크립트 가드 구성시 - 가드가 경계값을 갖는 조건문으로 구성되어 있으면 "경계값 분석" 기법 적용 - 가드가 복잡한 조건문으로 구성되어 있으면 "Modified condition/decision coverage" 기법 적용
4.4 Structure-based or white-box techniques (K3)
구조 기반 기법/화이트 박스 테스팅은 다음의 예제에서 보여지듯 시스템이나 소프트웨어의 정의된 구조에 기반한다.
• 컴포넌트 레벨 (Component Level) :
여기서의 구조는 코드 그 자체의 구조이다. i.e 문장(statements), 결정(decision), 분기(branches)
• 통합 레벨 (Integration Level) :
여기서의 구조는 호출 트리(Call tree)가 될 수 있다. (다른 모듈을 호출하는 모듈을 내부에 가진 다이어그램)
• 시스템 레벨 (System Level) :
여기서의 구조는 메뉴 구조, 업무 프로세스 구조나 웹 페이지 구조가 될 수 있다.
이번 섹셕에서, 문장, 결정에 기반한, 두가지 코드와 관련된 구조적인 기법이 논의된다. 결정 테스팅(decision testing)에 대해서는, 컨트롤 플로우 다이어그램이 각각의 결정에 대한 선택사항을 가시화하기 위하여 사용될 수 있다.
4.4.1 문장 테스팅과 커버리지 (Statement testing and coverage)(K3)
컴포넌트 테스팅에서 문장 커버리지는 테스트 케이스 슈트(test case suite)에 의하여 동작된 실행 가능한 문장을 페센티지(%)로 평가한 것이다. 일반적으로 문장 커버리지를 증가시키기 위하여, 문장 테스팅은 특정 문장의 실행을 위한 테스트 케이스를 유도한다.
4.4.2 결정 테스팅과 커버리지 (Decision testing and coverage)(K3)
분기 테스팅과 관련된 결정 커버리지는 테스트 슈트에 의하여 실행된 결정 결과(e.g IF문에서의 true, false 옵션)들의 백분율(%)를 평가하는 것이다. 일반적으로 결정 커버리지를 증가시키기 위하여, 결정 테스팅은 특정 결정 결과를 실행하기 위한 테스트 케이스를 유도한다.
결정 테스팅은 결정 지점(decision point)을 통하여 특정 컨트롤 플로우를 생성시키는 컨트롤 플로우 테스팅(control flow testing)의 한 형식이다. 결정 커버리지는 문장 커버리지보다 강력하다. 100% 결정 커버리지는 100% 문장 커버리지를 보증하지만 반대는 그렇지 않다.
4.4.3 다른 구조 기반 기법들 (Other structure-based techniques)(K1)
조건 커버리지와 다중 조건 커버리지와 같은 결정 커버리지를 넘어서는 강력한 레벨의 구조적인 커버리지가 있다.
물론 커버리지 개념은 테스트 케이스 슈트(test case suite)에 의하여 실행된 모듈, 컴포넌트, 또는 클래스의 퍼센티지는 모듈 커버리지, 컴포넌트 커버리지, 클래스 커버리지로 표현될 수 있는 것처럼, 다른 테스트 레벨(e.g 통합 레벨)에도 적용 될 수 있다.
정적 화이트 박스 테스트는 소프트웨어를 실행하지 않은 채 설계, 구조 또는 버그의 코드를 주의 깊고 조직적으로 검토하는 방법이다. 때로는 구조 분석이라 불리며, 정적 화이트 박스 테스트를 수행하는 이유는 조기에 버그를 발견하고, 나중에 수습하기 어려운 버그나 동적 블랙박스 테스트로는 발견하기 어려운 버그를 찾아내기 위해서이다. 소프트웨어를 검토하는 사람이 독립적일수록 이 방법이 효과적이며, 특히 개발 주기의 초기 단계에서의 개략적인 테스트에 효과적이다.
[공식적인 검토(Formal Reviews)]
공식적인 검토는 아래의 네가지 필수 요소가 있다.
▪ 문제 찾기 - 틀린 항목만이 아니라 누락된 항목도 포함되며 모든 비판은 코드 작성자가 아닌 코드 자체에 집중되어야 한다. 참가자들은 비난을 개인적으로 받아들여서는 안된다. ▪ 규칙 준수 - 규칙을 따라야 한다. 규칙은 검토해야 할 코드의 양, 소요시간, 회의 내용등을 결정
한다. ▪ 준비 - 각각의 참가자는 검토에 대하여 준비하고 도움을 주어야 한다. ▪ 보고서 작성 - 검토 작업의 결과를 요약하는 문서를 작성해야 하며 이 보고서를 제품 개발 팀의 나머지 구성원에 공개하여야 한다.
확립된 절차를 따라야 공식적인 검토의 효과를 볼 수 있다. 검토가 제대로 이루어진다면 이 작업이 초기에 버그를 발견하는 데 많은 도움이 된다는 것을 증명할 수 있다. 이외에 다음과 같은 간접적인 이점을 얻을 수 있다.
- 의사소통 - 품질 - 동료의식 - 솔루션
▪ Peer Reviews (동료들의 검토) ▪ Walkthroughs (워크스루) ▪ Inspection(인스펙션) - 가장 형식적인 과정으로 참가자에 대한 교육이 필요하다.
[코딩의 표준 및 지침]
표준이나 지침을 따라야 하는 이유는 다음과 같다.
1. 표준이나 지침에 따라 코드를 작성하는 것이 신뢰도가 더 높다. 2. 표준이나 지침을 따른 코드가 읽고 이해하기 쉬우며, 유지 관리가 쉽다. 3. 쉽고 간단하게 다른 플랫폼으로 코드를 이전할 수 있다.
[일반적인 코드 검토 점검표]
코드 검토 점검표는 표준이나 지침과 코드를 비교하고, 코드가 프로젝트의 설계 요구 사항을 충족하는지를 확읺는 것으로 다음의 사항이 포함된다.
▪ 데이터 참조 오류 ▪ 데이터 선언 오류 ▪ 계산 오류 ▪ 비교 오류 ▪ 제어 흐름 오류 ▪ 서브루틴 파라미터 오류 ▪ 입력/출력 오류 ▪ 다른 검사 사항
동적 화이트 박스 테스팅
동적 화아트박스 테스트는 코드의 역할과 작동 방법을 관찰하여 얻은 정보를 사용하여 테스트 할 대상과 테스트에서 배재할 대상, 테스트 접근 방법등을 결정하는 것이다. 동적 화이트 박스는 구조적 테스팅이라고도 불리는데 이는 코드의 근본적인 구조를 관찰하고 이를 사용하여 테스트를 설계하고 수행하기 때문이다. 동적 화이트 박스 테스트는 코드의 역할을 살펴보는데 그치지 않는다. 이 테스트에서는 직접 테스트를 해보고 소프트웨어를 제어해 본다. 화이트 박스에 포함되는 네가지 영역은 다음과 같다.
1. 직접 기능, 프로시저, 서브루틴, 라이브러리를 테스트한다. 2. 최종 단계에서 완결된 프로그램의 형태로 소프트웨어를 테스트한다. 하지만 이때 소프트웨어의 동작에 대한 지식에 기초하여 테스트 사례를 조정한다. 3. 생각대로 테스트가 진행되고 있는지 살펴보기 위하여 소프트웨어에서 변수 및 상태 정보를 읽을 수 있도록 액세스 한다. 보통 테스트에서는 수행하기 어려운 동작을 소프트웨어에서 수행해 볼 수 있다. 4. 테스트 수행시 얼마나 많은 코드를 대상으로 하는지, 특히 어떤 코드를 대상으로 하게 되는지 측정한 다음 중복되는 테스트 사례를 제거하고 누락된 것을 추가하는 등 테스트를 조정한다.
[동적 화이트 박스 테스트 대 디버깅]
동적 화이트 박스 테스트의 목표는 버그 발견이다. 디버그의 목표는 버그의 수정이다. 하지만 버그가 발생하는 장소, 원인을 분리하려는 영역에서는 중복된다.
[데이터 영역(Data Coverage)]
▪ 데이터 흐름 ▪ 하위 경계 ▪ 공식과 방정식 ▪ 오류만들기 ▪ 오류 메시지 만들기
[코드 영역(Code Coverage)]
소프트웨어의 모든 모듈을 시작하고 종료하고, 코드의 모든 라인을 조사하고,모든 논리와 결정 경로를 조사해야 한다. 이렇게 세부적인 수준으로 소프트웨어를 조사하는 것은 코드 영역 분석이라 부른다. 코드 영역 분석에 액세스 하여 테스트 케이스를 실행할 때 소프트웨어의 어떤 부분을 통과하는지 봐야 한다는 점에서 동적 화이트 박스 테스트 기법이 된다. 코드 영역 분석의 가장 단순한 형태는 컴파일러의 디버거를 사용하여 프로그램에 접근할 때 방문하는 코드의 라인을 살펴보는 것이다.
▪ 프로그램 문장 및 라인 영역 (Program Statement and Line Coverage) ▪ 분기 영역 (Branch Coverage) ▪ 조건 영역(Condition Coverage)
- Statement Coverage :
프로그램내의 모든 명령문을 적어도 한번 수행하도록 테스트 케이스를 산출
- Decision Coverage :
프로그램 내의 결정 명령문이 적어도 한번은 "true"와 "false"의 결과가 되도록 테스트 케이스를 산출 - Condition Coverage :
결정 명령문 내의 각 조건이 적어도 한번은 "true"와 "false"의 결과가 되도록 테스트 케이스를 산출한다. - Decision/Condition Coverage :
결정 명령문 및 명령문내의 각 조건이 적어도 한번은 "true"과 "false"을 취하고 모든 명령문이 적어도 한번은 수행하도록 테스트 케이스 산출 - All Path Coverage :
모든 경로를 적어도 한번 수행하도록 테스트 케이스 산출
4.5 Experience-based technique (K2)
아마도 가장 널리 쓰이는 테스팅 기법은 에러를 추정하는 것일 것이다. 테스트는 테스터(tester)의 기술(skill)과 직관 그리고 유사한 시스템(similar system)과 기술에 대한 경험으로 부터 유도된다. 체계적인 기법을 확대하여 사용할 때, 직관적인 테스팅은 매우 형식적인 방법을 적용한 후에 정형적인 기법으로 쉽게 찾을 수 없는 특별한 테스트들을 정의하는데 유용할 수 있다. 하지만 이 기법은 테스터의 경험에 의존하기 때문에 효용성의 정도는 다양할 수 있다. 에러를 추정하는 기법에 대한 구조적인 접근 방식은 가능한 에러의 리스트를 열거하고 이러한 에러들을 찾아내는 테스트들을 설계하는 것일 것이다. 이러한 결점과 실패 리스트는 경험, 이용가능한 결함(defect)과 실패(failure)의 자료, 그리고 소프트웨어가 왜 실패하는가에 대한 일반적인 지식에 기반하여 만들 수 있다.
탐색적인 테스팅(Exploratory testing)은 테스트 설계(test design), 테스트 실행, 테스트 로깅과 지식의 습득을 동반하며, 테스트 목표들을 포함하는 테스트 문서에 기반하고, 타임 박스 안에서 수행된다. 이러한 접근 방식은 소량이거나 불충분한 명세와 심각한 시간의 압박이 있는 경우, 또는 매우 형식적인 테스팅을 확대하거나 보층할 때 유용하다. 이 기법은 대부분의 심각한 결함이 발견되었다는 것을 확인 할 수 있는 테스트 프로세스 점검용으로도 사용될 수 있다.
▪ 유사 SW나 기술에의 경험을 바탕으로 직감적으로 테스트하는 기법 ▪ Formal 기법과 같이 사용 ▪ Formal 기법이 찾기 어려운 결함 발견 기나능 - 테스트의 경험에 따라 효과가 다르기 때문에 리관성이 떨어지면 관리가 어렵다.
▪ 탐색적 테스팅 (Exploratory Testing) ◦ 테스트 목표를 포함하는 테스트 차터(charter)를 기반으로 정해진 시간내에 테스트 설계, 수행, 기록과 학습하는 테스팅 기법 ◦ 명세가 거의 없고 시간이 부족한 경우 ◦ Formal 기법을 보충할 경우 ◦ 가장 심각한 결함을 모두 발견했다는 것을 확인하는 목적으로 사용하는 경우 적합
▪ Error guessing ◦ 가능한 결함을 리스트업하고 이를 발견하기 위한 테스트케이스 작성 ◦ 가능한 결함(에러, 오류)은 상식, 기존 경험과 기존 데이터를 통해 도출가능
▪ 일반적인 경험과 노하우의 반영믈 - 체크리스트 ◦ 문서 기반의 테스트 케이스를 작성시에도 체크리스트의 경험과 노하우를 반영하는 노력 요구
◆ Classification Tree Method
▪ 블랙 박스 기반 ▪ 명세가 없는 경우 ▪ 비공식적 - 비공식적이라고 나쁜 기법이 아니다. ▪ 테스트 아이디어 시각화 ▪ 복잡성 처리 - 중복성을 피하고 한가지 기능만 테스트 하는 경우 회피 가능 ▪ 개발 설계 체크 ▪ 테스트 비용 측정 가능
◆ 통계적 사용기반 기법
▪ 어떤 상황에서 어떤 동작이 수행될 가능성이 높은가? ▪ 상태와 이벤트 조합 확률에 의존 (Operational profiles) ▪ 다수의 테스트 케이스 ; Operational profiles에 비례 ▪ Rare Event Testing은 확률이 낮은 이벤트에 집중
그레이 박스 테스팅
그레이 박스 테스팅은 블랙박스 테스트와 화이트 박스 테스트의 혼합한 형태로, 두 가지 테스트 형태의 경계에 존재한다. 여기서는 소프트웨어를 블랙 박스 형태로 테스트하며, 화이트 박스와 같이 상세하지는 않지만 소프트웨어의 작동 원리에 대해 알아보는
4.6 Choosing test techniques (K2)
사용하기 위한 테스트 기법의 선정은 시스템 타입, 표준의 준수, 고객 또는 계약 요구사항, 위험 레벨, 테스트 목적, 문서화 가능여부, 테스터의 지식, 시간과 예산, 개발 주기, 유스케이스 모델과 발견된 결함 타입에 대한 이전 경험을 포함하는 인자(factor)의 수에 의존한다.
정적 테스팅 기법(Static testing techniques)은 테스트되는 소프트웨어를 실행하지않는다.; 정적 테스팅 기법은 매뉴얼 리뷰 또는 자동화된 정적 분석 기법들이다.
리뷰(Reviews)는 소프트웨어 작업 산출물(코드를 포함해서)을 테스트 하는 방법이며, 동적 테스트(dynamic test)에 실행 전에 수행 될 수 있다. 수명주기(life cycle) 초기 리뷰동안에 감지된 결함(defects)들은 테스트를 실행하는 동안에 감지된 결함들보다 제거하는 비용이 적게 든다.(e.g 요구사항에서 발견된 결점)
리뷰는 전적으로 인력을 요하는 액티비티이지만, 도구를 이용하는 것 역시 가능하다. 인력을 요구하는 주된 액티비티는 작업 산출물(work products)을 시험하고, 그에 대한 논평을 하는 것이다. 요구 사항문서, 디자인 명세, 테스트 케이스, 테스트 스크립트, 사용자 가이드 또는 웹 페이지를 포함한 모든 소프트웨어 작업 산출물은 리뷰의 대상이 될 수 있다.
리뷰의 해택은 초기의 결점 발견과 정정, 개발 생산성 향상, 개발 시간 축소, 테스팅 비용과 시간의 축소, 개발 비용 축소, 더 적은 결함과 커뮤니케이션의 증가를 포함한다. 예를 들어, 리뷰는 동적 테스팅에서 발견할 수 없는 요구사항의 빠진 부분을 발견 할 수 있다.
리뷰, 정적 분석과 동적 테스팅은 동일한 목적-결함을 찾는것-을 가진다. 이들은 상호보완적이다. 각기 다른 기법들은 여러가지 종류의 결함을 효과적이고 효율적으로 찾을 수 있다. 동적 테스팅과 대조하여, 리뷰는 실패(failures)보다 결함(defects)를 찾는다.
표준의 미준수(deviations from standards), 요구사항내의 결함(requirements defects), 설계상의 결함(design defects), 불충분한 유지보수성(insufficent maintainability)과 잘못된 인터페이스 명세(incorrect interface specifications)와 같은 전형적인 결함들은 동적 테스팅보다 리뷰에서 쉽게 발견된다.
▪ SW 중간 산출물을 테스팅하는 방법 - 프로그램 코드, 요구사항 명세서, 설계 명세서 - 테스트 계획서, 테스트 설계서, 테스트 케이스, 테스트 스크립트 사용자 지침서
▪ 소프트웨어 개발 생명 주기의 앞부분에서 수행하여 결함 제거 비용이 저럼
▪ 개발 생산성 향상, 개발 시간 단축, 테스트 비용과 시간 단축 - 보다 적은 내재 결함 수와 향상된 의사 소통으로 위 사항을 가능케 한다.
▪ 테스팅 기법별로 다른 종류의 결함 발견 (상호보완적) - 리뷰 : 코드 또는 문서상의 결함 (failure는 발견하지 못함) 표준과의 불일치성, 설계 결함, 유지보수의 불충분성, 인터페이스 명세 결함 - 정적분석 : 코드의 복잡도, 구문 에러, Missing 파라미터, Dead 코드 등
Review의 필요성
▪ 테스팅 보다는 Review에서 결함을 발견하는 것이 더 효율적 - 단위 테스트에서 시간당 2~4개 정도의 결함을 발견한다면 - Code Review에서는 6~10개 정도의 결함을 발견
▪ 단위 테스트 후의 결함제거에는 많은 비용이 필요 - 통합 및 시스템 테스트에서 각각의 결함을 발견하고 수정하는 데 걸리는 시간은 10~40 M/H 정도 - Inspection은 결함당 1시간 이내 소요
▪ 빠른 결함 제거 시 시간과 비용 절감 효과가 있다. - 개발 후반기 결함을 발견하고 수정하는 경우 더 많은 결함 비용 소모 - 개발 완료 후 결함을 발견하고 수정하는 경우에는 보다 많은 결함 비용 소요
◆ Informal Review VS Technical Review
| Informal Review | Technical Review -------------------------------------------------------------------------------- 주요 목적 | 저비용 문서/코드 검토 | 기술적 문제 해결 | | 토론, 의사결정, 대안 평가, 결함발견 | | 명세서 또는 표준과의 적합성 체크 -------------------------------------------------------------------------------- 참여자 | (선택적) Pair 프로그램밍 or | 동료 또는 기술 전문가가 문서화되고 | 기술 선임자가 설계와 코드 리뷰 | 정의된 결함 발견 프로세스에 참여 -------------------------------------------------------------------------------- 문서화 여부 | (선택적) 문서화 |실무에서는 Informal 또는 formal -------------------------------------------------------------------------------- 효과 | 리뷰어에 따라 효과가 다양 | 실무에서는 Informal 또는 formal -------------------------------------------------------------------------------- 사전준비 | | 미팅 사전 준비 단계 거침 -------------------------------------------------------------------------------- 미팅 주도 및 | | 이상적으로는 Moderator가 미팅 주도 활용 도구 | | (선택적) 체크리스트, 리뷰 리포트 (문서) | | 인시던트 리스트, 경영층 참여 활동 --------------------------------------------------------------------------------
◆ 리뷰 성공 요소
▪ 각각의 리뷰가 명확하게 기정의된 목적이 있어야 함 ▪ 적합한 인력이 선택되어야 함 ▪ 결함 발견은 언제나 환영하는 분위기이고 결함은 객관적으로 표현되어야 함 ▪ People issues와 심리적인 측면이 고려되어야 함 ▪ 리뷰 기법이 적절히 적용되어야 함 ▪ 효과적/효율적인 결함 발견을 위하여 필요시 체크리스트 활용 (역할 분담도 적절히 활용) ▪ 리뷰 기법에 대한 교육 훈련 제공 (특히, 인스펙션의 경우) ▪ 경영층이 리뷰 프로세스를 지원 (프로젝트에서 리뷰 기법 적용에 충분한 일정 할애) ▪ 학습과 프로세스 개션에 대한 강조
3.2 Review process
리뷰(Reviews)는 비형식적인 것에서 부터 매우 형식적인 것(i.e 잘 구조화되어 있고, 규칙적인)까지 다양하다. 리뷰 프로세스의 형식(formaility)은 개발 프로세스의 성숙도, 법적(legal) 요구사항과 규정(regulatory) 요구사항 또는 감사 추적(audit trail)에 대한 필요성과 관련이 있다.
리뷰를 수행하는 방법은 합의된 리뷰의 목적에 의존한다. (e.g 결함의 발견, 이해의 획득, 또는 여론에 의한 논의와 결정)
3.2.1 형식적 리뷰의 단계 (Phase of a formal review)
전형적인 형식 리뷰는 다음의 주요한 단계(Phase)를 갖는다.
• 계획(Planning) :
계획 단계에서는 인력을 선발하고, 각 개인에게 역할(role)을 할당하며 문서들의 어떤 부분들을 살펴 볼 것인가를 결정한다. 그리고, 점검(inspection)과 같이 좀더 형식적인 리뷰를 위해서 시작과 좋료 조건(entry and exit criteria)을 정의한다.
• 킥 오프(Kick-Off) :
Kick-Off 단계에서는 문서를 분배하고, 참가자들에게 리뷰 목적, 프로세스, 문서들에 대해 설명한다. 그리고, 좀더 형식을 필요로 하는 리뷰들을 위해서 시작 조건을 확인한다.
• 개별 준비(Individual preparation) :
개별 준비 단계에서는 참가자 개개인들 스스로가 리뷰 미팅 전에 잠재적인 결함, 질문과 코맨트들을 기록한다.
• 리뷰 미팅(Review meeting) :
(좀 더 형식적인 리뷰 타입을 위한) 문서화 된 기록 또는 상세한 기록과 더불어 논의와 로깅을 한다. 미팅 참석자들은 결함(defects)을 처리하기 위한 충고사항을 제시하거나 결함에 대한 결정을 하기 위하여 간단하게 결함을 기록할 수 있다.
• 재작업(Rework) :
발견된 결함을 고친다. 일반적으로 작성자(Author)에 의하여 행해진다.
• 추가작업(follow up) :
사후 점검 단계에서는 처리된 결점을 확인하고 측정 기준들을 수집한다. 또한 좀더 형식적인 리뷰들을 위해서 종료 조건에 대한 확인도 한다.
3.2.2 역할과 책임 (Roles and responsibilities) (K1)
• 관리자 (Manager) :
리뷰 실행에 대한 결정을 하고, 프로젝트 일정내에 리뷰 시간을 할당한다. 그리고 리뷰의 목표가 달성되었는가를 결정한다.
• 중재자 (Moderator) :
리뷰 계획, 미팅의 운영, 그리고 미팅 후 추가 사항을 포함하는 문서 혹은 문서 셋(document set)의 리뷰를 이끄는 사람을 말한다. 중재자는 다양한 관점들 사이를 중재할 수 있으며, 때때로 리뷰의 나머지 부분을 이끈다.
• 작성자(Author) :
작가 혹은 리뷰된 문서에 대한 주된 책임을 가지고 있는 사람
• 리뷰어(Reviewer) :
특정 기술 혹은 비지니스 배경을 가지고 있는 개인 (Checker 또는 Inspector로 불려질 수 있다.)으로 필요한 준비후에 리뷰 동안에 제품에서 발견된 사항(e.g 결함)을 정의하고 묘사하는 사람. 리뷰어는 리뷰 프로세스에서 표현되는 다양한 관점과 역할을 선택할 수 있어야 하며, 모든 리뷰 미팅에 참가해야 한다.
• 필기자(또는 서기)(Scribe(or recorder)) :
모든 이슈사항, 문제 그리고 미팅 동안에 정의되어야 하는 문제점(-미정사항open points)을 문서화한다.
여러가지 관점에서 문서를 살펴보는 것과 체크 리스트(checklists)를 이용하는 것은 리뷰를 더욱 효과적이고 효율적으로 만들 수 있다. 예를 들어, 사용자, 유지 보수인력(maintainer), 테스터 또눈 운영자 같은 측면에 기반한 체크 리스트나 전형적인 요구사항 문제들에 대한 체크 리스트는 리뷰를 더욱 효과적이고 효율적으로 만들 수있다.
3.2.3 리뷰 타입 (K2)
하나의 문서는 하나 이상의 리뷰의 주제가 될 수 있다. 만약 한 종류 이상의 리뷰가 수행된다면, 순서는 매우 다양해 질 수 있다. 예를 들어 비형식적인 리뷰(informal review)를 테크니컬 리뷰(technical review)에 앞서 수행 할 수 있다. 또한 요구사항 명세에 대하여 수행되는 점검(Inspection)은 고객과 함께하는 walkthrough 전에 수행될 수 있다. 일반적인 리뷰 타입들의 주요한 특성, 옵션과 목적은 다음과 같다.
비형식 리뷰 (Informal Review)
주요 특성 • 형식적인 프로세스가 없다. • 쌍으로 하는 프로그래밍(Pair programming)이나 기술 리더가 디자인과 코드를 리뷰하는 것이 될 수 있다. • 조건적에 따라 문서화 될 수 있다. • 리뷰어에 의존하여 유용성이 변할 수 있다. • 주요 목적 : 임의의 혜택을 얻는 비용이 많이 들지 않는 방법
Walkthrough
주요 특성 • 작성자(Author)에 의해 주도되는 미팅 • 시나리오들, 리허설(dry runs), 동료 그룹 • 미 종결된 세션 • 조건적인 리뷰어들의 선 미팅 준비(pre-meeting preparation), 리뷰 리포트, 발견 사항과 필기자(scribe)의 리스트 • 실제로 상당히 비형식적인 것에서 부터 매우 형식적인 까지 다양하다. • 주요 목적 : 배우고, 이해하고, 결점을 찾는다.
기술 리뷰 (Technical Review)
주요 특성 • 문서화 되고, 동료와 기술적인 전문가를 포함하는 결함 탐지(defect-detection)을 위한 정의된 프로세스 • 관리자의 참가없이 동료가 리뷰를 함으로써 수행될 수 있다. • 이상적으로는 훈련된 조정자(작성자가 아닌)에 의하여 주도된다. • 선 미팅 준비 (pre-meeting preparation) • 때때로 체크 리스트, 리뷰 리포트, 발견 사항의 리스트를 사용하고 관리자가 참여한다. • 실제로 상당히 비형식적인 것에서 부터 매우 형식적인 까지 다양하다. • 주요 목적 : 논의, 결정, 대안 사항의 평가, 결함(defect)의 발견, 기술적인 문제 해결, 명세와 표준의 준수 확인
점검 (Inspection)
주요 특성 • 훈련된 조정자(moderator)에 의하여 주도된다. • 동료에 의한 평가가 일반적이다. • 정의된 역할 • 특성(metrics)을 포함한다. • 항목(entry)과 종료 특성(exit criteria)을 가진 규칙(rules)과 체크 리스트(checklists)에 기반한 형식적인 프로세스 • 선 미팅 준비 (pre-meeting preparation) • 점검 보고서(Inspection report), 발견사항 리스트(list of findings) • 형식적인 사후 처리 프로세스 (formal follow-up process) • 때때로, 프로세스 향상과 리더(reader)가 필요하다. • 주요 목적 : 결함의 발견
3.2.4 리뷰의 성공 요소 (K2)
리뷰의 성공 요소는 다음을 포함한다.
• 각각의 리뷰는 명확하게 미리 정의된 목표를 갖는다. • 리뷰 목적에 맞는 적절한 인력이 포함되어야 한다. • 결함의 발견은 환영되어야 하며, 객관적으로 표현되어야 한다. • 사람들의 이슈사항과 심리학적인 측면을 다룬다.(e.g 작성자에게 긍정적인 경험으로 만든다.) • 리뷰 기법이 적용되며, 리뷰 기법은 소프트웨어 작업 산출물과 리뷰어의 레벨과 종류에 적합해야 한다. • 만약 결함 확인의 효과를 증가시키는데 적당하다면, 체크 리스트와 역할이 사용된다. • 리뷰 기술에 대한 훈련을 받는다. 특히 점검(Inspection)과 같은 매우 형식적인 기법에 대해서는 • 관리자가 옳바른 리뷰 프로세스를 지원한다. (e.g 프로젝트 리뷰 액티비티에 대한 적당한 시간을 짜 넣으므로써) • 학습과 프로세스 향상에 대하여 강조한다.
▪ SW 중간 산출물을 테스팅 하는 방법 - 프로그램 코드, 요구사항 명세서, 설계 명세서 - 테스트 계획서, 테스트 설계서, 테스트 케이스, 테스트 스크립트, 사용자 지침서 ▪ 소프트웨어 개발 생명주기의 앞부분에서 수행하여 결함제거가 저렴 ▪ 개발 생산성 향상, 개발 시간 단축, 테스팅 비용과 시간 단축 - 보다 적은 내재 결함 수와 향상된 의사소통으로 위 사항을 가능케 함 ▪ 테스팅 기법별로 다른 종류의 결함 발견(상호보완적) - 리뷰 : 코드 또는 문서상의 결함 발견 (Failure는 발견 못함) 표준과의 불일치성, 설계 결함, 유지보수의 불충분성, 인터페이스 명세 결함 - 정적분석 : 코드의 복잡도, 구문에러, Missing 파라미터, Dead 코드 등
◆ 리뷰(Review)의 필요성
▪ 테스팅 보다는 Review에서 결함을 발견하는 것이 더 효율적이다. ▪ 단위 테스트 후의 결함 제거에는 많은 비용이 필요하다.
◆ 리뷰(Review) 프로세스
▪ Formal 리뷰 구성 요소 - 높은 수준의 개발 프로세스 성숙도 - 법적 또는 제도적 요구사항이 있을 때 - 감사를 받고자 할 때 ▪ 리뷰의 다양한 목적(목적에 따라 리뷰 방식이 다름) -결함 발견, 이해도 증진, 토론과 의견일치에 의한 결정
◆ 리뷰(Review) 프로세스 단계
▪ 1. 계획활동 - 역할 분담, 시작/종료 기준 정의, 검토할 문서 설정 ▪ 2. 시작(Kick-off) - 문서 배포,목표/리뷰 프로세스/문서에 대한 설명, 시작 기준(조건) 확인 ▪ 3. 개별준비 - 잠재 결함을 체크, 회의에서 제기할 질문가 코멘트 준비 ▪ 4. 리뷰미팅 - 토론하고 기록함 (보다 formal한 경우 상세 회의록 작성) - 단순한 결함 체크-> 결함 대처안 제안 -> 결함 (처리)여부를 결정 (Inspection에서는 하지 말라고 하는 것 ) ▪ 5. 재작업(rework) - 발견한 결함 수정 (typically by the author) ▪ 6. Follow-up - 발견된 결함이 처리되었는지 확인, 매트릭 수집 & 확인, 리뷰 종료 기준 체크
◆ Fagan Inspection Process (7단계)
▪ 1. Planning - Inspection 할 산출물이 entry criteria를 만족함을 확인 - Inspector 역할 할당 (Moderator, Authoer, Reader, Tester) - 다음 4단계에 대한 일정 확보 - 2.4.5 단계를 위한 회의실 확보 ▪ 2. Overview - Inspection 팀이 preparation 단계를 잘 실행할 수 있도록 배경 설명, context, rationale에 대한 교육 실시 ▪ 3. Preparation - 각자 Inspection 할 산출물의 습득 - 각자 맞겨진 역할을 수행할 수 있도록 준비 - Defect로 단정 짓지 말고 Inspection 회의 시 질문 사항 기록 ▪ 4. Inspection meeting - Find Defect (defect 해결책 또는 개선책을 거론하지 말 것) ▪ 5. Process Improvement - 향후 defect 발견을 향상 시킬 수 있도록 1~4 단계 검토 - Systemmatic defect 식별과 Recommended fixes ▪ 6. Rework - 모든 발견된 defects 수정 및 조사항목 보완 ▪ 7. Follow-up - 모든 보완 사항과 해결책이 적합한가를 검증 (20% defects의 근본 원인이 bad fixes)
◆ Inspector 역할
▪ Moderator - 7단계의 Fagan Inspection Process 실행 동안 Inspection 팀을 Lead하며 본인도 Inspector의 역할 담당, 팀의 synergy를 자극하며 phantom inspector 효과를 이끌어 냄 - 자격 요건 : Fagan defect-free process를 잘 이해하며, Inspection 할 산출물을 작성할 수 있을 정도의 기술능력을 보유하고, 여러 사람과 협력하여 일을 추진할 수 있는사람 ▪ Author - Inspection 할 산출물의 작성자이며 동시에 적극적으로 Inspector 역할 담당 - 현재 상태에서 가능한 모든 defect를 발견하는 것이 가장 중요한 사람(방어태세 지양) ▪ Reader(Reviewer) - 보편적으로 본인의 업무가 inspection할 산출물에 크게 의존될 사람이 reader로 선정됨 - Inspection 회의 시 본인이 다음 단계 업무를 수행할 수 있는 정도의 관점과 이해력을 가지고 본인이 이해한 대로 각 statement를 설명함 ▪ Tester - 어떻게 시험할 것인가에 관점을 두어서 inspection 회의 시 질문
◆ Inspection의 주요 특징
▪ 주요 목적 : 결함 발견 ▪ 저자가 아닌 훈련된 Moderator에 의한 진행 및 제어 ▪ 주로 동료 검사 ▪ 역할이 정의되어 있음 ▪ 매트릭을 수집하고 활용함 ▪ 체크리스트와 규칙을 기반으로 하는 정식 프로세스 ▪ 미팅 전 준비 과정 거침 ▪ 인스펙션 리포트와 발견사항 리스트 산출 ▪ 정식적인 결함 수정 확인 ▪ 프로세스 개선(선택적)
◆ Walkthrough의 주요 특징
▪ 주요 목적 : 결함 발견, 학습, 시스템에 대한 이해 향상 ▪ 저자에 의한 진행 및 제어 ▪ 시나리오, dry run, 동료 그룹 ▪ Open-ended 세션 ▪ (선택적) 미팅 전 준비과정 거침(리뷰어, 리뷰 리포트, 인시던트 리스트, 서기 지정) ▪ 실무에서는 Informal 또는 Formal 하게 할 수 있음
3.3 Static analysis by tools (K2)
정적 분석(Static analysis)의 목적은 소프트웨어 소스 코드나 소프트웨어 모델에서 결함(defects)을 발견하는 것이다. 정적 분석은 도구에 의하여, 시험되어지는 소프트웨어의 실제적인 실행없이 수행된다. 동적 테스팅(dynamic testing)은 소프트웨어 코드를 실행시킨다. 정적 분석은 테스팅에서 발견하기 어려운 결함들의 위치를 알아낸다. 리뷰와 더불어, 정적 분석은 실패(failure)보다는 결함(defects)를 찾는다. 정적 분석 도구는 프로그램 코드를 분석(e.g 컨트롤 플로우와 데이터 플로우)하며, HTML과 XML과 같은 결과물을 생성한다.
정적 분석의 가치는 다음과 같다.
• 테스트 실행 이전 결점의 조기 감지 • 높은 복잡성(complexity) 측정과 같은 특성(metrics) 계산에 의한 코드 또는 설계의 의심스러운 측면에 대한 초기 경고 • 동적 테스팅에 의하여 쉽게 발견되지 않는 결함의 정의 • 링크와 같은 소프트웨어 모델에서의 의존성과 불일치성 감지 • 코드와 디자인의 유지보수성(maintainability) 향상 • 개발에서 배워진 교훈이 있다면, 결함의 방지
정적 분석 도구에 의하여 발견되는 전형적인 결점들은 다음을 포함한다.
• 정의 되지 않은 값을 가진 변수의 참조 • 모듈과 컴포넌트 사이의 일관적이지 않은 인터페이스 • 사용되지 않는 변수 • 실행할 수 없는(죽은) 코드 • 프로그래밍 표준 위반 사항 • 보안 취약성들 • 코드와 소프트웨어 모델의 구문 위반사항(syntax violations)
컴포넌트 테스팅과 통합 테스팅 하는 동안이나 그 이전에, 그리고 디자이너가 소프트웨어 모델링을 하는 동안에, 정적 분석 도구들은 일반적으로 (미리 정의된 규칙 혹은 프로그래밍 표준에 대한 확인을 위하여) 개발자에 의하여 사용된다. 정적 분석 도구는 가장 효과적인 도구의 사용을 위하여 제대로 관리되는 것이 필요한 많은 수의 경고 메시지를 만들어 낼 것이다.
컴파일러들은 특성의 계산(calculation of metrics)을 포함한 일부 정적 분석 기능을 지원할 수 있다.
1. Find defects in software source code and software models 2. Performed withtout actually executing the software being examined 3. Locates defects that are hard to find in testing 4. Finds failures rather than defects
◆ 정적 분석의 가치
▪ 테스트 수행전 결함 발견 ▪ 의심스러운 코드와 설계에 대한 조기 경보 (프로그램 복잡도 등의 매트릭을 계산해서...) ▪ 동적 테스팅에서 발견하기 어려운 결함 발견 ▪ 소프트웨어 모델에서의 의존성과 불일치성 발견 ▪ 코드와 설계의 유지보수성 향상 ▪ 결함 예방 (if lessons are learned in development)
◆ 정적 분석을 통해 발견되는 결함
▪ 정의되지 않은 값으로 변수 참조 ▪ 모듈과 컴포넌트 간에 일관되지 않은 인터페이스 ▪ 사용되지 않는 변수 ▪ 사용되지 않는 코드 (Dead Code) ▪ 코딩 표준 위반 ▪ 보안 취약성 ▪ 코드와 소프트웨어 모델의 syntax 위반
실제로 V모델에서는 소프트웨어 제품과 프로젝트에 따라서, 개발과 테스팅 레벨에 변화를 주거나 특정 레벨을 추가 또는 삭제 할 수도 있다. 예를 들어, 컴포넌트 테스트 후에 컴포넌트 통합 테스팅이 있을 수 있으며, 시스템 테스팅 후에 시스템 통합 테스팅이 있을수 있다.
개발 동안에 만들어진 소프트웨어 작업 산출물들(비지니스 시나리오 혹은 유스케이스, 요구사항 명세, 설계 문서, 코드)등은 때때로 하나 혹은 그 이상의 테스트 레벨에서의 테스팅의 기반이 된다. 일반적인 작업 산출물을 위한 참고에 CMMI나 'Software life cycle processes'(IEEE/IEC 12207)를 포함한다. 검증(Verification)과 유효성 검사(Validation) (그리고 초기 테스트 설계)은 소프트웨어 작업 산출물 개발 동안에 수행되어져야 한다.
2.1.2 반복 개발 모델(Iterative development models) (K2)
반복 개발은 요구사항 작업, 설계, 시스템의 구축과 테스팅 프로세스를 작은 개발의 시리즈로 행하는것이다. 반복 개발의 예로서는 프로토타입핑(Prototyping), RAD(Rapid Application Development), RUP(Rational Unified Process) 그리고 에자일(agile) 개발 모델이 있다. 반복동안에 만들어진 추가 부분은 개발의 한 부분으로써 여러가지 레벨에서 테스트 될 것이다.
이전에 개발된 다른 부분에 추가된, 점정 증가하는 부분적인 시스템을 형성하는, 추가 개발 부분 역시 테스트 되어야 한다.
회귀 테스팅(Regression testing)은 첫번째 반복 이후의 모든 반복에서 중요성이 증가한다. 검증(Verification)과 유효성 검사(Validation)은 각각의 인크리먼트(Increment)에서 수행되어야 한다.
2.1.3 개발 주기 모델에서의 테스팅(K2)
모든 개발 주기 모델에는, 좋은 테스팅의 몇가지 특성이 있다.
• 모든 개발 액티비티와 관련있는 테스팅 액티비티가 있다. • 각각의 레벨은 그 레벨에 맞는 테스트 목표를 가진다. • 주어진 레벨에 대한 테스트의 분석과 설계는 관련된 개발 액티비티 동안에 시작되어야 한다. • 개발 수명 주기 모델에서 문서들의 배포판들이 이용가능하게 되면, 문서 리뷰시 반드시 테스터들이 포함되야 한다.
테스트 레벨들은 시스템 아키텍쳐나 프로젝트의 본질에 의존하여 조합되거나 재조직되어야 한다. 예를 들어, 사용 소프트웨어 제품의 시스템의 통합을 위해, 구매자는 시스템 레벨의 통합 테스트(예를 들어 다른 시스템과 기반 구조(Infrastructure)에 대한 통합 혹은 시스템 배치(Deployment))와 승인 테스트(기능/비기능 테스트, 그리고 사용자/운영 테스팅)를 수행해야 한다.
명시된 요구사항들을 만족하는지 여부를 확인하기 위해 개발단계 말이나 중간에 구성요소나 시스템을 평가하는 프로세스(IEEE/ANSI) * 특징 :
컴퓨터 기반 테스팅(Compoter-Based Testing) - 실제적으로 소프트웨어를 실행한다.
* 종류 :
하위 레벨 테스팅 (Low-Level-Testing)과 상위 레벨 테스팅(High-Level-Testing) - 하위 레벨 테스팅 - 단위 테스팅(Unit Testing)과 통합 테스팅(Integration Testing) - 상위 레벨 테스팅 - 사용성 테스팅(Usability Testing), 기능 테스팅(Function Testing), 시스템 테스팅(System Testing), 인수 테스팅(Acceptance Testing)
Verfication
* 정의 :
개발 단계의 산출물이 그 단계의 초기에 설정된 조건을 만족하는지 여부를 결정하기 위해 구성 요소나 시스템을 평가하는 프로세스 (IEEE/ANSI) , 본격적인 구축(Implementation) 단계 이전에 요구사항 명세서, 설계 명세서, 코드등과 같은 산출물을 대상으로 평가(Evaluating), 검토(Reviewing) 점검(Inspecting)등을 하는 프로세스 * 특징 :
인간에 의한 테스팅(Human Testing) - 주로 산출물 위주의 검토 형태 * 종류 :
점검(Inspection), 워크스루(Walkthrough), 동료에 의한 검토(Buddy Checks)
각각의 테스트 레벨에 대하여 다음의 것들이 정의될 수 있다.: 테스트 레벨의 일반적인 목표들, 테트 케이스를 유도하기 위하여 참조되는 작업 산출물(e.g 테스트 기반), 테스트 목표(예를 들어 무엇이 테스트 되어야 하는가?), 발견되어야 하는 일반적인 결점(defects)과 실패(failures), 테스트 설비 요구사항과 도구 지원, 그리고 특정 테스트 방법과 책임들
2.2.1 컴포넌트 테스팅(Component Testing) (K2)
컴포넌트 테스팅은 개별적으로 테스트가능한 소프트웨어(예를 들어, 모듈, 프로그램, 객체, 클래스 등)안의 결점을 찾고, 기능을 검증한다. 컴포넌트 테스팅은 시스템의 나머지 부분과 고립되어 실행되며, 개발 생명 주기와 시스템의 내용(context)에 의존한다. 스텁(stub), 드라이버(drivers) 그리고 시뮬레이터(simulators)가 사용될 수 있다.
컴포넌트 테스팅은 기능적인 특성과 자원의 작용(예를 들어, 메모리 누수)과 같은 비기능적인 특성이나 견고성(robustness) 테스팅, 구조적인(structual) 테스팅(예를 들어 브랜치 커버리지)도 포함할 수 있다. 테스트 케이스들은 컴포넌트 명세(specification), 소프트웨어 설계(design) 혹은 데이터 모델과 같은 작업 산출물로부터 유도된다.
일반적으로, 컴포넌트 테스팅은 실제로 테스트 되는 코드를 가지고 단위 테스트 프레임윅(unit test framework) 혹은 디버깅 도구 같은 개발 환경의 지원하에 하며, 일반적으로 코드를 작성한 프로그래머를 포함시킨다. 결점(defects)들은 부가사항(incident)의 기록없이(기록할 필요 없이) 발견 되자마자 바로 수정된다.
컴포넌트를 테스팅하는 한가지 방법은 코딩전에 테스트 케이스를 준비하고 자동화시키는 것이다. 이것은 테스트 우선 접근방법(test-first approach) 혹은 테스트 주도 개발(test-driven development)이라 불린다. 이러한 접근 방법은 매우 반복적이며 테스트 케이스 개발의 주기(cycle)에 기반한다. 따라서 작은 코드의 조각들을 생성하고 통합하고 그들이 패스할 때까지 컴포넌트 테스트를 실행한다.
2.2.2 통합 테스팅(Integration Testing) (K2)
통합 테스팅은 컴포넌트들 사이의 인터페이스, 운영 시스템, 파일 시스템, 하드웨어나 시스템 사이의 인터페이스와 같은 시스템의 여러 부분에 대한 상호작용(interactions)을 테스트한다.
한 단계의 이상의 통합 테스팅이 될 수(하나 이상의 통합 테스팅 단계가 있을 수) 있으며 다양한 크기의 테스트 객체에 대하여 수행될 수 있다.
예를 들어;
• 컴포넌트 통합 테스팅은 소프트웨어 컴포넌트 사이의 상호작용을 테스트한다. 그리고 컴포넌트 테스팅 후에 행해진다. • 시스템 통합 테스팅은 여러가지 시스템 사이의 상호작용을 테스트하며 시스템 테스팅 후에 행하여진다. 이러한 경우, 개발 조직은 인터페이스의 한쪽만 통제하기 때문에 변경사항은 불안정 해질수 있다. 비즈니스 프로세스(business processes)는 시스템의 시리즈에 포함 될 수 있는 워크플로(workflow)로써 구현된다. 교차 플랫폼 문제가 중요해질 수 있다.
통합되는 범위(scope)이 커질수록, 특정 시스템이나 컴포넌트로부터 위험을 증가시킬 수 있는 실패들(failures)을 고립(isolate)시키는 것이 더욱 어려워진다.
시스템적인 통합 전략들은 시스템 아키텍쳐(하향식과 상향식), 기능적인 작업, 트랜잭션 프로세싱 시퀀스, 시스템 혹은 컴포넌트의 다른 측면들에 기반을 둘 수 있다. 늦은 결점 발견의 위험을 줄이기 위하여 통합은 한번에 모든 것을 끝내는 것(big-bang)보다는 일반적으로 점증적이어야한다.
특정 비기능적인 특성들(예를 들어 성능)의 테스팅은 통합 테스팅에 포함될 수 있다.
각각의 통합 단계에서, 테스터들은 오직 통합 그 자체에만 집중해야한다. 예를 들어, 테스터들이 모듈 A를 모듈 B와 통합한다면, 그들은 이 모듈들 사이의 커뮤니케이션을 테스팅하는데 관심을 가져야하며, 각각의 모듈의 기능에 관심을 가지면 안된다. 기능적인 접근 방법과 구조적인 접근 방법 모두 사용될 수 있다.
이상적으로, 테스터들은 아키텍쳐와 통합 계획에 영향을 주는 것을 이해하여야 한다. 만약 컴포넌트나 시스템들이 구축되기 전에 통합 테스트가 계획된다면, 테스터들은 가장 효과적인 테스팅 순서를 정할수 있다.
2.2.3 시스템 테스팅(System Testing) (K2)
시스템 테스팅은 개발 프로젝트나 프로그램의 범위에 의하여 정의된 전체 시스템/제품의 행위에 관심을 둔다.
시스템 테스팅에서, 테스트 환경은 환경으로 인한(environment-specific) 실패의 위험이 발견되지 않도록 가능한한 최종 타켓이나 생산 환경과 연관되어야 한다.
시스템 테스팅은 요구사항 명세, 비즈니스 프로세스, 유스케이스, 혹은 시스템 행위의 상위 레벨의 묘사, 운영 시스템과의 상호작용 그리고 시스템 자원이나 위험에 기반한 테스트들을 포함한다.
시스템 테스팅은 시스템의 기능요구사항과 비기능 요구사항 모두를 반드시 조사해야 한다. 요구사항은 텍스트와/혹은 모델들로 존재할 수 있다. 또한 테스터들은 불완전하거나 문서화되지 않은 요구사항도 다루어야 할 필요가 있다. 시스템의 기능 요구사항 테스팅은 테스트 되어야 하는 시스템 측면에 대한 가장 적당한 규격 기반(블랙박스) 기술을 사용하여 시작한다. 예를 들어, 의사 결정 테이블(decision table)은 비즈니스 규칙들에 설명된 효과의 조합들을 위해 만들어 질 수 있다. 그런 다음, 메뉴 구조나 웹 페이지 네비게이션과 같은 구조 기반의 기술(화이트 박스)은 구조적인 요소의 측면에서 테스팅한 성능을 평가하는데 사용될 수 있다. (See Chapter 4)
독립적인 테스트 팀이 종종 시스템 테스팅을 수행한다.
2.2.4 승인 테스팅(Acceptance Testing) (K2)
승인 테스팅은 주로 시스템의 사용자나 고객의 책임이다. 물론 다른 이해당사자가 포함될 수 있다. 승인 테스팅의 목적은 시스템, 시스템의 부분이나 시스템의 특정 비기능적인 특성들에 대한 확신을 갖는 것이다. 결점을 발견하는 것이 승인 테스팅의 중점사항은 아니다. 승인 테스팅은 비록 절대적으로 시스템의 최종 단계의 테스팅은 아니지만, 시스템의 사용과 배치를 위한 시스템의 준비정도를 평가할 수 있다. 예를 들어, 대규모 시스템의 통합 테스팅은 시스템에 대한 승인 테스팅 다음에 할 수 있다.
승인 테스팅은 단일 테스트 레벨보단 여러 레벨에서 일어날 수 있다. 예를 들어
• 상용 소프트웨어 제품(COTS software product)은 설치되거나 통합되기 전에 승인 테스팅을 받을 수 있다. • 컴포넌트의 가용성(usablity) 승인 테스팅은 컴포넌트 테스팅 동안에 행해질 수 있다. • 새로운 기능 향상을 위한 승인 테스팅은 시스템 테스팅 전에 행할 수 있다.
승인 테스팅의 전형적인 형식은 다음을 포함한다.
사용자 승인 테스팅(User acceptance testing) 일반적으로 비즈니스 사용자에 의하여 시스템의 사용에 대한 적합성(fitness)을 검증한다.
운영 (승인) 테스팅 (Operational (acceptance)testing) 시스템 관리자에 의하여 행하여지는 시스템의 승인 테스팅은 다음을 포함한다.
• 백업과 복원(restore)의 테스팅 • 재난시 복구(recovery) • 사용자 관리 • 관리 작업 • 주기적인 보안 취약점의 확인.
계약, 규정 승인 테스팅 (Contract and regulation acceptance testing)
계약 승인 테스팅은 맞춤형으로 개발된 소프트웨어에 대하여 생산된 계약자의 승인 특성(acceptance criteria)에 대하여 수행된다. 규정 승인 테스팅은 정부나 법률 혹은 안전 규정과 같은 반드시 지켜야 하는 모든 규정(regulations)에 대하여 수행된다.
알파, 베타(또는 필드) 테스팅 (Alpha and beta (or field) testing)
시장제품, 상용제품, 또는 소프트웨어의 개발자는 때때로 시장에 소프트웨어 제품을 상업적으로 판매하기에 앞서, 잠재고객이나 기존의 고객들로부터 피드백을 받기를 원한다. 알파 테스팅은 개발 조직의 사이트에서 수행된다. 배타 테스팅 혹은 필드 테스팅은 사람들에 의하여 그들이 있는 장소에서 수행된다. 두가지 제품의 개발자가 아니라 모두 잠재적인 고객에 의해여 수행된다. 여러 조직들에서는 고객 사이트에 이동하기 전과 후에 테스트 되어야 하는 시스템에 대하여 제조 승인 테스팅(factory acceptance testing)과 사이트 승인 테스팅(site acceptance testing)과 같은 다른 용어를 사용할 수 있다.
▪ 한번에 총체적으로 조직화되고 관리되는(하는) 테스트 활동 - Unit, Integration, System, Acceptance Test Level - SW/HW 모두 포함한다. ▪ 독립적 테스트 계획 ▪ 독립적으로 테스트 된다. ▪ 독립적 테스트 환경
알파 릴리즈
몇몇 주요 고객 또는 마케팅 시연 목적으로 제한된 숫자만 배포되는 초기 빌드. 실제 사용을 위해 제작된 빌드는 아니다. 알파 릴리즈를 사용하게 될 사용자는 빌드의 정확한 컨텐트와 제한된 품질 수준을 이해하고 있어야 한다.
베타 릴리즈
잠재적 고객에게 광범위하게 배포되는 공식적인 빌드. "버그 파티 및 베타 테스트"에서 베타 테스트를 수행하는 특정한 이유를 정의해야 한다는 점을 기억하라
테스팅은 소프트웨어 개발 공정 중에서 가장 노력과 비용이 집중적으로 투자되는 작업으로 기능과 성능을 확인하는 작업이다. 일반적으로 오류의 종류와 프로그램이 비교 테스트되는 기준에 따라 단위 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅과 같은 네가지 성격의 테스팅 방법이 있다.
1. 단위 시험 (Unit Testing, Component Testing)
단위 시험은 소프트웨어 설계의 기본 단위인 모듈 내부적인 오류를 발견하기 위한 시험이다. 단위 시험은 화이트 박스 방식과 블랙 박스 방식으로 수행할 수 있으며 일반적으로 화이트 박스 중심의 시험을 사용한다.
단위 시험시 결과 테이터 구조에 대한 조사, 제어 흐름에 정확성에 대한 조사, 최대점, 최소점 바로 위와 아래의 데이터 값들의 조사하는 테스트 케이스들은 오류를 쉽게 발견할 수 있다는 것을 알 수 있다. 모듈은 독립형 프로그램이 아니기 때문에 시험시 드라이버나 스텁이 필요하다. 그러나 드라이버와 스텁은 개발될 소프트웨어에 포함될 사항이 아니므로 시험시의 오버헤드에 해당한다. 하지만 오버헤드를 줄이기 위해 간단하게 드라이버와 스텁을 구성하는 것은 적절한 시험을 불가능하게 한다.
▪ 하나의 소프트웨어 모듈이 정상적으로 기능을 수행하는지의 여부를 테스트
▪ 원시 코드를 시험 대상으로 하며 주된 테스트 방법은 화이트 박스 테스트임
▪ 단위 프로그램별로 설계서 상에 정의된 기능을 제대로 수행하는지 검증
▪ 해당 개발자에 의해서도 수행될 수 있으나 타개발자나 3자에 의해서도 실시
▪ 개발 과정에서 수행하는 테스트
▪ 소프트웨어 각각의 단위(모듈)을 다른 부분과의 연계성을 고려치 않고 격리하여 테스트
목적
▪ 기본적 패스(path)를 확인
▪ 모든 에러 핸들링 패스를 확인
▪ 모듈 인터페이스 확인
▪ 로컬 데이터 확인, 경계값 확인
◆ 단위 테스트 기법 - Control flow 테스트
- Condition decision (branch)
- 커버리지 테스트 (Elementary comparison test)
- 등가 분할 & 경계값 테스트
◆ 단위 테스트 완료 조건 ▪ AI(Application Integrator)가 통합 테스트로의 entry criteria를 만족시켰다고 판단하는 경우 (품질 수준을 개발 프로젝트 리더, 팀 리더가 결정) - 기 결정한 테스트 커버리지 달성 - 특정 테스트 기법 사용 확인 - 단위 테스트 케이스와 결과 검토 및 워크스루를 통해 결정 ▪ QA enterance 조건을 만족시킴 (통합테스트와 단위테스트를 구별하지 않는 경우) ▪ 개발 관리자가 완료로 결정함(일반적인 경우)
2. 통합 시험
각 모듈들에게 서비스를 요청하고 그 결과를 정확하게 연결시켜 주는 부분의 역할이 중요하다. 문제점은 모든 모듈을 하나로 만드는 인터페이싱이다. 통합 시험은 이와 같은 인터페이싱과 관련된 오류를 발견하는 시험을 수행하고 동시에 프로그램 구조를 구성하는 체계적인 기법이다. 이 시험의 목적은 모듈이 시험한 단위를 택하여 설계에서 지시한 프로그램 구조로 구성하는 것이다.
모든 모듈을 사전에 미리 결합하고 전체 프로그램을 하나로 시험하게 되면, 대단히 혼란스러운 결과가 나타나고 많은 오류가 발생한다. 전체 프로그램이 광범위해서 생기는 여러 원인을 제거하는 작업이 복잡하기 때문에 수정 작업도 어렵다. 일단 이러한 오류들이 수정되면, 새로운 오류들이 나타나고 끝도 없이 이러한 과정이 지속된다. 이와 같은 문제점을 제거하기 위해서는 체계적인 접근이 필요하며 조금씩 통합하고, 통합 후 시험하는 작업을 반복하는 것이 현명한 방법이 된다. 점증적 통합(Incremental Integration)을 이용하여 프로그램을 작은 단위로 추가해가면 시험해 나가면 오류를 정확히 찾아낼 수 있으며, 수정하는 것도 쉽고, 인터페이스를 완벽하게 시험할 수 있어서 체계적인 시험 접근법을 적용시킬 수 있다.
▪ 시스템이나 시스템 구성요소(component) 또는 소프트웨어 프로그램의 데이터 및 기능의 인터페이스가 정상적으로 작동하는지에 중점을 두고 수행하는 테스트 ▪ 단위 테스트들 통과한 개발 소프트웨어/하드웨어 컴포넌트(모듈)간 인터페이스 및 연동 기능 등을 구조적으로 접근하여 테스트 하는 방법 ▪ 개발자가 효과적(effective)으로 테스트 할 수 있는 방법 단위 테스트로 개발자가 테스트에 흥미를 잃을 수 있음 ▪ 테스트 라이프사이클에서 단위 레벨과 시스템 레벨의 중간 레벨을 테스트
◆ 통합 테스트 종류
- 빅뱅 통합 - Bottom up 통합 - Top down 통합 - 백본 (Backbone) 통합 - 중심(Central) 통합, 협업(Collaboration) 통합, 계층(Layer) 통합, C/S 통합
3. 시스템 시험
소프트웨어는 대형 컴퓨터 시스템의 하나의 요소일 뿐이다. 소프트웨어는 다른 시스템 요소인 하드웨어, 정보들과 통합되어 일련의 시스템 통합과 검증 시험이 수행된다. 이러한 시험은 소프트웨어 개발자가 단독으로 수행하는 것이 아니다. 그러나 소프트웨어 설계와 시험동안에 수행된 단계들은 대형 시스템에서 성공적인 시스템 통합의 가능성을 크게 향상시킨다.
시스템 시험은 컴퓨터 시스템을 완벽하게 검사하는 주요 목적을 가진 일련의 또 다른 시험 방법이다. 비록 시험이 다른 목적을 갖고 있어도 모든 작업은 모든 시스템 요소가 적절히 통합되고 할당된 기능을 수행하는지를 검증한다.
▪ 실 사용 환경과 동일한 모의 시스템을 구성 ==> Environment Specific failure을 일으킬 risk를 최소화 ▪ 시스템 성능과 관련된 고객의 요구사항이 완벽하게 수행되는지를 테스트 ▪ 시스템 시험을 성공적으로 수행하기 위해서는 성능 요구사항을 명확히 하여야 함 ▪ 현장에서 적용 가능한 시스템 테스트: 스트레스 테스트와 볼륨 테스트 ▪ 단위/통합 시험이 완료되어 기능상 문제가 없는 상태여야 함 ▪ 개발 조직과 테스트 조직이 원활히 정보를 공유하고 협력하여야 함
◆ 시스템 테스팅의 기반 - 요구사항 명세서
(요구사항은 주로 텍스트 또는 모델의 형태로 존재하지만 불완전하고 문서화하지 않은 요구사항이 대부분이다.) - 리스크 분석 결과 - 비지니스 절차 - 유스케이스 - 상위 레벨의 시스템 행동 기록 문서 - OS, 시스템 리소스와의 상호작용
◆ 시스템 테스팅은 기능적 요구사항과 비기능적 요구사항을 커버
▪ 기능적 요구사항 테스트 기법 - 명세 기반 기법(Black-box) : Decision Table ▪ 비기능적 요구사항 테스트 기법 - 구조기반 기법(White-box) : 메뉴 구조 또는 웨 페이지 네비게이션 등의 구조적 요소에 대한 테스팅 커버리지(thoroughness) - 성능 테스트 - 보안 테스트
4. 인수 시험
주문 소프트웨어가 고객을 위하여 구축된 경우, 고객의 모든 요구사항을 만족하는지 확인하도록 하는 인수 시험(Acceptance test)가 수행된다. 인수 시험은 시험 드라이브에서 계획적이고 체계적으로 수행되는 일련의 시험까지 포함되어 실시된다. 대부분의 소프트웨어 개발자는 최종 사용자만이 찾을 수 있는 오류를 발견하기 위하여 알파 테스트와 베타 테스트를 수행한다. 알파 테스트는 고객이 개발자의 위치에서 실행하는 시험이다. 이때 소프트웨어 개발자가 참여하여 오류와 사용법 문제를 기록하면서 사용자에게 도움을 줄 수 있는 통제된 환경에서 수행된다. 반면에 베타 테스트는 개발자가참여하지 않은 상황에서 실질적으로 프로그램을 실행하여 사용하는 환경에서 수행된다. 고객은 베타 시험에서 발생한 문제를 기록하여 개발자에게 보고하고, 개발자는 이를 바탕으로 소프트웨어를 수정한다.
▪ 계약상의 요구 사항이 만족되었는지를 확인하기 위해, 설치 후 구입자 운영 환경에서 납품자도 참가하여 구입자에 의하여 실시되는 시스템 또는 기능 단위의 공식 테스트 ▪ 이 결과를 기초로 고객(구매자)이 개발된 시스템을 인수할 것인지를 결정
여러 종류의 테스트 액티비티들의 목적은 특정 이유나 테스팅의 대상에 기반한 소프트웨어 시스템(또는 시스템의 일부분)을 검증하는 것이 이다.
한 테스팅의 타입은 특정한 테스트 목표에 초점을 두며, 소프트웨어에 의하여 수행되어야 하는 기능을 테스팅할 수 있다 - 신뢰성(reliability)또는 가용성(usability)와 같은 비기능적인 특성들, 또는 소프트웨어나 시스템의 아키텍쳐(architecture)나 구조(structure), 또는 관련된 변경사항들, 예를 들어 결함(defect)가 고쳐졌다는 다는 것을 확인하는 것 (확인 테스팅)과 의도되지 않은 변경 사항을 찾는 것(회귀 테스팅)등을 테스팅 할 수 있다.
소프트웨어의 모델은 개발될 수 있으며 구조적 테스팅(structural testing)과 기능적 테스팅(functional testing)에 사용될 수 있다. 기능 테스팅에서의 프로세스 플로우 모델(process flow model), 상태 전이 모델(state transition model) 또는 일반적인 언어 명세, 그리고 구조적인 테스팅에서의 컨트롤 플로우 모델(control flow model) 또는 메뉴 구조 모델(menu structure model)을 예로 들 수 있다.
2.3.1 기능 테스팅 (functional testing) (K2)
시스템, 서브 시스템, 또는 컴포넌트의 기능(function)이 수행하여야 하는 것은 요구사항 명세, 유스케이스 또는 기능 명세나 문서화되지 않은 무엇과 같은 작업 산출물(work product)에 설명되어 있을 수 있다. 이러한 기능들(functions)들은 시스템이 무엇(what)을 하는가 이다.
기능 테스트들은 (문서에 기술되어 있거나 테스터에 의하여 이해된) 이러한 기능(functions)과 특성(features)에 기반하며, 모든 테스트 레벨에서 수행되어 질 수 있다. (예를 들어, 컴포넌트에 대한 테스트는 컴포넌트 명세에 기반할 수 있다.)
소프트웨어나 시스템의 기능으로 부터 테스트 조건(test conditions)과 테스트 케이스를 유도하는데에 명세 기반 기법들(specification-based technique)이 사용될 수 있다. (4장을 보라). 기능 테스팅은 소프트웨어의 외부적인 동작을 고려한다. (블랙 박스 테스팅)
기능 테스팅의 한 타입인 보안 테스팅(security testing)은 악의적인 외부(mailcious outsiders)로 부터의 바이러스와 같은 위협의 감지와 관련된 기능을 조사한다.
2.3.2 소프트웨어 제품 특성의 테스팅 (non-functional testing) (K2)
비기능 테스팅(Non-functional testing)은 성능 테스팅(performance testing), 부하 테스팅(load testing), 스트레스 테스팅(stress testing), 사용성 테스팅(usability testing), 상호연동 테스팅(interoperability testing), 유지보수성 테스팅(maintainability testing), 그리고 이식성 테스팅(portability testing)을 포함하지만, 이러한 것들에 의하여 제한되지는 않는다. 이것은 시스템이 어떻게(how) 동작하는가에 대한 테스팅이다.
비기능 테스팅은 모든 테스팅 레벨에서 수행될 수 있다. 비기능적인 테스팅이란 용어는 성능 테스팅에서의 응답 시간(response time)과 같이 다양한 규모의 수량화(quantified) 될 수 있는 시스템과 소프트웨어의 특성들의 측정을 요구하는 테스트를 말한다. 이러한 테스트들은 "소프트웨어 공학-소프트웨어 제품 품질"(ISO 9126)에 정의된 것과 같은 품질 모델(Quality Model)을 참조할 수 있다.
2.3.3. 소프트웨어 구조/아키텍쳐의 테스팅 (structure testing) (K2)
구조 테스팅(화이트 박스)은 모든 테스트 레벨에서 수행될 수 있다. 구조적인 기법들(structural techniques)은 한 종류의 구조의 커버리지 측정을 통하여 테스팅이 완벽한가를 측정하기 위하여 명세 기반 기법(specification-based technique) 다음으로 가장 많이 사용된다.
커버리지(Coverage)는 테스트 슈트(test suite)에 의하여 테스트 된 구조의 범위로, 처리된 항목의 퍼센티지(%)로 표현된다. 만약 커버리지가 100%가 아니라면, 더 많은 테스트들이 테스트에서 빠진 항목의 테스트를 위하여 설계되어야 한고 이러한 방식으로 커버리지가 증가한다. 커버리지 기법들은 4장에서 처리한다.
모든 테스트 레벨에서, 특히 컴포넌트 테스팅과 컴포넌트 통합 데스팅에서 문장(statements)이나 분기(decisions)와 같은 요소들의 코드 커버리지를 측정하는데 도구를 사용할 수 있다. 구조적인 테스팅은 호출 계층 구조(calling hierachy)와 같은 시스템의 아키텍쳐에 기반을 둘 수 있다.
구조적인 테스팅 접근 방법은 시스템, 시스템 통합 또는 승인 테스트 레벨에도 역시 적용할 수 있다. (예를 들어 비지니스 모델이나 메뉴 구조)
2.3.4 변경 사항에 관련된 테스팅(confirmation and regression testing)
결함이 검출되고 고쳐진 다음, 소프트웨어는 반드시 원래의 결점이 성공적으로 제거되었는지 확인하기 위하여 다시 테스트되어야 한다. 이것을 확인 테스팅(confirmation testing)이라고 부른다. 디버깅(결점의 수정)은 개발 액티비티이지, 테스팅 액티비티가 아니다.
회귀 테스팅(regression testing)은 이미 테스트된 프로그램을 변경(modification)후에 변경(들)의 결과로 커버되지 않았거나 발견되지 않은 결점을 발견하기 위하여 반복해서 테스팅하는 것이다. 이러한 결점들은 테스트 된 소프트웨어 내에 있거나 다른 연관된 소프트웨어 컴포넌트나 연관되지 않은 소프트웨어 내에 있을 수 있다. 회귀 테스팅은 소프트웨어나 환경(environment)이 변경되었을 때 수행된다. 회귀 테스팅의 확장은 이전 부터 동작해 왔던 소프트웨어 내의결점을 발견하지 못하는 위험(risk)에 기반한다.
확인 테스팅을 사용하고, 회귀 테스팅을 지원하기 위해서는 테스트는 반복적이어야 한다.
회귀 테스팅은 모든 테스트 레벨에서 수행될 수 있다. 그리고 기능, 비기능, 구조적 테스팅에 적용된다. 회귀 테스트 슈트(regression test suite)는 여러 번 수행되고 일반적으로 천천히 진화된다. 따라서 회귀 테스팅은 자동화를 위한 강력한 후보이다.
블랙 박스 테스트(Black-Box test)와 화이트 박스 테스트(White-Box test)
블랙 박스 테스트에서 테스터는 소프트웨어가 가져야할 기능을 알고 있지만, 이 기능이 어떻게 작동되는지는 볼 수 없다. 어떤 내용을 입력 했을 때 특정 출력을 얻게 되지만 테서트는 작동 원리와 이유에 대해서는 모르고 있다. 블랙 박스 테스트에서는 소프트웨어가 어떤 과정을 거쳤는지는 중요하지 않다. 결과만이 중요하다.
화이트 박스 테스트에서 소프트웨어 테스터는 프로그램의 코드에 접근하여 결과에 대한 원인을 살펴볼 수 있다. 조사한 결과에 기초하여 테스터는 특정 종류의 입력에서 오류가 발생할 가능성이 있는지 없는지에 대한 여부를 판단하고 이 정보에 따라 테스트를 수행할 수 있다.
정적 테스트(Static test)와 동적 테스트(Dynamic test)
정적 테스트는 실행 중이 아닌 제품을 테스트하는 것, 즉 조사하거나 검토하는 것을 뜻한다.
동적 테스트는 우리가 흔히 테스트 작업 이라고 생각하는 것, 즉 소프트웨어를 실행한 다음 테스팅하는 것을 뜻한다.
◆ Quality Model
▪ Functionality (기능성) : 규정된 기능 및 성능을 정확하게 충족시키는 능력 ▪ Reliability (신뢰성) : 고장없이 성능 수준을 지속적으로 유지시키는 능력 ▪ Usability (사용성) :사용자가 쉽게 이해하고 배울 수 있게 하는 능력 ▪ Efficieny (효율성) : 부하변동에 대한 자원의 효율적인 운영 능력 ▪ Maintainability (유지보수성) : 소프트웨어의 수정, 개선을 용이하게 하는 능력 ▪ Portability (이식성) : 다양한 운영 환경에 적응할 수 있는 능역
◆ 테스트 종류
▪ 기능 테스팅 ▪ 비기능 테스팅 ▪ 구조적 테스팅 (Testing of SW structure/architecture) ▪ 확인/회귀 시험 (Testing related to changes)
◆ 기능 테스팅 (Functional Testing)
▪ 소프트웨어 기능 중심의 테스팅 ▪ 테스트 케이스 (대부분을 차지함) - 메뉴, 사용자 매뉴얼 챕터 제목이나 목차에서 기능 추출 - 각각의 기능에 대해 기준, 출력, 내부 조건, 내부 상태를 파악하여 테스트 케이스 작성
◆ 비기능 테스팅 (Non-functional Testing)
▪ 소프트웨어 제품 특성을 테스팅 ▪ 성능 테스팅, 부하 테스팅, 스트레스 테스팅 ▪ 사용성 테스팅 ▪ 호환성 테스팅, 유지보수 테스팅, 신뢰성 테스팅, 이식성 테스팅 ▪ 보안성 테스팅
◆ Stress, Load, Performance Testing
▪ 스트레스 테스트 - 시스템을 의도적으로 규정된 한계치 이상의 스트레스를 가하는 테스트 - 시스템이 다운될 때까지 스트레스를 가하여 최대로 견디는 지점 파악 - 시스템이 설계된대로 복원하는지 확인 ▪ 부하 테스트 - 실제 환경을 가정하고 일반적으로 부하의 최대치를 발생시켜 시스템이 안정적으로 작동하는지를 확인하는 테스트 ▪ 성능 테스트 - 비지니스 사용자가 기 정의한 성능 기대 레벨과 비교하여 측정하는 시험 - 일반적으로 모든 성능 관련 테스트를 총칭하는 용어로 쓰임
소프트웨어 시스템은 한번 배치되면(deployed), 종종 수년이나 수십년 동안 운용된다. 이 기간 동안에 시스템과 시스템의 환경은 자주 수정되고(corrected), 변경되거나(changed) 확장된다(extended). 유지보수 테스팅(Maintenance testing)은 기존의 운영되는 시스템에서 행하여지며, 소프트웨어 시스템의 변경(modification), 이전(migration) 혹은 퇴역(retirement)에 의하여 유발된다.
변경(Modification)은 계획된 성능 향상을 위한 변경(e.g 릴리즈에 기반한), 수정(corrective)에 의한 변경사항과 긴급한 변경사항, 그리고 계획된 운영 시스템이나 데이터베이스의 업그레이드, 새로 나타나거나 발견된 운영 시스템의 취약성에 대한 패치와 같은 환경의 변경을 포함한다.
이전(Migration)(e.g 한 플랫폼에서 다른 플랫폼으로)을 위한 유지보수 테스팅은 반드시 변경된 소프트웨어는 물론 새로운 환경에 대한 운영 테스트를 포함하여야 한다.
퇴역(retirement)하는 시스템에 대한 유지보수 테스팅은 긴 시간의 데이터 유지기간이 필요하다면 테이터 이전 혹은 저장에 대한 테스팅을 포함할 수 있다.
무엇이 변경되었는지에 대한 테스팅에 더하여, 유지보수 테스팅은 변경되지 않은 시스템의 부분들에 대한 대규모의 회귀 테스팅을 포함한다. 유지보수 테스팅의 범위(scope)는 기존 시스템의 크기(size)와 변경의 위험(risk)과 관련된다. 변경에 종속되어, 유지보수 테스팅은 모든 테스트 레벨에서 행하여 질 수 있으며, 일부 혹은 모든 테스트 종류에 대하여 행하여 질 수 있다.
변경 사항에 의하여 기존의 시스템이 어떻게 영향을 받는가를 결정하는 것은 영향 분석(impact analysis)라고 부른다. 그리고 영향 분석은 얼마나 많은 회귀 테스팅을 해야 하는가를 결정하는 것을 돕는다.
만약 명세서(specifications)들이 오래 되었거나 분실되었다면, 유지보수 테스팅은 어려워 질 수 있다.
