정적 테스팅

정적 테스팅의 기초

정적 테스팅은 대상 소프트웨어를 실행하지 않아도 된다.

코드, 프로세스 명세, 시스템 아키텍쳐 명세, 기타 작업 산출물을 수동(ex : 리뷰)으로 또는 도구를 사용해 평가한다.

 

정적 분석 테스팅 목표 : 품질 개선, 결함 식별, 가독성/완전성/정확성/테스트 용이성/일관성 등의 특성 평가

** 정적 테스팅은 베리피케이션과 밸리데이션 모두에 적용할 수 있다.

 

정적 분석은 테스트 케이스가 필요하지 않다. 도구를 사용하는 경우가 많다.

- 상대적으로 적은 노력으로 동적 테스팅 전에 문제를 식별할 수 있다.

- 정적 분석을 CI 프레임워크에 통합하는 경우가 많다.

 

정적 분석의 사용처 : 구체적인 코드 결함을 식별하는데 사용, 유지보수성과 보안을 평가하는 데도 사용

정적 분석 도구 ex) 맞춤법 검사기, 가독성 도구

 

 

정적 테스팅으로 검사 가능한 작업 산출물

정적 테스트를 사용하여 거의 모든 작업 산출물을 검토할 수 있다.

ex) 요구사항 명세서, 소스 코드, 테스트 계획서, 테스트 케이스, 제품 백로그 항목, 테스트 차터, 프로젝트 문서, 계약서, 모델

 

읽고 이해할 수 있는 모든 작업 산출물은 리뷰 대상이 될 수 있다. 그러나 작업 산출물을 검토할 수 있는 기준이 되는 구조가 필요하다(모델, 공식 문법이 정해진 코드나 텍스트)

 

사람이 해석하기 어려운 것과 도구로 분석해서 안되는 작업 산출물(ex : 법적으로 문제가 되는 타사 코드)는 정적 테스트에 적합하지 않다.

 

 

정적 테스팅의 가치

정적 테스팅은 소프트웨어 개발수명주기(SDLC) 초기 단계에서 결함을 식별하기 때문에 조기 테스팅의 원리를 지킬 수 있게 한다.

또한 동적 테스팅으로 식별할 수 없는 결함(도달 불가능한 코드, 원하는대로 구현되지 않는 설계 패턴, 비실행 작업 산출물의 결함)등도 찾을 수 있다.

 

정적 테스팅은 작업 산출물의 품질을 평가하고 신뢰를 쌓을 방법을 제공한다. 또한 문서화 된 요구사항을 확인함으로써 요구사항이 실제로 자기가 필요한 것을 묘사하고 있는지 확인할 수 있다.

정적 테스팅은 SDLC 초기에 수행할 수 있으므로 이해관계자 간 공통된 이해를 형성할 수 있다.

이해관계자 간 의사소통도 개선된다.

 

리뷰 구축 비용은 많이 들 수 있으나, 프로젝트 후반에 결함을 수정하는 시간과 노력이 줄어들어 전체 프로젝트 비용이 낮아질 수 있다.

 

일부 코드 결함은 동적 테스팅보다 정적 분석을 통해 더 효율적으로 식별할 수 있다. -> 코드 결함이 줄고, 개발 노력도 감소

 

 

정적 테스팅과 동적 테스팅의 차이

정적 테스팅과 동적 테스팅은 서로를 보완한다. 두 활동은 작업 산출물 결함의 식별을 지원하는 듯 비슷하지만 다음과 같은 차이도 있다.

    - 정적 테스팅이나 동적 테스팅 중 한가지로만 식별할 수 있는 겷함 유형도 있다.

    - 정적 테스팅은 결함을 직접 식별하는 반면, 동적 테스팅은 장애를 일으킨 후 연관된 결함을 후속 분석을 통해 찾아낸다.

    - 정적 테스팅은 실행되지 않거나, 동적으로 도달하기 어려운 코드 경로에 있는 결함을 쉽게 발견할 수 있다.

    - 정적 테스팅은 비-실행(non-executable) 작업 산출물에도 적용할 수 있지만, 동적 테스팅은 실행 가능한 작업에만 적용

    - 정적 테스팅은 코드 실행에 의존하지 않는 품질 특성(유지보수)측정, 동적은 코드 실행의 의존적인 품질 특성(성능 효율성) 측정

 

정적 테스팅을 통해 더 쉽게 적은 비용으로 식별할 수 있는 결함은 다음과 같다.

    - 요구사항 결함

    - 설계 결함

    - 특정 유형의 코딩 결함

    - 표준 위반

    - 잘못된 인터페이스 명서

    - 특정 유형의 보안 취약성

    - 테스트 베이시스 커버리지의 차이 또는 부정확성

 

 

 

 

피드백과 리뷰 프로세스

이해관계자 피드백을 조기에 자주 받을 떄의 이점

피드백을 조기에 자주 받으면 잠재적인 품질 문제를 조기에 파악할 수 있다. SDLC동안 이해관계자의 참여가 적으면 개발 중인 제품이 이해관계자의 초기 및 현재 요구를 충족하지 못할 수 있다.

이해관계자가 원하는 것을 전달하지 못하면 큰 비용이 드는 재작업, 납기일 지연, 서로 간의 비난 등이 발생할 수 있으며, 프로젝트가 실패할수도 있다.

 

SDLC 전반에 걸쳐 이해관계자의 피드백을 자주 받으면, 요구사항에 대한 오해를 방지하고, 요구사항 변경을 조기에 이해하고 구현할 수 있다.

 

 

리뷰 프로세스 활동

ISO/IEC 20246 표준은 특정 상황에 맞게 리뷰 프로세스를 조정할 수 있는 체계적이면서 유연한 프레임워크를 정의한다 필요한 리뷰가 공식적일수록 각 활동에 대한 설명된 작업 중 수행할 것이 더 많아지게 된다.

 

