QA ≠ Test

QA(품질 보증)는 개념적인 용어이고, TEST는 QA(품질 보증)를 하기 위한 수단이자 방법이다.

TESTING/ABOUT ISTQB

[2011 실라버스 - Chapter.3] 정적 기법과 테스트 프로세스에 대해서 알아보자

품생품사(品生品死) 2020. 10. 30. 00:10
반응형

※ "개발자도 알아야 할 소프트웨어 테스팅 실무"를 기반으로 요약 ※ 

Part 3. 정적 기법

3.1 정적 기법과 테스트 프로세스

3.1.1 리뷰의 이점과 목적
리뷰는 코드를 포함하여 소프트웨어 개발 및 테스트 산출물을 검토하고 테스팅하는 방법이며, 동적 테스팅을 실행하기 전에 적절하게 수행할 수 있다.

 

- 리뷰의 이점
1. 조기 결함 발견 및 수정
2. 개발 생산성 향상
3. 개발 기간 단축
4. 테스트 비용 감소 및 시간 단축
5. 개발 수명주기 전체에 걸친 비용 감소
6. 결함 감소
7. 커뮤니케이션 향상

리뷰와 정적 분석, 동적 테스팅은 모두 결함 발견이라는 동일한 목적을 가지고 있다. 정적 기법은 동적 테스팅과는 달리 장애 자체 보다는 장애의 원인(결함)을 발결한다.

 

- 동적 테스팅보다 리뷰를 통해 발견하기 쉬운 결함의 종류

1. 표준 위반
2. 요구사항 결함
3. 개발 설계 결함
4. 불충분한 유지보수성
5. 부정확한 인터페이스 명세

3.1.2 리뷰와 테스팅
- 리스크가 높거나 중요한 기능에 한해서 테스트케이스를 도출하면서 문서를 테스트할 수 있다.

 

3.2 리뷰 프로세스

3.2.1 공식적 리뷰의 단계
ISO/IEC 29119-2 정적 테스트 프로세스
정적 테스트 준비단계 -> 리뷰/분석 단계 -> 후속 처리 확인 단계
- 공식적 리뷰의 절차
1. 계획 활동 : 참가 인원을 선정하고 역할 할당. 시작 및 종료 기준을 정의. 어떤 부분의 문서 및 코드를 리뷰할 것인지를 정한다.
2. 시작(Kick-off) : 문서 배포. 리뷰의 목표, 절차 및 문서를 참석자에게 설명
3. 개별 준비 : 미팅 전에 참석자 별로 사전 리뷰 활동을 통해 잠재적인 결함이나 회의에서 제기할 질문과 의견을 기록한다.
4. 리뷰 미팅 : 개발 준비 내용을 토의하고 이에 대한 결과를 문서로 기록한다. (상세 회의록 작성)
미팅 참석자들은 간단하게 결함을 기록하고, 결함 처리 방안을 제안하고, 결함 여부에 대해서 결정을 내린다.
5. 재작업 : 발견된 결함을 대상 문서의 저자가 수정한다.
6. 후속 처리 확인 : 발견된 결함이 조치되었는지를 확인하고 보다 공식적인 리뷰에서는 관련 측정치를 수집하고 리뷰 종류기준을 점검한다.

3.2.2 역할과 책임
- 관리자 : 리뷰의 실행 여부를 결정. 프로젝트 일정에 리뷰 시간을 할당, 리뷰의 목적 달성 여부를 확인하고 승인
- 중재자 : 문서의 리뷰를 리드한다. 리뷰 계획 , 미팅 진행 , 미팅 후속 조치의 처리 여부등을 추적하고 관리. 공식적인 리뷰 또는 인스펙션에서 중재자는 리더 또는 지도자로서의 자질을 갖춘 사람 중에서 선발하여 반드시 리뷰 중재자 교육을 받도록 한다.
- 저자 : 리뷰 대상 문서의 작성자 또는 책임자
- 검토자 : 해당 분야의 기술적 또는 비즈니스적 배경을 갖춘 사람으로 필요한 준비단계를 거친 후 리뷰 대상에서 인시던트를 발견하고 기술하는 사람이다. 검토자는 검사자 또는 인스펙터라고도 불린다. 
- 기록자 : 리뷰 미팅에서 발견된 모든 이슈, 문제점 , 미해결점 등을 기록하고 문서화한다.

테스트 전문가는 일반적으로 검토자로서 리뷰에 참여하게 된다. 이때, 테스트 전문가는 다른 검토자들과는 달리 테스팅 관점에서 발견한 결함과 검토 의견을 가지고 리뷰에 참여한다. 즉, 리뷰 대상을 테스트 케이스로 만들면서 발견한 '다른 종류'의 결함을 가지고 리뷰에 기여한다.

3.2.3 리뷰의 유형
- 비공식적 리뷰
1. 공식적인 절차가 없음
2. 페어 프로그래밍에 의한 리뷰이거나 기술 선임자가 설계와 코드를 리뷰하는 것일 수 있음
3. 선택적으로 문서화 할 수 있음
4. 리뷰하는 사람에 따라 성과가 좌우됨
5. 주요 목적 : 저렴한 방법으로 수준의 성과 달성
- 기술적 리뷰
1. 동료와 기술 전문가가 참여하는 결함 발견을 위한 문서화되고 정의된 프로세스가 존재함
2. 관리자 개입이 없는 동료 검토 형태로 수행할 수 있음
3. 이상적으로는 저자가 아닌 중재자가 미팅을 주도함
4. 미팅전 사전 준비 단계 필요
5. 체크리스트, 리뷰 리포트 , 발견한 인시던트 리스트, 관리자 참여 활용
6. 실무에서는 공식적 또는 비공식적일 수 있음
7. 공식적인 경우 문서화 필수
8. 성공적으로 진행되는 경우 검토자에 관계없이 일관되고 정량적인 효과 도출 가능
9. 주요 목적 : 기술적 문제 해결, 토론 , 의사결정 , 대안평가 , 결함발견 , 명세서 또는 표준과의 적합성 검토

