[part 3] 정적 테스팅

- 용어 - 

에픽

테스트 프로시저

액티비티 다이어그램

 

3.1 정적 테스팅 기초 - 작업 산출믈 수동으로 검사(리뷰)하거나 코드나 다른 작업 산출물을 도구 기반으로 평가(정적분석)하는 방법에 의존한다. 두 가지 유형의 정적테스팅 모두 테스트 중인 코드 또는 작업 산출물을 실제로 실행하지 않고 평가.

3.1.1 정적테스팅으로 검토할 수 있는 작업 산출물

대부분의 작업 산출물은 정적 테스팅(리뷰나 정적분석)으로 검사할 수 있음.

• 비지니스 요구사항, 기능 요구사항, 보안 요구사항과 같은 명세
• 에픽, 사용자 스토리, 인수기준
• 아키텍처 및 설계 명세
• 코드
• 테스트 계획, 테스트 케이스, 테스트 프로시저, 자동화 테스트 스크립트와 같은 테스트웨어
• 사용자 가이드
• 웹페이지
• 계약, 프로젝트 계획, 일정, 예산 기획
• 형상 및 인프라 셋업
• 엑티비티 다이어그램과 같은 모델 기반 테스팅에서 사용되는 모델

3.1.2 정적 테스팅의 효과 

• 동적 테스트 실행 전에 보다 효율적으로 결함을 발견하고 수정
• 동적테스팅으로 발견이 쉽지 않은 결함 식별
• 요구사항 불일치, 애매 모호함, 모순, 누락, 부정확, 중복 등을 식별해서 설계나 코딩의 결함 예방
• 개발 생산성 향상(예 설계개선, 향상된 코드 유지보수성)
• 개발 비용 및 기간 단축
• 테스팅 비용 및 기간 단툭
• 수명주기 후반 또는 출시 후 운영과정에서 발견되는 장애 감소로 소프트웨어 수명주기 전반에 걸친 총 품질 비용 감소
• 리뷰에 참여하는 팀원 간의 의사소통 개선

3.1.3 정적 테스팅과 동적 테스팅의 차이 - 공통된 목적은 작업 산출물의 품질을 평가하고 가능한 빨리 결함을 식별하는 것. 정적 테스팅과 동적 테스팅은 발견하는 유형의 결함이 서로 달라 상호 보완적이다.

가장 중요한 차이점 중 하나는 정적 테스팅은 소프트웨어를 심행하지 않고 결함을 직접 발견하는 것. 

정적 테스팅은 작업 산출물의 일관성과 내부 품질을 향상하기 위해 사용 하는 반면, 동적 테스팅은 일반적으로 외부에서 보이는 동작에 초점을 맞춤.

 

일반적인 정적 테스트에서의 결함

• 요구사항 결함 ( 불일치, 모호함, 모순, 누락, 부정확, 중복 등)
• 설계 결함 ( 비효율적인 알고리즘이나 데이터베이스 구조, 높은 결함도, 낮은 응집도 등)
• 코딩 결함 (정의되지 않은 값이 있는 변수, 선언했으나 사용하지 않는 변수, 도달할 수 없는 코드, 중복 코드 등)
• 표준과의 차이 ( 코딩 표준 미준수 등)
• 잘못된 인터페이스 명세 ( 호출하는 시스템과 호출되는 시스템이 서로 다른 측정 단위 사용)
• 보안 취약점 ( 오버플로우)
• 테스트 베이시스 추적성이나 불충분한 커버리지 또는 부정확성( 특정 인수 조건에 대한 테스트 누락)
• 유지 보수성 결함 ( 잘못된 모듈화, 낮은 컴포넌트 재사용성 등)

3.2 리뷰 프로세스 - 합의된 리뷰 목적에 따라 결정(결함발견, 이해 향상, 테스터와 신규 팀원 등과 같은 참여자에 대한 교육 또는 토론과 합의에 의한 결정)

 

3.2.1 작업 산출물 리뷰 프로세스 

• 계획 
• 리뷰 착수
• 개별 리뷰
• 이슈 논의 및 분석
• 수정 및 보고

계획

• 리뷰 목적, 리뷰할 문서가 전체인지 특정 부분인지, 평가할 품질 특성 등을 포함하는 범위의 정의
• 노력과 기간 추정
• 리뷰 유형에 따라 결정되는 역할, 활동, 체크리스트와 같은 리뷰 특성의 식별
• 리뷰에 참석할 인원을 선정하고 역할 할당
• 인스펙션과 같은 보다 공식적인 리뷰의 경우에는 시작 및 종료 조건 정의
• 시작 조건이 충족되는지 확인

리뷰 착수

• 작업 산출물과 이슈 기록 양식, 체크리스트, 관련된 작업산출물과 같은 기타 자료 배포
• 참가자에게 범위, 목적, 프로세스, 역할, 작업 산출물을 설명
• 참가자가 리뷰에 대해 가질 수 있는 여러 질문에 답변

개별 리뷰