작업 산출물이 너무 커서 한번의 리뷰로 다룰 수 없는 경우도 많다. 작업 산출물의 리뷰를 끝내기 위해 여러번 수행할 수도 있다.

리뷰 프로세스에 포함되는 활동은 다음과 같다.

    - 계획 : 목적, 리뷰 대상 작업 산출물, 평가할 품질 특성, 집중할 영역, 완료 조건 등으로 리뷰의 범위를 정의해야 한다.

    - 리뷰 착수 : 관련된 모든 사람과 사항이 시뷰를 시작할 준비가 되었는지 확인하는 것이다.

    - 개별 리뷰 : 하나 이상의 리뷰 기법을 적용해 리뷰중인 작업 산출물의 품질을 평가하고, 의문사항 등을 식별하기 위해 수행한다.

                        리뷰어는 식별한 모든 이상 사항, 권장 사항, 의문 사항을 기록한다.

    - 논의 및 분석 : 리뷰 중에 확인한 이상 사항이 반드시 결함은 아니므로 모든 이상 사항에 대해 분석하고 논의한다.

                            리뷰 회의를 통해 작업 산출물의 품질 수준, 필요한 후속 조치 등도 결정한다.

                            조치 완료를 위한 후속리뷰가 필요할수도 있다.

    - 수정 및 보고 : 모든 결함에 대한 결함 보고서를 작성해 후속 조치가 추적 가능하도록 한다.

                            완료 조건을 충족하면 작업 결과물을 승인할 수도 있다.

 

 

리뷰에서의 역할과 책임

리뷰에서는 다양한 이해관계자가 참여하며, 한 명이 여러 역할을 동시에 맡을 수도 있다.

    - 관리자 : 리뷰할 내용을 결정하고, 리뷰에 필요한 사람과 시간 등 자원을 제공한다.

    - 저자 : 리뷰 대상 작업 산출물을 작성하고 수정한다.

    - 중재자 : 중재, 시간 관리, 모든이가 자유롭게 발언할 수 있는 안전한 리뷰 환경 조성 등 리뷰 회의의 효과적인 운영을 담당한다.

    - 서기 : 리뷰어로부터 이상 사항을 수집하고, 결정 사항이나 리뷰 회의 중에 발견한 새로운 이상 등 리뷰 정보를 기록한다.

    - 리뷰어 : 리뷰를 수행한다. 리뷰어는 프로젝트에 참여하는 사람 또는 주제 전문가, 기타 이해관계자가 될 수 있다.

    - 리뷰 리더 : 리뷰에 참여할 사람을 결정하고, 리뷰 시간과 장소를 협의하는 등 리뷰에 대한 전반적인 책임을 진다.

 

 

리뷰 유형

리뷰는 비공식, 공식 리뷰 등 다양한 유형이 있다.리뷰가 어느정도로 공식적이어야 하는지는 소프트웨어 개발수명주기, 프로세스의 성숙도, 산출물의 중요도와 복잡성 등에 따라 달라진다. 처음에는 비공식적으로 리뷰 후 나중에 보다 공석적으로 리뷰하는 등, 같은 작업 산출물도 여러 형태로 리뷰할 수 있다.

 

리뷰 유형은 다음과 같다.

    - 비공식 리뷰 : 비공식 리뷰는 정의된 프로세스를 따르지 않으며 공식적인 결과 문서도 요구하지 않는다.

                           목적은 이상 사항을 식별하는 것이다.

    - 워크쓰루 : 저자가 리더가 된다. 작업 산출물에 대한 신뢰 구축, 리뷰어 교육, 아이디어 창출, 이상 사항 발견 등

                      여러 목적을 달성할 수 있다. 리뷰어는 워크쓰루 전에 개별리뷰를 수행할 수도 있지만 필수는 아니다.

    - 기술 리뷰 : 기술 리뷰는 기술적인 자격을 갖춘 리뷰어가 수행하고, 중재자가 리더가 된다. 기술 문제에 대한 합의를 도출하고,                            결정을 내리는 것 뿐만 아니라 이상 사항 식별, 품질 평가 및 작업 산출물에 대한 신뢰 구축 등 저자가 개선할 수

                        있도록 동기를 부여하고 지원하는 것이다.

    - 인스펙션 : 가장 공식적인 리뷰 유형, 이상 사항을 최대한 많이 찾는 것, 메트릭을 수집해 리뷰 프로세스를 포함한 전체

                       소프트웨어 개발수명주기를 개선하는데 사용한다.

 

 

리뷰의 성공 요소

리뷰의 성공 여부를 결정하는 요소는 다음과 같은 것들이 있다.

    - 명확한 목표와 측정 가능한 완료 조건을 정의. 참가자의 평가가 목적이 되어서는 안된다.

    - 주어진 목표를 달성할 수 있으면서, 유형, 참여자, 요구사항 등 정황에 맞는 리뷰 유형을 선택한다.

    - 리뷰어가 개별 리뷰 또는 회의에서 집죽력을 잃지 않도록 작은 단위로 리뷰를 진행한다.

    - 이해관계자와 저자에게 리뷰 피드백을 제공해 제품 및 활동을 개선할 수 있게 한다.

    - 참가자가 리뷰를 준비할 수 있는 충분한 시간을 제공한다.

    - 리뷰 프로세스를 관리층이 지원한다.

    - 학습 및 프로세스 개선 촉진을 위해 리뷰가 조직 문화의 일부가 되도록 한다.

    - 모든 참가자가 자신의 역할을 어떻게 충족해야 하는 지 알 수 있도록 적절한 교육을 제공한다.

    - 회의에 퍼실리테이션을 적용한다.