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

 

📚 도서 요약

<개발자도 알아야할 소프트웨어 테스팅 실무 제3판>

본 포스팅은 개인적으로 남기고 싶은 부분만을

요약하여 작성함을 알려드립니다.

 

서론

동적 테스팅이 실제 구현된 시스템을 실행하여 테스팅 하는 것이라면, 정적 테스팅은 실제 시스템이 구현되기 전에 요구사항 정의서, 설계(기준)서, 소스 코드 등의 개발 산출물을 테스팅 하는 것(리뷰/인스펙션, 정적 분석)을 의미한다. 정적 테스팅은 개발 프로세스의 초기에 결함을 발견함으로써 전체 개발 수명주기의 효율을 높여 개발 비용을 낮추는데 도움을 주는 테스팅 활동이다.

 

일부 테스트 전문가는 정적 테스팅을 테스트 엔지니어가 적극 활용해야 할 테스팅 방법으로 인식하기보다는, 개발자나 품질보증 담당자의 전유물로 생각하는데 실제로는 그렇지 않다. 

 

정적 기법

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

3.1.1 리뷰의 이점과 목적

정적 기법은 소프트웨어를 실행하지 않고 테스팅하는 기법으로 리뷰와 같은 수동적(Manual) 기법과 정적 분석 자동화 도구를 활용한 정적분석이 있다.

 

리뷰의 이점

조기 결함 발견 및 수정, 개발 생산성 향상, 개발 기간 단축, 테스팅 비용 감소 및 시간 단축, 개발 수명주기 전체에 걸친 비용 감소, 결함 감소(품질 향상), 커뮤니케이션 향상 

 

> 동적 테스팅에서 발견하기 어려운 개발 산출물(요구사항 명세)의 누락(omissions)과 같은 결함을 발견할 수 있다.

 

정적 기법은 동적 테스팅과는 달리 장애(Failures) 자체 보다는 장애의 원인(결함)을 발견한다.

 

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

표준 위반, 요구사항 결함, 개발 설계(Design) 결함, 불충분한 유지보수성(Insufficient maintainability), 부정확한 인터페이스 명세

 

3.1.2 리뷰와 테스팅 ( Review and Testing )

- 조기 테스트 설계를 통해 코딩을 시작하기 전에 요구사항 문서와 설계 기준서 등에서 테스트 케이스를 만들 수 있으며, 이 과정에서 개발 문서상의 결함을 발견할 수 있다.

- 시스템과 관련된 문서를 먼저 테스트하여 시스템에 유입될 수 있는 결함을 미리 예방할 수 있다.

- 시간을 절약할 수 있다.

그러나, 시스템 명세는 그 내용이 자주 변경될 소지가 있으므로, 프로젝트 초기(개발단계 전)에 모든 테스트 케이스를 생성해 놓는 것은 현명치 못한 방법일 수 있다. 명세가 변경되면 관련된 테스트 케이스를 모두 수정/업데이트 해야 하며, 상황에 따라서는 이미 만들어놓은 테스트 케이스를 유지 보수하는 시간이 새로 테스트 케이스를 작성하는 시간보다 더 소요될 수 있다.

 

 

3.2 리뷰 프로세스

리뷰는 공식적인 것부터 비공식적인 것까지 다양한 형태를 갖는다.

 

페이건(Fegan) 인스펙션 - 리뷰의 성과를 객관화하고 체계화하여 정리한 일례

개발 초기에 요구사항 정의 분석 및 설계 인력이 소수 투입되다가 코딩 시작되면서 투입 인력 수요가 급증하게 된다. 투입 인력 규모가 테스팅 단계에서 절정에 이르게 되며 테스팅이 끝나게 되면 개발 조직이 소수의 유지보수 인력만 남기고 해제된다.

 

인스펙션을 도입할 경우 코딩 전까지는 소요 인력이 인스펙션이 없을 때보다 2배정도 필요하며 초기 프로젝트 비용이 증가하지만, 성공적인 인스펙션 결과 코딩 단계에서의 재작업과 투입 인력이 줄게되어 품질 비용이 감소하고 개발기간을 단축할 수 있다.

 

3.2.1 공식적 리뷰의 단계 ( Phase of a formal review )

정적 테스트 프로세스는 크게 정적 테스트 준비단계, 리뷰/분석 단계, 후속 처리 확인 단계의 3단계로 구성된다.

Static Test Preparation -> Review/Analyse -> Static Test Follow-Up

 

리뷰를 성공적으로 진행하기 위해서는 절차를 준수해야 한다. 비공식적인 리뷰의 경우, 절차의 많은 부분을 생략할 수 있지만, 기본적인 골격을 이루는 절차는 따르는 것이 바람직하다. 특히, 계획 활동과 개별 준비, 후속 처리 확인은 리뷰 미팅을 진행하면서 강제화하여도 좋은 절차이다.

 

공식적인 리뷰 절차

1) 계획 활동 : 참가인원 선정 및 역할 할당, 시작 및 종료 기준 정의, 어떤 부분의 문서 및 코드를 리뷰할지 정함

2) 시작 : 문서 배포. 리뷰의 목표, 절차 및 문서를 설명. 시작 기준 점검

3) 개별 준비 

3) 리뷰 미팅

4) 재작업

5) 후속 처리 확인(Follow-up)

 

3.2.2 역할과 책임 ( Roles and reponsibilities )