• 작업 산출물 전체 혹은 부분 리뷰
• 잠재 결함, 권고사항, 질문 기록

이슈 논의 및 분석

• 식별한 잠재 결함 전달
• 잠재 결함 분석 및 담당자 및 상태 할당
• 품질 특성 평가 및 문서화
• 종료 조건을 기준으로 리뷰 결과를 평가하여 리뷰 결과 결정

수정 및 보고

• 작업 산출물에 대한 수정을 요하는 잠재 결함에 대한 결함 보고서 작성
• 리뷰한 작업 산출물에서 발견한 결함 수정(일반적으로 저자가 수정)
• 결함 정보를 적절한 사람이나 팀과 공유
• 필요한 경우 주석 작성자의 동의를 포함해 업데이트된 결함 상태 기록
• 메트릭 수집
• 종료 조건의 충족여부 확인
• 종료 조건이 충족되면 해당 작업 산출물 인수

3.2.2 공식 리뷰에서의 역할과 책임

 저자, 관리자, 촉진자, 리뷰 리더, 검토자, 서기, (인스펙션에서는 낭독자도 가능)

 

저자

• 리뷰 대상 작업 산출물 작성
• 리뷰 대상 작업 산출물 결함 수정

관리자

• 리뷰 계획 담당
• 리뷰 실행 결정
• 인력, 예산, 시간 할당
• 진행 비용 대비 효과 모니터링
• 결과가 만족스럽지 않은 경우 제어 결정 실행

촉진자

• 리뷰 회의 진행 시 효과적 회의 진행 보장
• 필요한 경우 다양한 관점들에 대한 중재
• 많은 경우 리뷰의 성공 여부에 결정적인 역할을 하는 사람

리뷰 리더

• 전반적으로 리뷰에 대한 책임을 지는 사람
• 참여를 결정하고 언제 어디서 진행할지 결정

검토자 

• 해당 주제에 대한 전문가, 프로젝트 참여 인원, 작업 산출물에 관심이 있는 이해관계자나 특정 기술 혹은 비지니스 배경을 가진 사람등
• 리뷰 대상 작업 산출물의 잠재적 결함 식별
• 다양한 관점을 대표할 수 있음.

서기

• 개별 리뷰 활동에서 발견한 잠재 결함 수집
• 리뷰 회의가 진행되는 경우 새로운 잠재 결함, 쟁점, 결정, 사항 기록

3.2.3 리뷰 유형 -리뷰를 다양한 목적으로 활용할 수 있지만, 주된 목적 중 하나는 결함 발견.

 

비공식 리뷰

(ex - 버디 체크, 페어링, 짝 리뷰)

• 주요 목적 : 잠재적 결함 발견
• 기타 목적 : 새로운 아이디어나 해결책 도출, 소소한 문제의 빠른 해결
• 공식 프로세스를 기반으로 하지 않음
• 리뷰 회의를 진행하지 않을 수 있음
• 저자의 동료 (버디 체크) 또는 다른 사람이 수행할 수 있음
• 결과는 문서로 기록할 수 있음
• 검토자에 따라 성과가 달라짐
• 체크리스트 사용 여부는 상황에 맞게 판단
• 에자일 개발에서 매우 일반적으로 사용됨

워크쓰루

• 주요 목적: 결함 발견, 소프트웨어 제품 개선, 다른 구현 방법 고려, 표준이나 규정 준수 평가
• 기타 목적: 다양한 기술이나 스타일에 대한 아이디어 교환, 참여자 교육, 합의 도출
• 리뷰 회의 전 개별 준비는 필요에 따라 수행
• 리뷰 회의는 일반적으로 작업 산출물의 저자가 주도
• 서기 참여 필수
• 체크리스트 사용 여부는 상황에 맞게 판단
• 시나리오, 드라이 런, 시뮬레이션의 형태로 수행할 수 있음
• 잠재 결함 로그와 리뷰 보고서 작성
• 실무에서는 비공식적인 형식에서 매우 공식적인 형식까지 다양할 수 있음

기술 리뷰

• 주요 목적: 합의 도출, 잠재적 결함 발견
• 기타 목적: 작업 산출물의 품질 평가 및 자신감 획득, 새로운 아이디어 도출, 저자가 미래의 작업 산출물을 개선하도록 지원하고 동기를 부여, 다른 구현 방법 고려
• 검토자는 저자의 기술 동료이면서, 동일 분야 또는 다른 분야의 기술 전문가여야 함
• 리뷰 회의 전 개별 준비 필요
• 리뷰 회의는 선택 사항이며, 이상적으로는 훈련된 촉진자(일반적으로 저자가 아닌)가 주도
• 서기는 반드시 있어야 하며, 이상적으로는 저자가 아닌 사람이 수행
• 체크리스트 사용 여부는 상황에 맞게 판단
• 잠재 결함 로그와 리뷰 보고서 작성

인스펙션

