[개발 / 필독서 ] 소프트웨어 공학으로 보는 개발자 필독서 06 - Verification & Validation

5편을 못 봤다면

[개발 / 필독서 ] 소프트웨어 공학으로 보는 개발자 필독서 05

 

지난 글에서 구현을 완성했다!

이제는 내가 만든 프로그램이 잘 돌아가는지 확인 및 검증을 할 것이다.

 

 

 

 

확인 및 검증 (Verification & Validation)

확인 및 검증은 줄여서 V&V 라고도 한다.

 

확인(Vailidation)은 제대로 된 소프트웨어를 만들었는지 확인한다.

최종결과가 잘 돌아가는지 확인한다.

 

검증(Verification)은 소프트웨어를 제대로 만들었는지 확인한다.

스펙에 맞게(SRS에 맞춰서) 프로그램을 만들었는지 확인한다.

 

말장난인가 싶은데 이론적인 내용이라 잘 와닿지 않는다.

쉽게 개발자가 해야할 일로 생각해보자.

크게 두 가지로 나눌 수 있다.

• 리뷰 (Review)
• 테스팅 (Testing)

 

 

 

1. 리뷰 (Review)

좋은 리뷰는 사장님의 기분을 좋게 한다.

코드 리뷰는 코드 작성자가 아닌 다른 사람이 코드를 검사하는 단계이다.

코드 리뷰를 통해 코드와 제품의 퀄리티를 유지하게 된다.

리뷰를 하면서 어떤 것을 확인해야 할까?

구글의 리뷰 가이드를 참고해서 알아보자.

 

• 디자인 : 코드가 시스템에 맞게 잘 설계되었는가?
• 기능 : 코드가 의도한대로 동작하는가? 유저에게 좋게 작동하는가?
• 복잡도 : 코드를 더 간단하게 할 수 있지 않는가? 다른 개발자가 미래에 코드를 보고 쉽게 이해할 수 있는가?
• 테스트 : 코드가 정확하고 잘 설계된 자동화 테스트를 거치는가?
• 네이밍 : 변수, 클래스, 메소드에 대해 명확한 이름을 사용했는가?
• 코멘트 : 모든 코멘트가 명확하고 유용한가?
• 스타일 : 코드가 스타일 가이드(구글 공식 컨벤션) 을 따랐는가?
• 문서 : 관련 문서를 업데이트 했는가?

 

어떻게 리뷰를 하는지도 구글 리뷰 가이드에서 확인할 수 있다.

Code Review Developer Guide

 

 

코드 리뷰는 집단지성을 통해서 코드의 퀄리티를 높이는 작업이다.

혹시.... 내 코드가....?

 

코드 리뷰를 통해 일차적으로 기능이 동작하는지 확인을 한다.

그 후 테스팅을 통해 여러 케이스를 확인하며 코드가 의도한대로 동작하는지 확인한다.

 

 

 

 

2. 테스팅 (Testing)

테스팅은 내가 작성한 코드가 의도한대로 동작하는지 확인하는 작업이다.

테스팅을 통해 사전에 결함(defect)를 찾아낸다.

 

테스팅은 크게 세 가지로 나눌 수 있다

• 유닛 테스팅 (Unit Testing)
• 통합 테스팅 (Integration Testing)
• 시스템 테스팅 (System Testing)

그 외에도 릴리즈 테스팅(Release Testing), 회귀 테스팅(Regresstion Testing), 유저 테스팅(User Testing)이 있다.

 

 

2.1 유닛 테스팅 (Unit Testing)

유닛 테스팅은 가장 작은 단위의 테스팅으로 개별 함수, 메소드, 클래스 등을 테스트 한다.

상황에 따라 컴포넌트(Component)도 유닛으로 볼 수 있다. (보통 1000줄 이내의 코드)

 

간단한 Swift 예제를 작성했다.

 

인자 2개를 더해주는 간단한 덧셈 함수를 만들었다.

 

c는 1+3 = 4 이다.

XCTAssertEqual 문은 두 개의 인자가 같은지 확인한다.

c가 4이므로 해당 테스트는 통과했다.

 

c는 4인데 5와 같지 않으므로 위와 같이 에러가 난다.

 

 

 

2.2 통합 테스팅 (Integration Testing)

통합 테스팅은 유닛 테스팅가 완료되서 코드들이 나오면, 해당 코드들을 합쳐 테스팅하는 테스트이다.

 

세상에서 가장 가벼운 자전거 출처 : tririg.com

자전거를 예시로 들자.

(세상에서 가장 가벼운 자전거 2.8kg라고 하는데 맥북 프로 16인치 + 아이패드 프로 무게다. 갑자기 궁금해서 찾아봤다)

페달이랑 바퀴를 만들고 각각 성공적으로 테스트를 맞췄다. (유닛테스팅)

이제 두개를 연결해서 페달을 밟으면 바퀴가 돌아가야 한다.

두 개를 연결했는데 페달을 밟아도 바퀴가 돌아가지 않는다면 두 개의 연결 부위(흔히 Interface)를 확인해봐야한다.

이게 통합 테스팅이다.

 

유닛 테스팅은 독립적으로 테스팅을 하는데 반해 통합 테스팅은 연결을 하기 때문에 의존성(Dependeny) 가 생긴다.

그 부분을 잘 확인해서 테스팅해야 한다.

 