- 워크쓰루
1. 저자에 의한 진행 및 제어
2. 성격 : 시나리오 사용, 예행 연습 , 동료 그룹 검토
3. 시간 및 인원수 등에 제한이 없고 상황에 따라 변경할 수 있는 세션
4. 미팅 전 준비과정 거침. 예를 들어, 미팅 전에 검토자를 지정하고 리뷰 리포트를 준비하고 발견한 인시던트 리스트를 준비하고 기록자를 지정함
5. 실무에서는 비공식적 또는 공식적일 수 있음
6. 주요 목적 : 학습 , 시스템에 대한 이해 향상, 결함 발견


- 인스펙션
1. 저자가 아닌 훈련된 중재자에 의한 진행 및 제어
2. 주로 동료 검사
3. 역할이 정의되어 있음
4. 메트릭을 수집하고 활용함
5. 체크리스트와 규칙을 기반으로 시작과 종료 조건이 있는 정식 프로세스 존재
6. 미팅 전 준비 과정 필요
7. 인스펙션 리포트와 발견사항 리스트 산출
8. 정식적인 후속 처리 확인 프로세스 존재
9. 리뷰 프로세스 개선 활동 수행
10. 주요 목적 : 결함 발견

 

인스펙션 대상은 모든 개발 산출물과 테스트 산출물 등이다. 인스펙션은 리스크 분석 결과를 활용하여 장애 발생 가능성이 높고 발생한 장애로 인한 영향이 심각할 수 있는 부분을 중심으로 진행되어야 한다. 일반적으로 비지니스와의 연관성이 높거나 , 복잡도 , 변경율 , 결함율이 높은 부분이 이헤 해당되며 , 인스펙션 할 분량을 체계적으로 계획하여 인스펙션을 수행한다.

 

This is ISTQB_0011
인스펙션 예시

 

3.2.4 리뷰의 성공 요소
- 각각의 리뷰 활동에는 명확하게 기 정의된 목적이 있어야 합니다.
- 리뷰 목적에 적합한 인력이 선택되어야 합니다.
- 결함 발견은 언제나 환영하는 분위기이고 결함은 객관적으로 표현되어야 합니다.
- 사람관련 이슈와 심리적인 측면이 고려되어야 합니다.
- 소프트웨어 개발 산출물과 검토자의 수준과 타입을 고려하여 리뷰 기법을 적절히 적용해야 합니다.
- 효과적이고 효율적인 결함 발견을 위해 필요 시 체크리스트 및 역할 분담 활용해야 합니다.
- 리뷰 기법에 대한 교육 훈련 제공, 특히 인스펙션과 같이 보다 공식적인 기법에 대해서는 교육 훈련 제공이 필수적입니다.(중재자는 별도의 교육을 반드시 이수해야 함)
- 관리자가 적극적으로 리뷰 프로세스를 지원해야 합니다.
- 학습과 프로세스 개선에 대한 강조해야 합니다.
- 리뷰 경험과 효과를 내재화 하여 지속적으로 적용하는 것이 필요 합니다.

 

3.3 도구에 의한 정적 분석

정적분석의 목적은 소프트웨어의 소스코드와 모델에서 결함을 발견하는 것이다.
- 정적분석의 특징
1. 정적 분석은 동적 테스팅으로 찾기 힘든 결함을 발견하는 것입니다.
2. 리뷰와 마찬가지로 정적 분석은 장애보다는 결함을 발견합니다.
3. 도구의 도움을 받아 수행합니다.
4. 정적 분석 도구는 프로그램 코드를 분석하는 것은 물론, HTML이나 XML과 같이 생성된 결과물로 분석합니다.


- 정적분석의 가치
1. 테스트 실행 전에 조기 결함을 발견합니다.
2. 높은 복잡도 측정치와 같은 메트릭을 계산하여 코드와 설계의 의심스러운 부분에 대한 조기 경보 합니다.
3. 동적 테스팅으로는 발견하기 어려운 결함 발견 합니다.
4. 소프트웨어 모델상의 의존도와 불칠치성 발견 합니다.
5. 코드와 설계의 유지보수성 향상 시킵니다.
6. 결함 예방이 가능 합니다.


- 정적 분석 도구를 통해 발견되는 전형적인 결함
1. 정의되지 않은 값으로 변수 참조
2. 모듈과 컴포넌트 간에 일관되지 않은 인터페이스
3. 사용되지 않는 변수
4. 사용되지 않는 코드
5. 코딩 표준 위반
6. 보안 취약성
7. 코드와 소프트웨어 모델의 구문 규칙 위반

 

Related References

- 도서 : 개발자도 알아야 할 소프트웨어 테스팅 실무

 

Software Inspection

Software Inspection There are various names for the same thing. Some call it software inspection, which also could extend to the design and its documentation, some call it code inspection which relates more to the source code. A third name would be Fagan I

www.the-software-experts.com

This is ISTQB_0012
ISTQB

요약 : iso 표준, 국제 표준 iso, 국내 표준, 표준, istqb, kstqb, 웹 qa, 모바일 qa, 앱 qa, test web

반응형