리뷰는 역할과 책임이 명확하지 않고서는 성공적인 성과를 내기 어렵다.

 

- 관리자 : 리뷰의 실행여부 결정 및 프로젝트 일정에 리뷰 시간을 할당하고 리뷰의 목적 달성 여부를 확인하고 승인

- 중재자 : 문서의 리뷰를 리드하고 참석자들의 다양한 관점을 중애한다.

- 저자 : 리뷰 대상 문서의 작성자 또는 책임자

- 검토자 : 해당 분야의 기술적 또는 비즈니스적 배경을 갖춘 사람으로, 리뷰 대상에서 인시던트(결함 포함)를 발견하고 기술하는 사람.

검사자 또는 인스펙터라고도 불린다. 검토자는 리뷰 프로세스에서 다양한 관점과 역할을 대표하도록 선발되어야 하고, 특정 리뷰 미팅에 제한적으로 참여하기보다는 모든 형태의 리뷰 미팅에 참석하여 리뷰 활동을 수행해야 한다.

- 기록자 : 리뷰 미팅에서 발견된 모든 이슈, 문제점, 미해결점 등을 기록하고 문서화한다.

 

3.2.3 리뷰의 유형 ( Type of review )

비공식적 리뷰 ( Informal review )

- 공식적인 절차가 없다.

- 페어 프로그래밍에 의한 리뷰이거나 기술 선임자가 설계와 코드를 리뷰하는 것일수도 있음.

- 선택적으로 문서화 될 수 있음.

- 리뷰하는 사람에 따라 성과가 좌우됨.

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

 

기술적 리뷰 ( Technical review )

- 저자가 아닌 중재자가 미팅을 주도함

- 실무에서는 공식적 또는 비공식적일 수 있음

- 주요 목적 : 기술적 문제 해결, 토론, 의사 결정, 대안 평가, 결함 발견

 

워크쓰루 ( Walkthrough )

- 저자에 의해 진행 및 제어

- 주요 목적 : 학습, 시스템에 대한 이해 향상, 결함 발견

 

인스펙션 ( Inspection ) 

- 중재자에 의한 진행 및 제어

- 주요 목적 : 결함 발견

 

공식적인 리뷰 프로세스를 따르며, 프로세스 개선 단계가 인스펙션 미팅과 재작업 단계 사이에 존재한다. 

검토자와는 다른 별도로 테스터(Tester)의 역할을 두고 있다.

인스펙션 절차 : 분량(Capacity)계획 -> 인스펙션 수행 -> 분석 및 평가

 

한가지 이상의 리뷰 방식이 사용된다면 리뷰의 순서는 다양할 수 있다. 예를 들어, 비공식적 리뷰는 기술적 리뷰 이전에 수행될 수 있고, 인스펙션은 고객과의 워크쓰루 이전에 요구사항 명세를 가지고 수행될 수 있다.

 

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

- 사람관련 이슈와 심리적인 측면이 고려되어야 함. 즉,코드 또는 문서의 저자가 리뷰를 통해 긍정적인 경험을 해야 지속적인 효과를 기대할 수 있음

 

 

3.3 도구에 의한 정적 분석

정적 분석의 목적은 소프트웨어의 소스코드와 모델에서 결함을 발견하는 것이다. 소프트웨어의 코드를 실행하여 수행하는 동적 테스팅에 비해, 정적 분석은 조사 대상 소프트웨어를 실제적으로 실행하지 않는 상태에서 도구의 지원으로 수행하는 것이다.

 

정적 분석 특징

- 동적 테스팅으로 찾기 힘든 결함을 발견

- 리뷰와 마찬가지로 장애 보다는 결함을 발견함

- 도구의 도움을 받아 수행

- 정적 분석 도구는 프로그램 코드를 분석하는 것은 물론 HTML이나 XML과 같이 생성된 결과물도 포함

 

정적 분석 가치

- 테스트 실행 전에 조기 결함 발견

- 높은 복잡도 측정치와 같은 메트릭을 계산하여 코드와 설계의 의심스러운 부분에 대한 조기 정보

- 동적 테스팅으로는 발견하기 어려운 결함 발견

- 소프트웨어 모델상의 의존도와 불일치성 발견

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

- 결함 예방 가능 

 

정적 분석 도구를 통해 발견되는 전형적인 결함

- 정의되지 않는 값으로 변수 참조

- 모듈과 컴포넌트 간에 일관되지 않은 인터페이스

- 사용되지 않는 변수

- 사용되지 않는 코드 ( Dead Code )

- 코딩 표준 위반

- 보안 취약성

- 코드와 소프트웨어 모델의 구문 규칙 ( Syntax ) 위반

 

> 전체 개발 수명주기의 초반에 적용되는 정적 기법의 경우, 단기적으로는 정적 테스팅을 위한 리소스가 투입되겠지만, 장기적으로는 조기에 결함을 예방할 수 있게 되므로, 결국 전체 품질 비용 절감의 효과를 얻을 수 있다.

 

 

 

💁🏻‍♂️ 3장 느낀점  

정적 분석이 생각보다 많은 리소스 절감 효과를 줄 수 있다는 것을 알게됨 ! 

또한 이러한 정적 분석을 성공적으로 이루기 위해서는 체계적인 리뷰와.. 문서가 잘못 설계되어있진 않은지, 결함이 있는 문서는 아닌지 잘 체크해봐야 한다는 것.