ISTQB) Part3 정적 기법

* 이 글은 개발자도 알아야할 소프트웨어 테스팅 실무 제3판을 토대로 작성되었습니다.

* 책에 실린 내용 외 추가적인 정의가 있으며 교재 목차와 순서가 다소 다를 수 있습니다.

* 2차 가공 및 재배포는 금지합니다.

* 잘못된 개념 혹은 오탈자는 댓글로 알려주세요.

 

1. 정적 기법과 테스트 프로세스

[ 리뷰의 이점과 목적 ]

* 정적 테스팅 ( Static Testing )

   - 실제 시스템이 구현되기 전에 요구사항 정의서, 설계서, 소스 코드 등의 개발 산출물을 테스팅하는 것

   - 종류 : 리뷰/인스펙션, 정적 분석

 

* 수동적 ( Manual ) 기법

   - 소프트웨어를 실행하지 않고 테스팅하는 기법 ( 리뷰 )

   - 초기 결함 발견 및 수정

   - 개발 기간 단축 및 비용 감소

   - 결함 감소 ( 품질 향상 )

 

* 정적 분석

   - 정적 분석 자동화 도구를 활용한 기법

   - 장애(Failures)보다는 결함(Defects)을 발견함

   - 목적 : 소프트웨어의 소스코드와 모델에서 결함 발견

 

[ 정적 분석의 필요성 ( 동적 테스팅과 비교 ) ]

* 동적 테스팅 ( Dynamic Testing ) ]

   - 실제 구현된 시스템을 실행하여 테스팅

   - 목적 : 결함 발견

 

* 결함(버그)의 종류

   - 고려하지 못한 케이스 ( 요구사항 누락 )

   - 기대하지 않은 동작 ( 요구사항 오해 )

   - 예상치 못한 입력 ( 예외 처리에 대한 누락 )

   - 단순한 코딩 실수로 인한 버그

 

* 동적 테스팅의 단점

   - 정적 테스팅에 비해 상대적으로 비싼 비용

   - 예상치 못한 입력은 동적 테스트의 케이스로 잘 만들어지지 않음

   ( 이유 : 이미 예상한 입력값으로 만들어진 테스트 케이스 )

   - 코딩 실수로 인해 메모리 누수가 발생하는 것은 운영 중인 소프트웨어에서 발견되는 경우가 많음

 

* 정적 분석 ( Static Analysis )

   - 경험 많은 개발자들의 노하우나 이미 필드에서 많이 발생한 여러 실행 시간 오류들의 사례로 규칙 만듦

   - 소스 코드 전반에 걸쳐 분석을 수행

   - 미처 예상하지 못한 입력이나 프로그램의 흐름 혹은 리뷰에서 실수로 빼먹은 코드에 대해서도 검사를 수행

 

* 정적 분석의 필요성

   - 동적 테스팅에 비해 비교적 적은 시간에 버그를 찾아낼 수 있음

   - 코드와 설계의 유지보수성 향상

   - 코딩 스타일 가이드에 관한 규칙과 코드의 품질 메트릭 제공

   - 코딩 스타일 가이드 : 미리 정한 가이드 라인을 잘 따라서 구현했는지 검사

   - 코드 품질 메트릭 : 코드의 복잡성, 확장성, 이식성 등을 수치를 통해 보여줌

 

2. 리뷰 프로세스

[ 리뷰의 절차 및 역할 ]

* 리뷰

   - 코드를 포함하여 소프트웨어 개발 및 테스트 산출물을 검토하고 테스팅하는 방법

   - 적절치 못한 리뷰 형식은 비용과 개발 기간이 늘어나는 역효과를 낳게 됨

   - 리더의 검토없이, 역할 분담없이, 적절치 못한 형식

   - 달성하고자 하는 합의된 목적에 맞는 형태를 취함

   - 결함 발견, 이해도 증진, 합의에 의해 결정과 이를 도달하기 위한 토론

 

* 리뷰의 절차

   - 계획 활동 → 시작 → 개별 준비 → 리뷰 미팅 → 재작업 → 후속처리 확인

   - 계획 활동 : 역할 할당 및 시작 종료 기준 정의

   - 시작 : 문서 배포 및 시작 기준 점검

   - 개별 준비 : 미팅 전 잠재적 결함 혹은 회의에서 제기할 질문과 의견 기록

   - 리뷰 미팅 : 상세 회의록 작성

   - 재작업 : 발견된 결함을 대상 문서의 저자가 수정

   - 후속 처리 확인 : 처리 상태 확인, 메트릭 수집 및 리뷰 종료 기준 점검

 

   - 정적 테스트 프로세스 : 정적 테스트 준비 단계 → 리뷰/분석 단계 → 후속 처리 확인 단계

 

[ 리뷰의 절차 및 역할 ]

* 관리자 : 리뷰의 목적 달성 여부 확인 및 승인

 

* 중재자 : 리뷰 계획, 미팅 진행, 미팅 후속 조치 등 문서 리뷰 리드

 

* 저자 : 리뷰 산출물 작성자 또는 책임자

 

* 검토자 : 리뷰 대상에서 결함을 발견하고 기술

 

* 기록자 : 리뷰 미팅에서 발견된 모든 이슈 기록하고 문서화

 

[ 리뷰의 유형 ]

* 비공식적 리뷰 ( Informal review )   

   - 두 명이 함께 프로그래밍 하거나 기술적 리더가 설계나 코드를 리뷰하는 형태   

   - 목적 : 저렴한 방법으로 일정 수준의 성과 달성

 

* 기술적 리뷰 ( Technical review )   

   - 자질이 있는 팀이 규격이나 표준 차이를 검토   

   - 목적 : 명세서와 계획에 대한 적합성 평가 및 변경 무결성 보증   

   - 참여자 : 기술전문가, 동료 ( 3명 이상 )

 

* 워크쓰루 ( Walkthrough )

   - 개발 산출물 작성 중에 저자에 의해 진행되며, 개발팀이나 관심 그룹이 소프트웨어 제품을 검토

   - 목적 : 산출물 평가 및 개선, 교육

   - 참여자 : 기술전문가, 동료 ( 2명 이상 )

   - 시간 및 인원수 등에 재한이 없는 사업적 리스크가 높은 영역에 효과적

 

* 인스펙션 ( Inspection )

   - 개발 산출물 작성 완료 후 저자 외 다른 동료가 소프트웨어의 에러, 규격, 표준 위배 사항을 검토

   - 목적 : 결함 파악 및 제거 ( 공식적 리뷰 프로세스 )

   - 참여자 : 동료 ( 3 ~ 7명 )

 

* 동료 검토 ( Peer Review ) : 조직 레벨에서 동등한 그룹 동료들 사이에서 수행 ( 기술적 리뷰, 워크쓰루, 인스펙션 )

 

[ 리뷰의 성공 요소 ( Success factors of reviews ) ]

* 수행하고자 하는 리뷰 대상 및 목적에 부합하는 리뷰 형식을 선택

 

* 소프트웨어 개발 산출물과 검토자의 수준과 타입을 고려하여 적절한 리뷰 기법 적용

 

* 체크리스트 및 역할 분담 활용

   - 체크리스트 : 요구사항 정의서, 분석서 및 설계서, 코드 등의 개발 산출물 각각에 대해 작성 및 유지

 

* 참여자 수를 3~5명 정도로 제한

 

* 경우에 따라서 내부 전문가 뿐만 아니라 객관적인 시각과 인지도를 갖춘 외부 리뷰 전문가의 참여 필요