QG(Quality Gate) 우리말로 의역을 하면, “품질통과기준으로 이해 할 수 있을 것 같다. 위키백과에서는 다음과 같이 정의하고 있다.

QG(Quality Gate)

간단히 이야기 하면, 검수관이 출구에 서서 제품을 살펴보고 이 제품 또는 기능이 출구를 통과해도 될지 안될지를 결정하는 과정이다.

 

모든 개발자는 당연히 좋은 품질의 소프트웨어를 만들기 위해 노력한다. 말은 참 쉬운데, 왜 쉽지 않을까?

여기에 고려해야 할 네 가지 주요 요소가 있다.

 

Feature – Quality – Time – Resource(사람과 비용)

 

피처를 잘 구현하기 위해서는 많은 시간과 자원을 투입하면 된다. (많은 시간과 자원을 투입한다고 항상 좋은 결과가 나오는 건 아닌 것 같지만J)

그렇지만, 기업은 항상 시간과 자원이 부족하다. 결국 전체 제품에서도 가치(Value)에 따라 우선순위를 정하고 자원을 배분 할 것이다.

 

예전 제 매니저분과 이야기 중 자신에게 자원(비용과 사람)이 풍부하다면, 난 이 일을 당신에게 맡길 이유가 있을까? 라고 질문을 하셨다. 사람과 자원이 풍부하면, 당연히 모든 주도권을 기업이 가지게 될 것이다. 결국 자원이 너무 풍부한 상황은 개발자 자신에게도 그렇게 유리한 상황은 아니다. (부족해도 문제, 많아도 문제 J)

품질과 자원은 항상 트레이드 오프가 생기게 되어 있다. 결국 조절을 해야만 한다.