+ 경우에 따라서는 유닛 테스팅과 통합 테스팅을 묶어서 생각하기도 한다.

 

 

 

2.3 시스템 테스팅(System Testing)

시스템 테스팅은 프로그램이 완성되면 최종적으로 하는 테스트이다.

테스팅을 통해 SRS에 적혀있는 기능 요구사항(Functional Requirements)와 비기능 요구사항(Non-Functional Requirements)를 잘 만족하는지 확인한다.

 

다시 자전거를 예시로 들면

자전거를 다 조립하고 자전거를 탈 수 있는지(FR) 원하는 색깔대로 나왔는지(NFR)를 확인하는 작업이다.

 

최종적인 테스팅 단계로 보면된다.

 

 

 

2.4.1 릴리즈 테스팅 (Release Testing)

릴리즈 테스팅은 다른 테스팅 팀이 시스템을 테스팅하는 것이다.

시스템 테스팅으로 봐도 무방하다.

블랙박스 테스팅을 통해 프로그램이 잘 작동하는지 확인한다.

 

 

2.4.2 회귀 테스트 (Regression Testing)

회귀 테스트는 유지/보수 단계에서 진행하는 테스트이다.

기존의 코드에 더해 새로운 코드를 작성했을 때, 새로운 코드가 기존의 코드를 고장내는지 확인하는 테스트이다.

즉 코드가 수정될 때마다(컴파일 될때마다) 기존의 테스트를 다시 수행해주는 테스트이다.

새로운 코드가 기존코드에 만들어낸 의존성(Dependency)를 알아내야하는 일이기 때문에 매우 어려운 일이다.

 

 

 

2.4.3 유저 테스팅 (User Testing)

유저 테스팅은 알파 테스팅과 베타 테스팅이 있다.

'베타 테스터 모집'

아마 게임을 했더라면 많이 들어봤을 것이다.

두 테스팅의 차이점은 알파 테스팅은 개발자 환경에서 하는 테스팅이고, 베타 테스팅은 사용자 환경에서 하는 테스팅이다. 

 

 

 

 

  

3. 테스트 주도 개발 TDD (Test Driven Development)

TDD는 테스트가 개발을 이끌고 가는 개발 방식이다.

실행 가능한 테스트 케이스를 먼저 만든 후 실제 코드를 작성한다.

어차피 코드를 작성하고 테스팅을 작성해서 확인을 해야한다면 테스트 케이스를 먼저 작성하고 그에 맞는 코드를 작성하면 되지 않을까? 가 TDD의 모토이다.

 

TDD 3 Step

TDD를 쉽게 표현한 것이 "Red - Green - Refactor" 개발 주기이다.

• Red 단계 : 실패하는 테스트 코드를 작성한다.
• Green 단계 : 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
• Refactor 단계 : 중복된 코드를 제거하고 리팩토링을 수행한다.

이 3가지 단계를 반복하며 코드를 작성한다.

 

 

테스트 코드를 작성할 때 FIRST라는 5가지 규칙을 따르면 더 깨끗한 코드를 작성할 수 있다. 

• Fast: 테스트는 빠르게 동작하여 자주 돌릴 수 있어야 한다.
• Independent: 각각의 테스트는 독립적이며 서로 의존해서는 안된다.
• Repeatable: 어느 환경에서도 반복 가능해야 한다.
• Self-Validating: 테스트는 성공 또는 실패로 bool 값으로 결과를 내어 자체적으로 검증되어야 한다.
• Timely: 테스트는 적시에 즉, 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다.

 

그러면 무조건 TDD를 사용하면 좋은 거 아닌가??

그건 또 아니다. TDD도 단점이 있다.

우선 가장 큰 단점은 생산성 저하이다.

테스팅 코드를 작성하고 실제코드를 작성해야하고, 중간 중간 테스트 코드를 수정해야하기 때문에 개발 속도가 느려질 수 밖에 없다.

시간이 부족한 경우에는 TDD를 잘 사용하지 않는다.

소프트웨어 공학은 No Silver Bullet 이다.

 

 

 

 

 

4. 개발 필독서

테스트 주도 개발(TDD) - 켄트 벡   링크

앞서 설명한 TDD 와 관련된 책

다양한 예시를 통해 TDD를 습득할 수 있다.

 

구글 테스팅 블로그    링크

테스팅 관련 책을 찾아봤는데 모든 프로그래밍 언어를 어우르는 범용적인 책이 딱히 없었다.

특정 프로그래밍 언어를 위한 테스팅 책들이 대부분이었다.

테스팅 자체가 예시를 통해 설명해야 하다보니 책들이 별로 없는 것 같은게 내 의견이다.

그래서 굳이 책을 찾아보기보다는 블로그 글이 더 나은 것 같다.

구글 테스팅 관련 블로그인데 "테스트를 얼마나 하는게 충분한가" 와 같이 테스팅에 관련된 주제 글을 읽어볼 수 있다.

 

 

 

 

 

이제 테스팅을 맞췄고 프로그램이 정식으로 출시되었다!

다음 마지막 글에서는 프로그램이 출시된 후에는 어떤 식으로 관리하는지를 알아볼 것이다.

😁

 

 

 

 

다음 편보기

[개발 / 필독서 ] 소프트웨어 공학으로 보는 개발자 필독서 07