• 주요 목적: 잠재적 결함 발견, 작업산출물의 품질 평가 및 자신감 획득, 저자 학습과 근본 원인 분석을 통한 유사 결함의 발생 예방
• 기타 목적: 저자가 앞으로의 작업 산출물과 소프트웨어 개발 프로세스를 개선하고 합의를 이끌어 내도록 동기를 부여
• 규칙 및 체크리스트를 기반으로 공식 문서 산출물을 작성하는 정의된 프로세스를 수행
• 3.2.2절에서 필수로 지정한 바와 같이 명확하게 정의된 역할 참여, 낭독자 (리뷰 회의중 작업 산출물을 종종 자신의 말로 의역하고 소리내어 읽는 사람)의 참여 가능
• 리뷰 회의 전 개별 준비 필요
• 검토자는 저자의 동료 또는 작업 산출물과 연관된 분야의 전문가
• 명시된 시작 및 종료 조건을 사용
• 서기 차여 필수
• 리뷰 회의는 훈련받은 촉진자(저자가 아닌 사람)가 주도
• 저자는 리뷰 리더, 글을 읽는 사람 또는 서기가 될 수 없음
• 잠재적인 결함 로그 및 리뷰 보고서 작성
• 인스펙션 프로세스 포함 전체 소프트웨어 개발 프로세스를 개선하기 위해 메트릭을 수집하고 사용

3.2.4 리뷰 기법 적용

개별 리뷰 활동 중에 결함을 발견하기 위해 사용할 수 있는 리뷰 기법

• 에드혹 - 검토자에게 리뷰 수행 방법에 대한 안내가 거의 또는 전혀 제공되지 않는다. 검토자는 대부분의 경우 작업 산출물을 순차적으로 읽으면서 이슈를 식별하고 기록. 이 기법은 능력에 크게 의존하며, 여러 검토자가 동일한 문제를 보고할 수 있음.
• 체크리스트 기반 - 체계적인 기법으로, 검토자는 리뷰 시작 시점에 배포된 체크리스트(촉진자에 의해) 를 기반으로 이슈를 식별한다. 리뷰 체크리스트는 잠재 결함을 식별하기 위해 경험에서 도출한 일련의 질문으로 구성. 체크리스트는 리뷰 대상 작업 산출물 유형별로 작성해야 하며 이전 리뷰에서 누락된 이슈 유형을 다루기 위해 주기적으로 개선할 필요가 있음. 체크리스트 기반 기법의 주요 장점은 일반적인 결함유형에 대한 체계적인 커버리지를 갖는 점.
• 시나리오 및 드라이 런 - 시나리오 기반 리뷰에서 검토자는 작업 산출물을 어떻게 검토할지에 대한 구조화된 지침을 제공. 시나리오 기반 리뷰는 작업 산출물에 예상되는 용도를 기반으로 작업 산출물(유스케이스와 같이 적절한 형식의로 문서화된 경우) 에 대해 "드라이런"을 수행할 수 있도록 검토자를 지원. 다른 결함 유형을 발견하기 위해 검토자는 기록된 시나리오에만 너무 얽매이지 않아야 함.
• 관점 기반 - 관점 기반 읽기는 역할 기반 리뷰와 마찬가지로 검토자가 개별 리뷰 중 다양한 이해관계자의 관점을 사용하게 됨. 일반적을 ㅗ사용되는 이해관계자 관점에는 최종 사용자, 영업, 설계자, 테스터, 운영자 등이 있다. 서로 다른 이해 관계자 관점을 사용하면, 검토자 간에 중복되는 이슈가 줄어들고 개별리뷰가 좀 더 깊이 있게 진행됨. 관점 기반 읽기가 요구사항 및 기술 작업 산출물에 대한 리뷰에 가장 효과적인 기법. 주요 성공 요인은 리스크 기반으로 다양한 이해관게자의 관점을 적절하게 포함시키고 평가하는것.
• 역할 기반 - 검토자가 작업 산출물을 개별 이해관계자 역할의 관점에서 평가하는 기법. 

3.2.5 리뷰의 성공 요소 

• 각 리뷰는 명확한 목적이 있어야 함. 목적은 리뷰 계획 시 정의하며, 측정 가능한 종료 조건으로 사용
• 목적을 달성하기에 적합하고, 소프트웨어 작업 산출물 및 참여자 유형 수준에 맞는 리뷰 유형을 적용
• 체크리스트 기반 및 역할 기반 리뷰와 같이 사용하는 모든 리뷰 기법은 리뷰 대상 작업 산출물의 결함을 효과적으로 식별하기에 적함해야 한다.
• 사용하는 체크리스트는 주요 리스크 식별을 위해 작성해야 하며, 가장 최신의 정보를 반영해야 함.
• 규모가 큰 문서는 작은 단위로 작성하고 리뷰를 수행해 저자에게 결함에 대한 피드백을 조기에 그리고 빈번하게 제공함으로써 관리를 수행
• 참여자는 충분한 준비 시간을 갖는다.
• 리뷰는 기업의 품질 테스트 정책에 통합된다.