(이러한 조정은 보통 와이드밴드 델파이(Wideband Delphi) 기법을 많이 사용한다. 와이드밴드 델파이 기법은 향 후 꼭 다루게 될 것이다. 그때 자세히 이야기 하도록 하겠다.

품질 프로세스와 보안 프로세스는 절 때 개발 프로세스와 떨어져서 진행하면 안 된다. 항상 함께 고려해서 함께 진행을 해야 한다.

 

자 이제 QG를 통과하기 위한 항목으로 소프트웨어 개발에서는 어떤 것을 보는지 살펴보자.

 

1.      높은 수준의 경고를 사용해 컴파일

2.      정적 분석 도구를 이용한 코드 분석

3.      모든 코드에 대한 유닛 테스트

4.      코드 커버리지 비율

5.      모든 코드에 대한 리뷰

 

여기서 소스와 개발은 닷넷위주로 이야기 하도록 하겠다.

경고는 항상 버그라고 생각해서, 되도록 방어적 프로그램을 할 필요가 있다. 사실 매뉴얼 하게 하면, 일이 참 많은 부분인데 Visual Studio를 사용하면, 쉽게 적용이 가능한 부분이다.

 

정적 분석 도구를 이용하는 부분이 QG에서 상당히 비중이 높다.

 

소스 코드를 가이드에 맞게 작성을 했는지 그 규칙을 지정한다. 소스 코드의 스타일 지침은 소스 코드의 형식을 지정하는 방법에 대한 규칙이며, 들여쓰기나 순환문의 형식 등 아주 자세한 코딩 룰을 지정 할 수 있다. 이런 소스 코드에 대한 규칙은 StyleCop 이라는 툴을 많이 이용한다.

자세한 방법은 아래 사이트나 검색을 통해 관련 자료들을 찾을 수 있다. 저는 향 후 이 내용에 대해서도 아주 심도 있게 다룰 것이다.

StyleCop 사이트


그 다음이 소스 코드 보다는 좀 더 나아가 어셈블리 중간코드를 분석해줄 필요가 있다.

FxCop 이라는 툴을 사용해 컴파일된 .NET 어셈블리의 중간 코드를 분석하고 디자인, 보안 및 성능 개선을 위한 기능을 제공한다.

이 기능은 제가 아주 좋아하는 기능이라 뒤에서 아주 자세히 다루도록 하겠다.

FxCop 사이트

C/C++Prefast를 사용할 수 있다.

Visual Studio Team System을 사용한다면, 통합되어 있는 Code Analysis를 사용하는 것이 가장 편할 것이다.

 

다음은 분석된 결과를 기반으로 각 코드에 대한 Unit 테스트를 모두 실행해야 한다. 유닛 테스트가 TDD에서도 가장 비중 있게 논의되는 부분이다.

닷넷에서 가장 많이 사용하는 툴은 NUnit 이다. NUnit은 닷넷 기반의 단위 테스트 프레임워크(Unit-testing framework)이다. Visual Studio Team System Unit 테스트 프레임워크를 사용할 수도 있다.

이것 또한 제가 아주 좋아하는 툴로 단지 사용법뿐만 아니라 단위 테스트에 대해서는 아예 다른 코너를 만들어서 다룰까 한다.

NUnit 사이트

 

이외에도 좋은 단위 테스트 툴이 많이 있다.

csUnit, mbUnit, xUnit.net 등이 있는데, 그 중 최근 개발된 xUnit이 눈에 뛴다. xUnit의 개발자 중 한명인 James Newkirk NUnit 개발에도 참여한 사람으로 다년간의 노하우로 xUnit을 개발했다고 한다. 기대가 되는 툴이 될 것 같다.

xUnit 사이트

 

마지막으로 닷넷에서의 단위 테스팅 프레임웍크와 TDD를 하기 위해 꼭 참고할 사이트가 바로 테스트 드리븐 닷넷이 있다.

테스트 드리븐 닷넷

 

다음 과정은 코드 커버리지를 통해 테스트가 코드를 얼마나 잘 테스트하는지를 측정하는 방법이다. 테스트의 목적은 무조건 많은 코드를 테스트 하는 것이 목적이 아니라 소프트웨어의 품질을 향상시키는데 있다면, 코드 커버리지의 목적은 테스트의 품질을 향상시키는데 있다. 그 비율을 통해 신뢰의 정도를 결정 할 수 있을 것이다. 보통 70~80%로 결정 하는 것 같다. 이건 상황에 맞게 결정 하면 될 것 같다.

 

자 마지막으로 모든 코드에 대한 리뷰과정이 있다. 보통 코드 인스펙션(Code Inspection) 이라고 하는데, CODE COMPLETE 2 에서는 코드 읽기로 소개가 된 것 같다.

인스펙터 툴도 있는데, 이건 제가 보기에는 정적 분석 도구로 분류하는 것이 더 나을 것 같다.

이게 사람들이 모여서 하게 되면, 잘못하면 누가 멀 잘못했는지 감정이 많이 상할 수 있는 부분이 있다. 이론상 좋지만 쉽지 않은 부분인 것 같다.

마이크로소프트에서는 개발자는 자신의 코드를 빌드 서버에 올릴 수가 없고, 리뷰어만 등록을 할 수 있는데, 보통 테스터가 많이 한다고 한다. 등록된 코드의 문제점에 대한 책임은 개발자가 지는게 아니고 리뷰어가 지게 된다고 한다. 당연히 내가 잘못한 것도 아닌데, 책임을 져야 하니 눈에 불을 키고 문제를 찾게 될 것이다. 저 또한 이 부분에서는 경험이 부족해 아주 자세한 노하우는 전달이 힘들 것 같다.

 

이러한 과정을 다 거쳐야 QG를 통과하게 되는 것이다. 사실 간략히 넘어갔지만 중간 중간 나오는 과정 하나가 상당한 분량이고 거기에 있는 툴 하나에도 상당한 책들이 나와 있을 만큼 중요한 부분이기도 하다.

제가 좋아 하는 부분이기도 해서 많이 다루고 싶었지만, 지금은 그 과정을 이야기 하는 부분이라 대부분 소개만 하고, 뒤에 자세히 다루기로 하겠다.

특히 몇몇 툴은 분량이 너무 많아 아예 카테고리 하나 만들어서 이야기 하는 것이 나을 것 같다.

 

자 다음은 Scrum(스크럼)에 대해 이야기 해 보도록 하겠다.

스크럼 자체를 아주 자세히 설명하는 건 아니니 스크럼이 무엇인지는 검색을 통해 미리 알고 있으면 좋을 것 같다.

 

Posted by SF공장장

티스토리 툴바