매뉴얼 테스트와 테스트 자동화. 정말 그 범위를 정하기도 힘들고, 잘 하기도 힘든 가장 기초적인 테스트 방법입니다. 아마도 대다수의 사람들이 알고 있는 테스트의 기본이기도 합니다.

메뉴얼 테스트(Manual Test)는 수동 테스트라는 의미로 테스터에 의해 직접 수행하여 테스트 결과를 기록하는 방식이며,
테스트 자동화(Automated Test)는 자동 테스트라는 의미로 프로그래밍이나 스크립트에 의해 자동으로 테스트를 수행하여 결과를 기록하는 방식입니다.

개발자라면 테스트 자동화를 최우선으로 여기지만, 사실은 매뉴얼 테스트의 영역이 갖는 테스트의 의미는 매우 비중이 높습니다. 많은 사람이 오해하는 것 중에 하나가 자동화 테스트가 정교하고 정확하다고 생각한다는 것입니다. 최근 추세도 자동화 테스트에 매우 큰 비중을 갖고 시스템을 구축하고 테스트 인력을 양산하고 있는 것도 사실입니다. 필자가 전제를 말씀을 드리자면 자동화 테스트는 그 신뢰도가 그리 높지 않습니다.

반면, 매뉴얼 테스트는 매번 인력이 투입되는 테스트이기 때문에 테스트 수행 비용이 매우 비싼 편이며, 테스트 수행 속도가 느리지만 그 신뢰도가 매우 높은 편입니다.

아마도 독자 여러분들은 매뉴얼 테스트가 왜 테스트 결과의 신뢰도가 높은지 의아해 할 수 있을지도 모릅니다. 최근 테스트 자동화를 구축하기 위해서 모든 테스트 케이스의 90%, 많게는 95%이 이르기 까지 테스트를 자동화하기 위해 노력하고 있습니다. 즉, 메뉴얼 테스트:자동화 테스트=95:5 라는 비율을 갖게 되는데, 이것의 비율에 대한 신뢰 퍼센테이지는 매뉴얼 테스트가 훨씬 더 신뢰도가 높다는 의미입니다. 바꾸어 말하면, 매뉴얼 테스트로 수행하는 테스트 케이스가 몇 되지 않기 때문에 그 만큼 테스트의 신뢰할 수 있는 확률이 높다는 의미입니다.

   

   

하지만 이런 꿈 같은 이야기는 안타깝게도 단지 수치적이고 해외의 사례입니다. 우리나라의 테스트는 전혀 이런 이상적인 환경을 따라가지 못하고 있습니다. 그 이유 또한 이전의 포스트 중 "[ALM-Test] 8. 소프트웨어 테스트 후진국 "대한민국"에서 언급하였듯이 테스트를 대하는 자세, 테스트에 대응하는 자세가 아직 성숙되지 않았기 때문입니다.

   

   

자동화 테스트부터 이야기 해 봅시다.

실제로 소프트웨어 세계 1위 기업인 Microsoft 는 처음 기업을 만들면서 납품하던 여러 가지 DOS(Disk Operation System) 제품부터 테스트의 중요성을 깨닫고(깨닫기 보다 그들이 이미 소프트웨어계 최고의 인물이기 때문에…) 이 DOS 제품에 대한 테스트를 적극적으로 투자하였습니다. DOS 제품을 만들던 당시 여러 나라와 다양한 컴퓨터의 요구 사항에 맞는 DOS 제품을 거듭 납품하기 전부터 하나 둘 씩 테스트 인력을 확보하기 시작했습니다.

운영체제로 동작하는 DOS 제품은 시스템 동작에 가장 기본적으로 제공하는 인터페이스를 제공하는 매우 중요한 제품이기 때문에 테스트에 대해 명확한 철학을 가지고 있었습니다. DOS 제품 자체는 내부적으로 인터럽트(Interrupt) 라고 하는 이벤트 기반으로 시스템과 디바이스를 제어하고 이것을 이용하여 동작하는 소프트웨어가 상당하기 많이 보유했기 때문에 그 제품 자체가 매우 정교할 수 밖에 없습니다. (최종적으로 작은 기업이었던 Microsoft 는 MS-DOS 를 IBM PC에 납품하면서 점차적으로 거대 기업으로 자랄 수 있는 기반이 되었습니다)

이 이후 Windows 95 가 출시되면서 굉장히 획기적인 기능이 추가되었습니다. 그것이 바로 플러그앤플레이(PnP-Plug in Play) 입니다. 이것은 독자들도 알다시피 새로운 하드웨어나 장치가 추가되면 자동으로 OS가 그 장치를 인식할 수 있는 기능이었습니다. 가령, 그래픽 카드를 사서 꼽았는데 Windows OS가 알아서 새로운 장치가 추가됨을 알려주고 드라이버를 설치하라고 알려주거나 자동으로 환경을 구성할 수 있는 기능을 일컫습니다. 데스크탑 컴퓨터 환경에서는 매우 획기적인 OS의 기능이었습니다.

일단 다시 처음으로 돌아가서, 왜 자동화 테스트를 해야 하는가… 필자는 "하지 않아도 됩니다." 라고 말하고 싶군요. 애자일 개발을 수십 가지 지침 중의 하나가 바로 TDD(Test Driven Development-테스트 주도 개발) 입니다. 오해 중의 오해라고 하면 이 지침이 마치 필수 조건으로 인식되는 경우가 있습니다. 필자가 테스트를 하지 않다고 된다는 의미는 테스트를 할 만큼 규모가 없음에도 불구하고 테스트를 의무적으로 강조할 필요는 없다는 의미입니다.

   

그럼 테스트 자동화를 위한 개발 환경이 다음에 적용된다면 자동화 테스트를 적극적으로 추천합니다. 각 항목이 참(True)라면 반드시 고려해보기 바랍니다.

  • A = ( 10명 이상의 개발자가 하나의 프로젝트에 투입되었다. )
  • B = A and ( 3명 이상의 개발자가 다른 개발자의 소스 코드나 컴포넌트에 연관되어 있다. )
  • ( A or B ) and ( 두 개 이상의 연계 시스템, 산하 시스템 또한 레거시 시스템이 존재한다. )
  • C = ( 소프트웨어 특성상 매우 복잡하거나 여러 가지 알고리즘을 사용한다 )
  • A = A or ( 5명 이상의 개발자와 2개 이상의 팀이나 파트가 협업을 해야 한다 )

   

즉, A or B or C = True 라면 반드시 테스트 자동화를 고려하기 바랍니다.

필자가 언젠가 세미나에서 언급한 적이 있습니다. 테스트는 개발자간의 신뢰라고요.

"나는 너를 믿지만 너가 만들 코드는 믿지 않는다. 테스트 코드가 없다면…"

여럿이 함께 개발해야 하는 환경에서 타인의 코드에 의한 오류인 경우 내가 낸 오류보다 더 화가 나는 것도 그 때문입니다. 신뢰~!

   

왜 자동화 테스트의 신뢰도가 낮은가

일반적으로 테스트를 자동화하면 할 수록 그에 대한 노력은 두 배가 됩니다. 일반적으로 자동화 테스트를 완벽하게 수행하는 경우 제품 코드보다 테스트 코드가 1.5~2개 가량 많습니다. 즉, 100,000 라인에 달하는 코드로 만든 제품은 최대 200,000 라인의 별도의 테스트 코드가 필요하다는 의미입니다. 왜 이렇게 제품 코드보다 테스트 코드가 많은지 궁금할 수 있습니다.

그 이유는 다음과 같습니다. 테스트 대상이 어떤 것인지에 따라 테스트 기법은 매우 다양합니다. 그리고 다국적 제품인 경우 나라 별로 법적인 대응 코드, 화폐나 날짜 체계, 그리고 문화적 다양성 체계 등이 상당한 분량의 테스트 코드를 양산할 수 밖에 없습니다.

  • 테스트 계획 (Planning)
  • 기능 테스트
    • 동등 클래스 분할 기법
    • 경계 값 분석 기법
    • 조합 분석 기법
  • 구조적 테스트
    • 블록 테스팅
    • 결정 테스팅
    • 조건 테스팅
    • 기본 경로 테스팅
  • 모델링 기반 테스트
  • 다국적 지원을 위한 로케일(Locale) 테스트
  • 비기능 테스트
  • 테스트 이력 관리 및 버그 추적, 관리
  • 전반적인 테스트 품질 관리 활동

   

   

그럼 다시 질문하자면, 왜 자동화 테스트의 신뢰도가 낮은가 입니다. 의외로 답은 매우 간단합니다. 개발 코드는 언제나 버그나 결함을 내포하고 있을 가능성이 있는데, 테스트 코드라고 다를 바가 없습니다. 테스트 자동화의 테스트 신뢰도는 테스트 코드 자체에 의존해야 하기 때문에 테스트 코드 자체가 잘못된 검증은 한다면 올바른 테스트가 아닙니다. 하물며, 개발자에게 엄격한 NullReferenceException 이나 Null Point 가 빈번하게 발생하는 버그라면, 테스트 코드 또한 개발 코드에 의해 동작하므로 이러한 잘못된 동작이 테스트 결과에 미치는 영향은 상당히 높을 수 밖에 없습니다. 쉽게 말해, 테스트 코드도 사람이 만드니까 실수를 한다는 것이죠.

개발자에게도 버그나 결함으로 지속적으로 코드를 관리해야 하지만, 테스터에게도 테스트 코드를 꾸준히 관리해야 하는 의무가 있는 것입니다. Microsoft 의 자동 업데이트 기능으로 Windows OS 가 꾸준히 패치되고 있긴 하지만, 어떤 패치는 네트워크 기능을 마비시키거나 그래픽 드라이버가 마비되는 애교 만점 패치도 상당 수 존재합니다.

이렇게 거대한 최대 소프트웨어 기업도 간지러운 애교에 많은 사용자가 분노하고 비방하고 욕설을 퍼붓고 운영체제의 안정성을 논하며 펌하 하는데, 왜 개발자들은 자신이 만드는 버그에 대해 그렇게 관대한지 더욱 사랑스럽기도(?) 합니다.

   

다시 이전에 얘기하던 Windows OS의 플러그앤플레이(Pnp-Plug in Play) 에 대한 내용은 잠시 보류하고, 매뉴얼 테스트를 다루어 본 이후에 다시 원점에서 다시 논의해보도록 하겠습니다.

최근 여러 달 동안 블로그를 관리하지 않아 이렇게 다시 글을 올리는 것이 약간은 부담이 되네요. 거의 1년이나 방치해둔 제 블로그에 '어떤 글을 첫 번째 글로 올려야 하나?' 라는 기본적인 것부터 시작해서 앞으로 어떤 주제를 가지고 지속적으로 블로그를 해야 하는지도 말입니다. 이미 마음속으로는 "테스트"라는 소프트웨어 공학적인 주제를 가지고 첫 번째 글을 쓸 것이라고 마음은 먹었지만, 그 동안 느낀 많은 것들 또한 천천히 블로그로 포스팅 하리라 약속을 드립니다.

   

소프트웨어 테스트 후진국 "대한민국"

소프트웨어 개발 중 테스트는 소프트웨어 개발 라이프사이클의 중요한 과정 중으로 하나임을 전산과를 전공하였다면 이미 알고 있을 것입니다. 그 만큼 소프트웨어 개발 과정 중 "테스트" 단계는 일련의 모든 이전 단계, 즉 분석, 설계, 개발이라는 범위의 기나긴 여정의 과정을 검증하는 단계이고, 그리고 이 과정에서 상당한 분량을 지식을 얻을 수 있는 과정이 테스트 과정이기도 합니다.

   

필자가 현재 회사로 이직을 하고 약 1여 년간 소프트웨어 테스트라는 Sub Job을 맞게 되면서, 초기에 가볍게 시작한 테스트 활동이 이제는 어느 정도 정착된 소프트웨어 테스트 프로세스를 수립하게 되었고, 이것을 올바르게 판단할 수 있도록 데이터를 시각화하기 위한 다양한 시도를 해 보았습니다. 그리고 테스트를 대하는 우리들의 자세에 대해서도 매우 비판적인 요소들이 많지만, 즉 이것은 아무도 올바른 테스트를 시도하지 않았고 경험해 보지 못한 것이라는 반증이기도 합니다.

   

   

사실 우리나라에서는 "테스트"라는 용어가 피부에 와 닿게 된 시점이 바로 "애자일" 개발 프로세스(방법론이라고 칭하지 않음) 덕분에 여러 사람들의 입방아에 가장 자주 오른 용어이기도 합니다. "애자일 프렉티스", "애자일 소프트웨어", "애자일 개발" 이라는 일파만파적인 용어와 수식어 들이 생겨나면서 우리나라의 현실적인 소프트웨어 개발 생태계에서 "테스트"가 재조명 받는 시기가 바로 "애자일"의 영향이 매우 컸음을 의미합니다.

물론, 자사의 솔루션이나 소프트웨어를 전문적으로 개발하는 진정한 소프트웨어 개발 업체에서는 정직하고 잘 동작하는 소프트웨어를 출시하기 위해 테스트에 상당한 노력을 기울이고 있습니다. 높은 단가로 팔리는 소프트웨어에 결함이 있다는 것은 고객에게 매우 치명적이기 때문에 이들의 업체들은 소프트웨어 테스트 전문 인력을 확보하고 꾸준히 품질 유지를 위해 노력하고 있으니까요.

특히 20세기 후반부터 큰 규모의 소프트웨어 개발을 일컬어 "엔터프라이즈 급"의 제품이 개발되고 이것은 즉, 혼자서 잘 동작하는 소프트웨어가 아닌, 다른 시스템, 소프트웨어, 컴포넌트와 잘 동작해야 하는 이식성 때문에 압도적으로 비중 있게 다루는 것 또한 테스트 입니다.

   

엔터프라이즈 급의 소프트웨어는 상하수직 관계와 팀간의 범위 등이 잘 조직화가 잘 된 우리나라에서 특히 가장 높은 퍼포먼스를 보여주기도 합니다. (높은 퍼포먼스가 그에 걸 맞는 품질을 보장하는 것이 아님을 주의해 주세요) 그리고 테스트는 1단계에서 2,3 단계까지 체계적으로 이루어지기도 합니다. "단위 테스트", "기능 테스트", "통합 테스트"라는 폴더를 만들고 수십 가지 문서를 양산해내면 테스트 단계는 통과하게 되는 것이지요^^. 테스트 이후 단계에서 문제가 발생하면 유지보수 계약에서 추가적으로 지원하면 되니까요..;; (물론, 그 과정이 단순한 과정이 아닌 것도 잘 아는 바이지만…)

흔히 모든 사람들이 문제라는 것을 인지하고, 테스트가 중요하다는 공감대가 형성이 되어야 비로서 저와 함께 논의가 될 수 있으리라 생각합니다.

   

   

개발자가 아닌 돌팔이를 주도적으로 양산

일단 개발자의 정식 명식은 "소프트웨어 기술자" 입니다. 일반적으로 우리나라에서는 개발자의 등급을 분류하기를 다음과 같이 분류하는 것을 좋아합니다.

자세한 개발자 등급 기준은 다음의 링크를 참고 하세요 (http://career.sw.or.kr/hrdict/front/guide/renew/sub1-4_popup.jsp )

  • 초급 기능사 : 기능사 자격증을 취득한 자
  • 중급 기능사 : 기능사 자격 취득 3년 경과 및 산업기사 취득한 자
  • 고급 기능사 : 기사, 산업기사 취득하고 기사 취득 후 7년 경과한 자
  • 초급 기술사 : 기사 취득, 산업 기사 이상 취득, 지식경제부장관이 고시한 공인민간자격을 취득한 자
  • 중급 기술사 : 기사 취득 및 그 후 3년 업계 종사 …
  • 고급 기술사 : 중급 기술사 취득 후 3년 이상 업계 종사
  • 특급 기술사 : 고급 기술사 취득 후 3년 이상 업계 종사
  • 기술사 : 기술사

   

참 문제가 많은 등급 분류 제도이지요? 대충 밑바닥부터 특급 기술사가 되려면 어림잡아 20년은 넉넉히 업계에 종사해야 하고, 빨리 빨리 자격을 취득하는 것이 상책인 제도인 것 같습니다. 이것도 저것도 싫다면 몇 가지 제한이 있긴 하지만, 양반으로 승진하는 방법은 "기술사"가 유일한 방법이네요. 석사, 박사 과정을 이수하고 좀 놀다가 기술사를 따면 초고속으로 "기술사"로 승진할 수 도 있지요. 이런 등급 제도를 싸잡아 대략 4등급으로 나누면 "초급", "중급", "고급", "특급", 이렇게 네 부류의 개발자(사)로 나뉘어 지는데, Microsoft 제품과 Borland 제품을 가지고 논지 20년이 훌쩍 넘는 필자 또한 아직은 초급을 벗어날 수 없는 운명에 처해있네요.

저렇게 등급화한 것이 문제가 아니라, 닷컴 열풍으로 소프트웨어 개발자 양산을 주도한 정부로써 진정한 엔지니어를 양산하려는 시도가 아닌 "초급 기능사"를 너무 많이 양산한 것이 문제이고, 일단 현업으로 뛰어든 초급 기능사는 현실적으로 다음 등급을 넘기 위해 다시 학교로 돌아가는 것이 가장 빠른 방법인 것이 더욱 문제이고, 더욱 문제는 막 현업에 뛰어든 기능사 개발자들이 더 높은 고지로 갈 수 있는 문턱은 당시 이미 닫혀버렸다는 것이 가장 큰 문제입니다. 덕분에 수 많은 일자리를 창출하고 당시 청년 실업률이 낮은 편이었으며, 누구에게나 개발자의 길이 열려있었다는 것이 지금 현재의 개발자 구인난의 대표적인 정책 실패라고 봅니다. 정책만이 실패한 것이 아닙니다. 닷컴 열풍 이후 지금의 소프트웨어 생태계는 이미 파괴되어버렸고, 지속적인 정책이 뒷받침 되지 않아 많은 수의 개발자들이 소프트웨어 업계를 떠났습니다.

소프트웨어를 공부하려고 뛰어는 사람들이 아닌, 단지 특정 플랫폼과 개발 언어를 가르치면서, 그 시장이 원하는 플랫폼과 개발 언어의 문턱을 넘지 못하면 그대로 낙오될 수 밖에 없으니, 학원 문턱을 통해 현업에 종사할 수는 있어도, 잘 할 수 없는 반복적으로 순환되는 구조적인 문제점을 아직도 그 때의 문제들을 우리 현업 종사자들이 짊어지고 가고 있습니다.

   

3년 후, 5년 후, 10년 후, 20년 후 개발자의 미래

어떤 개발자가 좋은 개발자인가부터 시작해 봅시다. 10점 만점 중에 각 개발자에게 점수를 주어보았습니다.

  1. 개발자는 코딩을 잘 하면 좋은 개발자입니다. (1점 드립니다)
  2. 개발자가 코딩을 잘하는데 커뮤니케이션 스킬이 좋으면 좋은 개발자 입니다.(4점 드립니다)
  3. 개발자가 신기술에 거부반응 없이 잘 소화하면 좋은 개발자 입니다. (5점 드립니다)
  4. 문서화, 시각화 역량이 좋으면 더 없이 써 먹을 데가 많은 개발자 입니다 (SI에서 쓰는 문서 제외) (8점 드립니다)
  5. 부하직원을 잘 부리고 성격도 좋으면 금상 첨화 입니다 (10점 드립니다)

   

이것이 무언인가 잘 생각해 보시면, 신입 사원이 팀장까지 가기 위한 스킬북이라고 보셔도 좋습니다. 전형적으로 우리나라에서 요구하는 개발자 구인 스킬이지요. 결국 코딩 하다가 커뮤니케이션 스킬을 인정받으면 5~10년 후 팀장 명함은 따놓은 당상입니다. 즉, 이것이 대다수의 개발자의 커리어가 될 수 도 있다는 의미입니다.

  • 이렇게 궁극의 개발자는 바로 관리자인 것인가…?
  • 개발도 제대로 못해본 사람들이 어떻게 좋은 소프트웨어를 만들 것인가…?

   

   

코드+코드+코드…+컴파일=소프트웨어

개발자+개발자+개발자…+야근=소프트웨어

   

아마도 필자가 수 년 전에 사용했던 이력카드의 스킬 인벤토리는 여러 개발자들도 낯설지만은 않을 것입니다.

 

우리나라 소프트웨어 산업의 80%인 SI(System Integration) 프로젝트가 모두 이런 형식의 이력카드를 사용하고, 고객사들도 원하는 것이 이런 형태의 이력카드이며, 여기에 근무기간을 합산하여 개발자 등급을 분류하여 페이(월급)을 지급합니다. 내가 저 프로젝트에서 뭘 하든 개발자를 바라보는 자세가 한낮 스타크래프트의 SCV, 그 이상이 아니다는 의미이기도 합니다.

   

저 또한 저러한 이력카드를 채우지 않은지 오래되었지만, 최근에는 제 스킬 인벤토리를 페이스북에 올려놓고 꾸준히 업데이트를 하고자 노력하기도 합니다. (http://www.facebook.com/profile.php?id=100000339676463&sk=info ) 좋은 예가 될지는 모르겠지만, 제 스킬 인벤토리는 최대한 특정 플랫폼에 종속적이지 않도록 작성했고, 제가 수행한 업무를 잘 소개하려고 노력 하였습니다. (물론 제 진짜 이력서가 아닌 제 간략한 정보임을 인지하고 봐주세요) 그리고 제가 개발자로써 어떤 활동을 하며, 어떤 에반젤리즘을 하는지도http://powerumc.codeplex.com/ 를 통해 게시하고 있습니다.

이러한 필자의 발버둥은 SCV 이상이 되고 싶음을 갈망하는 것일지도 모릅니다. 하지만 개발자는 개발자다워야 합니다. 개발자는 개발이 기본이 되어야겠지요.

애자일 개발 프로세스에서는 함께 하는 팀간에 비즈니스 모델이나 비전을 제시하고 함께 공감대를 형성하여 최상의 퍼포먼트와 팀워크를 구축하는 것이 첫 번째 단계입니다. 그래야 반복이고 머고 잘 됩니다. 애자일 개발 프로세스는 몰라도 됩니다. 팀원이 "이것이야 말로 애자일 프로세스로 돌아가는 프로젝트구나!!!" 라는 것을 느끼게 할 필요도 없습니다. 첫 단추를 잘 꿰면 굳이 애자일 프로세스가 아니더라도 마치 자연의 생태계의 흐름처럼 애자일리티할 수 밖에 없기 때문입니다.

즉, 필자가 이 섹션에서 하려는 말은 개발자는 개발이 기본이 되어야지, 회사나 프로젝트의 비즈니스는 그 다음 단계라는 것입니다. 회사나 프로젝트의 이익을 창출하는 비즈니스의 모델과 프로세스를 잘 이해하면 좋지만 개발자의 기본적인 소양을 갖추지 못한 사람이 그 비즈니스를 구현하게 되면 그것처럼 서포트하기 힘든 것도 없습니다.

   

결국은 좋은 테스트를 하기 부적격한 개발자들

이야기가 삼천포로 갔습니다만, 필자는 앞으로 테스트에 대한 연제는 계속될 것입니다. 그런데 다시 한번 우리나라 소프트웨어 생태계를 구성하는 많은 사람들을 보고 느낄 때는, 테스트가 문제가 아니라 개발자 한 명 한 명이 갖는 커리어와 목표의식이 없는 것이 더 큰 문제입니다. 이러한 우리나라 소프트웨어 개발에 대한 입방아는 책 한 권으로도 모자랄지도 모릅니다. 그리고 이를 공감하는 분들도 제 주변에 꽤 많은 편이고요.

결국 마치 필자가 우리나라 소프트웨어 생태계를 전반적으로 싸잡아 몰아가는 것처럼 보이지만, 꼭 그렇지는 않습니다. 왜냐하면 한 동안 테스트를 Sub Job으로 수행하면서 이러한 개발자의 근본적인 자세, 테스트를 대하는 자세, 테스트에 대한 편견, 테스트 결과가 개발자 자신에게 미치는 영향 등 여러 가지 경험을 하면서 결국 근본적인 문제에 대한 생각을 한 것 뿐입니다. 즉, 테스트라는 일련의 소프트웨어 개발 단계에 들어가기도 전에 많은 수행 착오를 거치면서 테스트의 기술적인 문제가 아니라 그 이전에 테스트를 바라보고 이해하는 사람들의 문제라고도 바꾸어 이야기 할 수 있습니다.

다시 말해,

  • 대다수의 개발자는 테스트는 필요하지만 내가 알 바는 아니라고 생각하고 있습니다.
  • 그리고 자신에게 부정적인 영향을 주는 테스트에 대한 적대적인 반감을 드러내는 것은 개발자로써가 아닌 감정적으로 대응하는 개발자들의 문제점들이 내포하고 있습니다.
  • 더 문제인 것은 테스트를 단 한번도 생각해 본적 없는 사람들이 테스트에 대해 펌하하고 논하는 것도 참 안타깝습니다.
  • 이보다 더 큰 문제는 테스트를 수행하는 사람 또한 소프트웨어/테스트 공학 1장도 읽어 보지 않은 사람들이 대부분이라는 것도 테스트를 수행하는데 큰 걸림돌입니다.
  • 종합해보면 테스트라는 일련의 단계에 대한 최소한의 이해가 부족하고, 스스로 부족한 것을 알고 받아들일 줄 아는 이해심도 부족합니다.

   

소프트웨어 개발 사이클에서 초기 분석과 설계를 잘 하는 것이 중요하고 그것을 잘하는 사람이 있음으로써 개발에까지도 영향을 미치는 것은 "애자일 개발 프로세스"든 "전통적인 개발 프로세스"든 마찬가지 입니다. 테스트도 마찬가지 입니다.

라이브 서비스를 하는 소프트웨어 서비스 업체들도 성능, 버그, 결함, 오류, 해킹 등에 많은 투자를 하고 심도 있게 다루는 부분입니다. 테스트는 분명 매우 민감하고 기본적이며 중요한 단계입니다.

테스트는 개발을 염두하고 테스트를 하지만, 개발자는 테스트를 염두하고 개발하지 않습니다. 그렇기 때문에 테스트는 개발자에게 언제나 불리할 수 밖에 없습니다. 아무런 이음매가 없는 개발 단계에서 테스트 단계까지 자연스러운 이음매를 맺기 위해서 기술적인 것은 기본이 되어야 할 것이며, 그 근본적인 공학적인 지식도 앞으로 꾸준히 다루어 보고자 합니다.

[ALM-Test] 7. TDD vs 계약기반 테스트

Agile Development 2011. 1. 4. 08:30 Posted by POWERUMC

단위 테스트를 어떻게 해야 잘 하나…?

단위 테스트를 어떻게 해야 잘 하는지는 사실 논란의 여지가 굉장히 많습니다. 왜냐하면

  • TDD를 해본사람 vs 안해본사람
  • TDD가 능숙한 사람 vs 능숙하지 않은 사람
  • 개발툴에서 TDD를 제공하는 환경 vs 제공하지 않는 환경
  • 테스트 지식이 있는 사람 vs 없는 사람

어쨌든 목표는 동일합니다. 작성된 코드에 대한 테스트를 수행하는 것이죠. 일반적으로 테스트의 목표에 따라 테스트 방법이 달라질 수 있지만, 흔히 단위 테스트는 기능 범위에 한하여 테스트 코드를 작성하는 방법입니다. 어떻게 코드가 변경이 되든, 어떤 데이터소스 이든지 간에 성공해야 할 테스트는 반드시 성공하고, 실패해야 할 테스트는 반드시 실패해야만 기능이 올바르게 동작한다는 것을 최소한으로 보장할 수 있다는 것입니다.

   

무엇이 단위 테스트를 어렵게 하나?

단위 테스트는 어떻게든 하는 것은 매우 쉽지만, 어떻게 해야 잘 할 수 있고, 시간을 단축하는 방법도 매우 중요합니다. 맹목적인 단위 테스트는 테스트의 목표를 상실하게 만들 수 있고, 의미 없는 더미(Dummy) 테스트 코드가 되기가 매우 쉽습니다. 그리고 더미(Dummy) 단위 테스트 코드를 양산하는 방법도 매우 쉽습니다.

  • 테스트에 대한 지식이 없는 경우
  • 처음부터 목적/목표가 없는 테스트 코드 작성
  • 테스트 방향이 잘못 설정된 경우
  • 단위 테스트 관리 방안이 없는 경우
  • 처음부터 잘못된 디자인이나 구현 도중 발생하는 디자인 결함

   

그리고 일반적으로 인간의 생각의 흐름은 매우 순차적입니다. 복잡한 생각 등을 결국은 순차적으로 나열을 하게 되지요. 그 대표적인 것이 자신의 머리 속에만 존재하던 사건을 도식화하는 것이 바로 육하원칙(5W1H) 입니다. 이런 육하원칙과 같이 테스트 대상을 명확하게 테스트 코드로 구현하는 것도 매우 중요한 부분입니다.

  • Who - 누가
  • When - 언제
  • Where - 어디서
  • What - 무엇을
  • Why - 왜
  • How - 어떻게


그리고 마지막으로 단위 테스트를 하는 것 중 "무엇을 테스트해야 하나?" 입니다. 테스트 대상을 어떻게 쪼개어 테스트를 해야 가장 생산적이고, 중복되지 않는 테스트를 작성하는가는 즉시 테스트의 관리 비용과도 영향을 미치는 중요한 부분이기도 합니다. 즉, 테스트 코드가 중복이 되면, 관리되는 테스트 코드의 양이 늘어나고, 그 테스트 결과가 반드시 성공/실패해야 함에도 그렇지 않게 될 수 도 있습니다.

흔히 열광하는 TDD(Test-Driven Development) 도 마찬가지입니다. 이론적으로 그 용이성은 필자도 인정하지만, 사실은 매우 실용적이지도 않고, 효과적이지도 않습니다. 더불어 위의 나열한 테스트 지식, 목표, 테스트 방향, 관리 방안, 디자인 측면에서도 명확하지 않는다면 쥐약과도 다름이 없습니다. 즉, 테스트라는 것에 집중되어 그 목표, 방향을 제시하기 힘들며, 객체지향적인 코드를 만들기도 어려우며, 실제로 지저분한 코드를 만들기 매우 쉬운 방법이기도 합니다.

즉, 인간의 생각은 매우 복잡한데, 순차적인 도식화 작업을 하지 않은 채로 순차화를 시키려 하니 테스트 코드의 품질과 소스 코드의 품질은 기대 이하가 대부분이었습니다.

   

계약 기반의 테스트

최근에는 계약 기반(Contract-Based)의 아키텍처 또는 패턴의 개발이 매우 활발합니다. 코드적으로 추상화를 통해 매우 명확하며, 이런 추상화된 모형을 통해 완벽하게 모형의 인터페이스를 통해 시그너처를 구현해 나가는 방식입니다. 정확하게 계약 기반의 개발도 아니며, TDD, BDD(Behavior-Driven Development)도 아닌 그 중간적인 형태를 취하는 방법입니다.

계약 기반(Contract-Based)의 개발 방식은 이전에 자주 세미나에 언급을 하였습니다. 자동차보험의 경우 계약서와 아래와 같은 계약 명세가 존재 합니다. 이 명세가 바로 인터페이스의 모형과 시그너처에 해당한다고 봐도 무방합니다.

   

아래는 자동차보험의 계약 명세에 대한 상세적인 약관입니다. 이 약관은 계약 명세에 대해 자세하게 약관을 명시하고 있으며, 이것을 인터페이스의 구현이라고 보셔도 무방합니다.

   

즉, 인터페이스의 모형과 시그너처는 단순히 객체지향적인 인터페이스를 넘어, 계약(Contract)적인 관점의 신뢰를 이루기도 합니다. 바로 그 계약을 잘 설명했던 TechDays 2010 Spring 의 슬라이드를 몇 장 재활용해보면^^

  

   

계약 기반의 개발과 테스트의 장점

물론 이 계약 기반의 개발과 테스트의 장점이 없다면, 필자 또한 이렇게 침을 튀기며 얘기하지는 않을 겁니다. 이전에 얘기했듯이 테스트는 하면 할수록 어려워지고, 또한 관리하기도 무척 버거워집니다. 그 과정에 의지와 다르게 테스트의 목적과 목표가 소실되고, 테스트의 방향성을 상실하는 경우가 허다합니다. 그리고 잘못된 초기 디자인이 특히 돌이키기 힘든 어려움이 될 수 있습니다.

사실 어떤 기가 막힌 테스트 기법도 명세(인터페이스의 모형, 시그너처)가 변경이 되면 많은 노가다(?)를 감수해야 할 수 밖에 없습니다. 바로 리팩토링(Refactoring) 작업인데, 좀 더 나은 코드/디자인을 위한 것이긴 하지만, 너무 많은 리소스나 비용이 필요하다면 이 리팩토링 작업이 전혀 즐겁지 않는 작업이 되기도 합니다.


하지만 절대 변하지 않는 진리 중 하나는, 쪼개진 것을 합치는 것은 쉬워도, 합쳐놓은 것을 쪼개기는 매우 어렵기 때문입니다.

   

각설하고, 계약 기반 테스트가 TDD보다 좀더 효과적인 이유는

  • 허술하게 하는 TDD는 테스트 목적/목표가 불명확한데 테스트 코드를 먼저 짠다?
  • 보험의 약관을 가지고 명세를 만들어 간다? 무지 어렵겠는걸…?
  • 디자인 목표가 없는 추상화가 과연 올바른 추상화인가…?
  • 코드는 생각을 먼저 하고 짜는 것이 방어적/효과적/객체지향적인데, 타이핑 먼저…?

   

위의 나열한 몇 가지 이유만으로, 필자는 TDD를 싫어하는 이유이기도 하지만 특히 싫은 이유는 리팩토링부터 시작하는 코드는 죽어라 리팩토링으로 끝나기 마련입니다. (리팩토링을 반드시 그 자체의 의미에 두고 하는 얘기는 아닙니다) 뒤돌아서면 내심 찜찜한 기분도 들고, 좀 더 완벽함에 가깝게 디자인하려 하지 않은 것이 어찌 완벽함에 가까워지겠습니까.

물론 어떤 테스트 기법이든지 "경우에 따라 잘 맞을 때가 있고 안 맞을 때"가 있습니다. 다만, 이런 TDD 기법 하나로 찬양하다시피 어떠한 올바른 방향을 제시하지 않는 것은 매우 위험한 발상이기도 합니다. 필자는 TDD 의 울타리에서 벗어나야만 올바른 TDD 를 할 수 있다고 생각을 하며 이만^^


2010년 8월 28일, Visual Studio Camp #1 에서 발표한 "Enterprise Track : [2] 소프트웨어 품질 향상을 위한 다양한 테스트 기법 - 엄준일 ALM MVP" 세션을 들어주신 분 중에 어느 테스트 전문가를 만나 뵙게 되었습니다. 최근 테스트 공학과 테스트 프로세스에 푹 빠져있는 저에게 매우 단비와도 같은 분이시고, 특히 테스트 전문 도구인 Load Runner 제품을 실제로 사용하고 계신 분이셨습니다.

(http://willstory.tistory.com/4)

제 세션의 내용과 현재 사용하고 계신 Load Runner 제품에 대해 경험적으로 비교를 해 주신 후기를 작성해 주셔서, 여러분들에게 도움이 될까 싶어 @will_story 님의 동의를 얻어 저희 팀 블로그에 게시하게 되었습니다.

가격에서 상당히 차이가 나는 Load Runner 와 Visual Studio 2010 Ultimate(테스팅 기능에 한하여) 비교해 주셨는데, 역시 비싸다고 좋은 도구는 아닌가 봅니다.^^ 이 두 도구에 대해 냉철하게 비교해 주신 @will_story 님께 감사 드리며, @will_story 님의 글을 보기 쉽게 편집하여 전문을 공개해 드립니다.

참고로, Visual Studio 2010 은 매우 광범위한 테스트 영역을 지원하고 있습니다. 테스트 공학에서 접근하는 대부분의 테스트 기능이 Visual Studio 2010 하나의 통합 도구에서 제공하는 것입니다.

[그림1] 테스트 기법 정리(Visual Studio Camp #1 의 세션 내용 중)

   

아래의 글은 http://willstory.tistory.com/4 의 글쓴이의 동의 하에 제공되어, 약간의 편집하였으나, 원문의 의미상 변형이 전혀 없음을 알려드립니다. 좋은 글을 제공해 주셔서 감사의 마음을 전해 드립니다. ^^

비주얼 스튜디오 2010 팀 블로그에서 Visual Studio Camp를 진행하였다. 여러가지 세션이 있었지만 나의 관심사항만 세미나를 경청하고 퇴장하였다. 유익한 정보였고 너무나도 소중한 시간이었다. 혹시 세미나 후기에 대한 내용에 대하여 자세한 정보를 알고 싶다면 아래의 링크를 따라갔으면 좋겠다.

Load Runner 의 버전은 8.1이다. 나에게는 아직 Windows 7이 없어 XP에서 잘 돌아가는 8.1 버전으로 작성하였다. Windows 7 에서 Load Runner 10.1을 해보고 싶었지만 OS가 없기에 아쉽게도 XP기준으로 작성한다.

[세미나 후기] Visual Studio Camp #1

Enterprise Track : [2] 소프트웨어 품질 향상을 위한 다양한 테스트 기법 - 엄준일 ALM MVP – 땡쵸[엄준일]

소프트웨어 개발의 이전의 사례를 바탕으로 테스팅의 중요성과 그 기법과 방법을 공부하면서 경험한 내용을 전달하였습니다. 소프트웨어 개발 프로세스 중 테스팅의 매력에 푹 빠져 있답니다.

소프트웨어는 개발 및 릴리즈 과정까지 수 많은 과정을 겪는데, 소프트웨어가 점진적으로 진화함에 따라 결함의 발생률이 증가합니다. 이를 개선하기 위한 테스트 기법 중 단위 테스트, WhiteBox 테스트, 화면 테스트, 성능 테스트, 부하 테스트 등 다양한 테스트 기법을 알아봅니다.

사실 PPT 자료만 올라오면 이미지를 Load Runner 와 비교하고 싶었지만 아쉽게도 자료를 받지 못한 것이 아쉽다. 먼저 Load Runner 이미지로 비교 분석을 하고자 한다. 나중에 추후 VS2010 팀에서 자료를 받으면 추후 업그레이드를 하도록 하겠다.

자아.. 이제 내 Tistory의 첫 포스팅이자 첫 블로그 운영이 내가 관심이 있는 분야라서 매우 즐겁다. 이제 이야기를 보따리를 풀어보자.

Visual Studio Camp #1은 예전부터 신청하였다. 전에도 SW Testing Bar Camp 때 주최하였던 곳에서 그리 멀지 않은 곳이기 때문에 가기까지는 무리 없이 도착하였다. 이전에 Sten에서 Razar라는 제품[베타 테스트로 참석하여 경품을 받게 되었다.]으로 테스트한 경험을 공유한다고 하여 10시에 일정이 있었는데, 필요인원 부족으로 무산이 되어 집에서 피파온라인으로 열심히 게임을 하다가 세미나 시간에 맞추어 참석하였다.

도착하였을 때 깔끔한 신청 절차 간편한 입장이 인상적이다. 누가 발표자인지 누가 경청자인지 알 수 있는 이름표는 좋았다는 생각이 들었다. 하지만 이름표에 자신의 맡고 있는 MVP 분야를 적어 두었다면 경청자가 추후 질문을 하는데 있어 생각하는 수고를 덜어줄 수 있지 않았을까? 라는 생각을 하게 된다. 1시간 정도의 짧은 만남 물론 얼굴과 이름은 질문자가 당연히 갖추어야 할 기본 예의지만 … 그냥.. 뭐 아쉽다는거다.

난 엔터프라이즈 Enterprise Track : [2] 소프트웨어 품질 향상을 위한 다양한 테스트 기법 - 엄준일 ALM MVP 님의 세미나를 들었다. 들으면서 Load Runner 와 흡사하기 보다는 오히려 'Load Runner 를 뛰어 넘을 수도 있겠다'라는 생각과 전율이 마음 깊숙히 전해져 왔다. 이미지가 있다면 전달이 쉽겠지만 아쉽다.. 아쉬워….

   

첫 번째, 비교[다양한 옵션 VS 심플함]

  • Load Runner 의 강점! 다양한 옵션

    다양한 옵션을 포함하고 있어 스크립트 작성 시 웹 페이지에 맞도록 작성이 용이하다.
    이외에 다양한 옵션이 존재한다. 좀…. 복잡하다. 잘못 설정했다가 원하는 결과를 얻기 어렵다.

  • Visual Studio 2010 강점
    Simple 하다. 너무도 쉽게 심지어 Load Runner 보다 쉽다. Load Runner 의 사용자 매뉴얼은 너무도 이론적이며 복잡하다.
    하지만 Visual Studio 안내 설명은 매우 쉽게 설명하여, 특히 Visual Studio 2010 공식 팀 블로그에서도 자세하게 설명을 해주고 있다. 직접 경험을 기반으로 작성을 해주니 이보다 친절하고 절실하게 와닿은 설명이 어디 있겠는가!(소통과 공유가 존재하는 것)

    일반 사용자가 특히 개발자가 바로 바로 성능 테스트를 수행 할 수 있도록 되어있다.

   

두 번째, 비교[성능 테스트 시나리오]

  • 스케줄이 편리한 강점
    원하는 대로 인원도 증가 시킬 수 있다. 예약시간도 존재한다. 성능을 위하여 새벽2시에 기다려 테스트하지 않고 예약시간을 설정하면 알아서 돌아 간다. 랜덤으로 oo명에서 0명까지 물결 치듯 설정도 가능
  • 편리한 스케줄 일정
    Load Runner 와 마찬가지로 스케줄이 변경이 동일하다. 랜덤으로 oo명에서 0명까지 물결 치듯 설정도 가능한지는 짧은 세미나 내용으로 언급되지 못한 것이 아쉬운 점이다. 하지만 예상으로는 될 것으로 보인다.

   

세 번째, 비교[성능 모니터링]

  • Load Runner 의 모니터링
    Load Runner 는 Web/HTML만 반영하는 것이 아니며 DB/Oracle도 성능 테스트가 가능하기 때문에 매우 다양한 모니터링 지원이 가능하다[물론 돈이 많은 기업이라면 유로로 라이선스를 사야 한다.]
  • Visiual Studio 2010의 모니터링
    가장 아쉬운 부분 중에 하나이다. Load Runner 처럼 다양한 모니터링을 제공할 수 있을까[?] 라는 의문이 든다.
    하지만 강점도 있다. Load Runner 모니터링보다 심플하고 깔끔하며 원하는 정보만 보여준다. 로드러너 처럼 4개 정도의 모니터링 그래프를 제공하는 형식은 비슷하지만 디자인 면에서나 컴퓨터를 오래 사용하는 사용자의 입장에서 생각하는 UI는 Microsoft 의 Windows 7 로고처럼 심플하면서도 편안한 이미지로 되어있다.
    Load Runner 는 보고서를 출력하면 중복되는 내용이 많은데 Visual Studio 2010은 깔끔함과 심플함 원하는 정보와 불필요한 중복을 피하는 듯한 느낌을 받았다.

   

네 번째, 비교[리포트 및 보고서 출력]

  • Load Runner 의 모니터링
    Load Runner 는 2가지 방식으로 보고서를 출력할 수 있다. HTML, *.doc(docx) 방식이다. 알아서 목차도 만들어주고 내용도 작성해 준다. 물론 아쉽지만 영어로만 제공된다. 나는 그래서 주로 그래프만 이용한다.
     
        
  • Visiual Studio 2010의 모니터링
    내가 보았을 경우에는 *.execl 형식으로 출력을 하는 것을 보았다. 조금은 아쉬운 점이다. 보고서를 다른 발주처에 보내었을 때 엑셀보다는 워드파일로 만약 공공기관이라면 *.hwp 파일로 보내야 하지만 *.execl은 조금은 뽀대[?]가 부족하다. 작성한 문서를 워드로 다시 편집 해야하는 수고를 덜어야 한다.
    물론 99% 성능 전문가들과 각 회사마다 프로젝트 성능 담당자들은 회사에서 쓰는 양식을 이용하여 템플릿에 맞게 보고서를 작성할 것이다. 나 또한 회사 템플릿으로 작성한다. 하지만 보고서로 출력하여 바로 줄 수 있을 정도의 수준이라면 이제는 로드러너는 내 손을 떠나 보내고 Visual Studio 2010 을 사용하지 않을까 생각한다.

   

Visual Studio 2010 Camp #1 짧은 후기

세션을 들으면서 엄준일[땡초]님과 10정도의 대화를 나누었다. 테스트에 재미를 붙이신 듯 호기심 어린 모습과 열정에 박수를 보내주고 싶다. [테스트의 세계로 오신 것을 환영합니다. 쿠쿠쿠쿠.ㅋ]

Visual Studio 2010 Camp #1 를 진행하셨던 어느 기술전도사님이 예전에 나도 스탭으로 다른 몇몇 분들과 함께 진행한 SW Testing Camp 와 함께 진행하였으면 좋겠다고 제안하였을 때 당장 "그럽시다" 라고 대답하고 싶었지만 아쉽게도 나 혼자만의 결정할 사안이 아니기에 대답을 회피했다. 아쉽 아쉽… Windows 7 운영체제에 Visiual Studio 2010 을 설치한 제품과 Load Runner 를 비교하면 나의 객관적인 입장에서는 Load Runner 에게 8.5점을 Visual Studio 2010 에게는 9.0점을 주고 싶다.

1시간만 들었던 세미나였지만 너무나 강렬한 인상이 아직도 기억 속에 남는다. 엄준일님이 함께하자는 말과.. 기술전도사님이 Visual Studio 2010 팀에서 함께 하자는 말 들이..

"기술전도사님 사실 저는 Windows 7이 없어요.. Visual Studio 2010도 없어요. ㅠㅠ;;; 빌려주시면.. 해보고는 싶어요.ㅠㅠ". 흑흑 2010년도는 일만 벌린다.. 담 주는 대학원 개강이구나

Windows 7에 Visiual Studio 2010 설치해주는 회사로 이직 옵션의 하나로 정해야겠다.. 좋은 회사 있음 소개시켜줘~ *_*/

많은 정보를 공유하고 싶지만 방화벽으로 text로만 해야 하는 회사에 아쉬움을 던지며 이만 작성 끝~~~

필자는 Load Runner 를 써보지 않고, 오직 Visual Studio 만으로 테스팅 공학과 분야에 흥미를 갖고 공부를 하고 있습니다. 이번 Visual Studio Camp #1 을 통해서 오히려 저에게 좋은 정보를 제공해 주시고, 의견을 공유할 수 있어서 너무 뜻 깊은 자리였습니다.

좋은 글을 저희 팀 블로그에 기고에 동의해 주신 http://willstory.tistory.com/4 님께 감사합니다.

[ALM-Test] 5. 테스트 계획

Agile Development 2010. 8. 10. 08:30 Posted by POWERUMC

테스트 계획은 테스트 작업을 시작하기 위한 가장 기초적인 명세서입니다. 테스트를 어떻게 진행하고 어떻게 결함을 발견할 것인지 계획을 갖고 테스트에 진입하는 것이죠. 테스트 계획 없이 테스트를 한다는 것은 아키텍처 없이 머리 속의 청사진으로 프로그램을 코드를 짜는 것과 마찬가지입니다. 그만큼 테스트 계획은 테스트에 있어서 첫 발을 내 딛는 중요한 작업입니다.

   

테스트 계획은 좋은 소프트웨어의 첫 걸음

아마 독자 여러분들 중에 개발 프로젝트를 한 두 번쯤 리딩(Leading) 해 보신 경험이 있다면 아실 겁니다. 좋은 설계과 좋은 계획만으로 좋은 소프트웨어가 나오는 것이 아니라는 것을…. 물론 좋은 소프트웨어를 위해 밑거름이 바로 계획입니다. 그리고 계획이 좋거나 나쁘다고 해서, 소프트웨어의 품질과 직결되는 문제는 아닐 수도 있습니다.

실제로 엉터리 계획을 가지고 소프트웨어를 만들어도, 정말 잘 되는 케이스(대외적으로)도 많습니다. 심지어 계획 없이 시작한 프로젝트도 좋은 소프트웨어(절대적으로 좋다는 것은 아닙니다)가 나올 수 도 있습니다. 반대로 아주 철저한 계획을 가지고 시작하더라도 소프트웨어의 품질이 엉망이기도 합니다.

최근 애자일(Agile) 방법론은, 설계 단계를 코딩(Coding) 으로 대체하기도 합니다. 계획 자체가 불필요한 산출물로 직결되는 경향이 많기 때문에, 바로 최종 산출물을 코드(Code) 로 바라보는 매우 간결한 방법론입니다. 그리고 설계 단계를 뛰어넘음으로써 발생하는 여러 가지 문제를 XP(eXtreme Programming) 에서 애자일 선언문 중 12가지 원칙으로 커버를 하고자 합니다.

 

깜놀~ MSDN 에서 애자일 방법론에 대한 설명이 있네요. (MSF v5.0과 관련된)
http://msdn.microsoft.com/ko-kr/library/dd997578.aspx

 

하지만 실제 현실에서는 어떤 특정한 계획 작업이 반드시 필요한 경우에 대부분입니다. 왜냐하면 지속적으로 소프트웨어가 운영되기 위해서는 과거의 이력이 쓸모 없기 보다는 적어도 필요 있는 경우가 대부분입니다. 설령 이력 관리가 되지 않은 문서라도 말입니다.

 

고객사의 소프트웨어의 산출물은 왜 관리가 안되는가?
몇 번의 컨설팅에 참여한 경험으로, 고객사의 산출물이 제대로 관리가 되지 않은 곳이 대부분이었습니다. 컨설팅을 수행하기 위해서 낯선 소프트웨어의 구조를 알기 위해, 산출물을 검토하면 실제로 현재와 다른 아키텍처나 구조를 가지고 있는 경우가 허다합니다.

왜 현재의 소프트웨어와 산출물이 일치하지 않는가에 대한 물음을 가질 수 있습니다. 산출물이 업데이트가 되지 않은 과거의 산출물이라면 특히 아키텍처나 구조를 파악하기 힘들 수 있거든요.

하지만, 굳이 산출물이 업데이트 되지 않더라도 누구를 탓할 수 있는 노릇은 아닙니다. 왜냐하면 업데이트가 되지 않은 산출물이라도 그 시대적인 배경과 당시의 이슈 등에 대해서 충분히 검토가 가능하기 때문입니다. 산출물이 업데이트 되지 않는 것은 무의미한 산출물이라고 말하는 사람들도 있지만, 꼭 나쁜 것은 아닙니다. 오히려 업데이트 되지 않은 산출물이 그 조직의 프로세스나 조직 구조를 파악하는데 더 도움이 되기도 하기 때문입니다.

   

테스트 계획, 어떻게 세워야 하나?

만약, 당신에게 소프트웨어의 특정 컴포넌트를 테스트를 해야 한다면, 바로 테스트의 계획을 어떻게 시작하냐 입니다. 필자의 생각으로는 개발보다 더 중요한 것이 바로 테스트라고 생각합니다. 잘못된 코딩을 검증할 수 있는 방법이 바로 테스트이기 때문입니다. 코드적인 오류나 비즈니스 프로세스적인 오류, 기술적인 오류 등 다양한 개발 코드에 잠재적인 오류가 내포되어 있습니다. 그것을 찾아내고 올바르게 검증하는 단계가 바로 테스트 단계입니다.

즉, 테스트를 하기 위한 목적과 목표가 뚜렸해야 합니다. 테스트 케이스는 테스트를 진행한 테스터(SDET) 에 의해 명확한 비전을 제시하며, 커뮤니케이션을 증진할 수 있습니다. 그렇기 때문에 테스트 케이스가 없는 테스트는 커뮤니케이션을 포기한 테스트와 다름 없습니다.

그럼 다음과 같은 단계로 테스트 계획을 진행할 수 있습니다.

  • 테스트 이름
    한 문장에 테스트에 대한 모든 요약 내용을 함축할 수 있어야 합니다.
  • 테스트 문제
    테스트 이름에 대한 설명입니다. 예를 들어, Stack Overflow 가 발생할 수 있다는 추측이나 테스트 목표를 서술합니다.
  • 분석
    개발자와 테스터의 업무는 전혀 다릅니다. 개발자는 문제 발생에 간과하여 넘어가는 경향이 있지만, 테스터는 그 문제를 밝혀내는 업무를 수행합니다. 문제가 되는 부분에 대해 왜 문제가 되는지 정곡을 찌르는 설명이나 추측을 서술합니다.
  • 설계
    실제 테스트가 수행될 경우, 어떤 파라메터와 결과 기대값을 갖는지에 대한 서술입니다. 테스트를 실제로 진행하게 될 과정을 서술하면 됩니다.
  • 오라클
    예상되는 결과에 대한 설명입니다. 즉, 설계 단계에서 왜 결과가 이렇게 나오게 될지에 대한 서술입니다.
  • 예제
    왜 결과 값이 이렇게 나오는지에 대한 예제나 코드 등을 나열하면 됩니다.
  • 함정과 계약
    예를 들면, 테스트에 사용된 파라메터가 항상 옳을 수는 없습니다. 즉, 업무 지식이 있는 사람과 없는 사람간에 테스트를 진행할 경우 테스트 결과에 대한 오차를 서술합니다. 왜냐하면 테스트 계획을 테스터와 비즈니스 업무 분석가 간에 시각 차이가 있을 수 있기 때문입니다.
  • 관련된 패턴
    이전에 말씀 드렸다시피 테스팅 패턴을 다양합니다. 어떤 테스팅 기법의 패턴으로 접근했는지에 대한 요약입니다.

위와 같이 테스트 계획을 수립할 수 있습니다. 하지만, 간결한 프로세스를 위해 몇 가지 항목은 건너뛰어도 괜찮다고 생각합니다. 필자가 테스팅 아티클을 쓰는 이유도 바로 이것 때문이죠. 우리나라 실정에 맞게 불필요 한 것은 제거하자.

필자의 경험으로 반드시 필요한 항목은 아래와 같습니다. 물론 필요한 경우 더 추가하셔도 좋습니다.

  • 테스트 이름
  • 테스트 문제
  • 함정과 계약

   

   

그렇다면 테스트 하는데 얼마나 걸리는데?

가장 민감한 사항입니다. 개발된 코드를 이용하여 테스트를 진행하는데 얼마만큼의 시간이 소요되는지에 대한 추정은 테스팅을 도입함에 있어서 비용과 직결되는 민감한 부분입니다. 왜 테스트를 진행해야 하는지조차 불분명하다면 차라리 전통적인 방법(수직적인 개발 방법론) 의 가장 마지막 단계에서 진행하는 것과 별반 다를 것이 없기 때문입니다.

개발자(SDE)가 자신의 코드를 테스트 하는 것과, 테스터(SDET) 가 테스트하는 것과 품질의 차이가 없다면 정말 테스트는 불품 없는 작업이기도 합니다. 하지만 분명한 것은 개발자의 시각과 테스터의 시각은 현저하게 다릅니다. 예를 들어, 개발자는 '사용자'가 이런 어처구니 없는 값을 입력하지 않을 거라고 단정하고 개발을 하지만, 테스터는 그렇지 않기 때문이죠. 이해하시죵? ^^

일반적으로 Microsoft 에서는 개발과 테스트의 시간을 1:1 로 봅니다. 즉, 개발 시간이 3시간이 걸리면, 테스트 시간도 3시간으로 예측합니다. 테스트에 소비되는 시간은 고객이 사용하는 소프트웨어의 결함에 대한 불쾌지수와 다름이 없습니다. 테스트가 적절한 패턴으로 정합적으로 수행되었다면, 그만큼 잠재적인 결함과 버그도 줄어들 것입니다.

   

테스트 산출물이 필요하다.

테스터(SDET) 가 테스트를 수행했더라도 잠재되어 있는 결함이나 버그는 여전할 수 있습니다. 테스트 패턴이 잘못된 접근법이나 방법을 사용했다면 잠재적인 치명적인 결함이나 버그로 이어질 수 있기 때문입니다. 그래서 특히 테스트에 대한 산출물이 테스터에게는 방어적이고 효율적인 수단이 될 수 있습니다.

가장 기본적으로 테스트는 코드의 모든 부분을 검증해야 합니다. 입력 값이 잘되었든, 잘못되었든 말이죠. 그리고 그 결과를 이력으로 저장하여 지속적으로 테스트의 검증이 올바르거나 효과적으로 진행되었다는 것도 기록이 필요합니다.

즉, 테스트를 진행해서 뭐가 좋아 졌는지의 수치적인 측정이 필요합니다.

  • 테스트 결과
  • 코드 커버러지
  • 스펙 종료 상태
  • 결함율 추이
  • 성능 테스트 결과

   

위의 항목에 대해서는 차근 차근 알아볼 예정입니다. 특히 주의할 사항은, 코드 커버러지가 100% 라도 테스트가 완전히 완료된 것은 아니라는 것입니다. 차후에 테스트 패턴에 대해서 알아보면서 다룰 예정입니다. 

[ALM-Test] 4. 테스터(SDET) 의 역할

Agile Development 2010. 8. 4. 08:30 Posted by POWERUMC

샘플 프로그램으로 시작해보자고!!

아주 간단한 Windows Forms 어플리케이션을 작성해 보았습니다. 실제로 실무에서는 이렇게 간단한 프로그램을 만드는 개발자도 없겠지만, 아주 간단한 것 부터 시작하여 테스트의 필요성과 테스터의 역할이 얼마나 중요한지 알 수 있는 시간이 되길 바랍니다.    

아래의 윈폼 어플리케이션은 숫자A와 숫자B 를 더하여 결과를 보여주는 프로그램입니다. 아래와 같이 간단하게 디자인을 하였습니다.

   

소스 코드는 더할나위 없이 간단합니다. 특별한 설명은 하지 않겠습니다.

이 프로그램으로 1과 2 값을 입력하면 당연히 3이라는 결과가 출력되어야 합니다 아래와 같이 말이죠.

프로그램이 완벽하지요?? 정말일까요?? 특히 프로그램을 개발하는 개발자의 시각은 테스터와 매우 다릅니다. 일반적으로 개발자에게 스팩(Spec)을 구현하는 명세서가 전달이 됩니다. 아래는 간단한 구현 명세서 입니다. (단, 화면 명세서가 아닙니다)

   

구현 명세서

제목

두 숫자를 입력 받고 합을 구하는 기능

기능

1. 테스트 박스 1에 숫자를 입력할 수 있다.
2. 텍스트 박스 2에 숫자를 입력할 수 있다.
3. 새로운 텍스트 박스에 텍스트 박스 1과 텍스트 박스 2의 합을 출력한다.

   

테스터(SDET) 의 힘이 발휘되는 순간!

개발자는 위의 명세서를 보고 두 숫자를 입력 받아 출력하는 프로그램을 아래와 같이 구현합니다.

사실상 동작에 아무런 문제점이 없지만, 테스터의 시각에서는 전혀 다릅니다. (물론 구현 명세서가 부정확하긴 합니다) 즉 숫자의 입력 범위가 매우 불확실합니다. 정수만 입력되는 Integer 값인지, 32Bit 부동 소수점을 표현하는 Float 인지 아무런 정보가 없기 때문이겠지요.

테스터는 바로 버그를 발생시킬 수 있는 프로그램의 코드나 사용성에 대해 즉각 테스트를 수행합니다. 개발 소스 코드가 제공이 된다면 해결 방안까지 제시할 수 있겠지만, 그렇지 않는다면 오로지 테스터의 경험과 실력에 의존할 수 밖에 없습니다. 그렇기 때문에 SDET 는 개발자(SDE) 와 동등한 기술 능력을 갖추거나 그 이상의 능력을 필요로 하게 됩니다.

위의 간단한 프로그램을 테스트하기 위해서는 SDET 는 테스트 케이스(Test Case) 를 작성합니다. 테스트 케이스(Test Case) 를 작성하는 목적은 기능이 올바르게 동작한다는 가정하에 잠재적인 버그(Bug) 를 유도하는 작업입니다. 그리고 테스트 케이스에 대해서는 차후에 자세히 다루도록 하겠습니다.

만약, SDET 가 아래와 같은 값을 입력했다면 어떻게 될까요? 즉시 프로그램은 오류를 뱉고 말 것입니다. 아래와 같이 말이죠.

   

물론, SDET 는 소프트웨어 버전이 매번 릴리즈 될 때마다 위와 같이 무식하게 수동 테스트(Manual Test) 를 수행하지 않을 것입니다. 이 수동 테스트를 개선하기 위해 자동화 테스트를 수행할 것이며, 이 부분 또한 차후에 설명할 예정입니다. 간단히 설명하자면 반복적으로 테스트를 수행한 가치나 목적이 있다는 자동화 테스트 대상이 될 수 있습니다.

위의 무식한 테스트 과정을 자동화 하기 위해 단위 테스트(Unit Test) 를 사용하여 아래와 같이 작성할 수 있습니다. (아래의 UI 테스트와 관련된 부분이며 마찬가지로 차후에 상세히 설명할 예정입니다, 단, 자동화 테스트 이외의 비기능 테스트가 무식하다는 것은 아닙니다.)

   

이 테스트는 아쉽지만, 무자비하게 오류를 발생합니다. 프로그램 소스 코드의 int.Parse 는 정수 값만 변환 가능하므로, 소수점이 포함된 "1.1" 값은 FormatException 을 발생하게 됩니다.

이런 결함에 대한 버그 리포트를 개발자에게 할당하게 되면, 아마도 아래와 같이 프로그램의 소스 코드가 int.Parse 에서 float.Parse 로 변경될 수 도 있겠지요.

위와 같이 코드를 수정하면 프로그램을 정상적으로 동적을 합니다. 아래와 같이 말이죠^^

   

정말 버그가 해결된 것일까?

FormatException 에 대해 SDET 가 테스트한 테스트 코드를 통해 개발자(SDE) 가 코드를 수정하였습니다. 그리고 원하는 테스트는 다행스럽게도 통과(Pass) 했습니다.

   

모든 소프트웨어는 그 품질을 향상하기 위해 테스트를 진행합니다. 하지만, 버그가 없는 소프트웨어란 있을 수가 없습니다. 위와 같은 다행스럽게 SDET 가 버그나 결함을 발견하였더라도 앞으로 발견될 잠재적인 버그는 언제나 소프트웨어가 내포하고 있습니다. 즉, 완벽한 소프트웨어는 없다는 것이지요. SDET 는 이러한 버그와 잠재적인 버그를 효과적으로 발견 해야하는 매우 중대한 업무를 수행하는 직군입니다.

현대의 소프트웨어는 인터넷의 발달로, 언제나 제작사에게 피드백을 건의하고 버그를 건의하는 시스템이 구축이 되어 있습니다. 그 중 Microsoft 의 대표적인 것이 아래와 같습니다.

  • CEIP(Customer Experience Improvement Program)

    고객 또는 사용자의 동의하에 고객 경험 개선 프로그램에 참여할 수 있습니다. 이 정보는 고객의 피드백을 수집하기 위한 정보로 활용이 됩니다.

  • WER(Windows Error Reporting)

    Microsoft Windows 제품은 실제 매우 광범위한 영역과 자원과 비용이 할당된 제품입니다. 이 제품에서 발생하는 오류나 버그를 수집하기 위해서 WER 프로그램이 윈도우 내부에 탑재가 되어 있습니다. 이 정보를 기반으로 윈도우의 차기 버전이나 패치 버전에서 우선 순위로 할당되는 중요한 정보로 활용이 됩니다.

  • CER(Corporate Error Reporting)

    일반 고객이 아닌 기업 대상으로 소프트웨어를 사용한다면, 기업 내부에서는 오류 정보가 Microsoft 로 전송되는 것을 원치 않을 경우가 많습니다. 왜냐하면 기업의 시스템의 배치, 소프트웨어의 활동 등이 기밀 정보가 될 수 있고, 매우 조심스러운 부분이기 때문입니다. CER 은 Microsoft 로 정보가 전송되지 않고 기업 내부에서 관찰할 수 있는 프로그램입니다.

  • 스마일 전송 프로그램 : 추후에 설명할 예정입니다. 간략하게 고객이나 사용자의 감성을 데이터베이스화 하고자 하는 Microsoft 사용성 향상을 위한 프로그램 입니다.

   

개발자 보다 더 똑똑한 테스터!

위의 int.Parse 를 float.Parse 로 바꿈으로써 버그가 해결되었다고 볼 수 있습니다. 하지만 진정으로 버그가 해결되었다고 볼 수 없기도 합니다. 왜냐하면 테스트 케이스를 만족하지만 다양한 부류 집단인 '베타 테스트'에서는 전혀 다른 결과가 나올 수 도 있으니까요. 그리고 테스터는 바로 이러한 버그의 발생을 아키텍처/코드/기능적인 부분을 고려하여 버그를 유도할 수 있습니다.

만약, 유능한 SDET 라면 Float 으로 인한 결과 값 버그를 아래와 같은 테스트 케이스로 작성할 수 있습니다.

   

왜 결과 값이 당연이 1이 되어야 하지만, 1.000054 라는 황당한 값이 나왔을까요? 바로 컴퓨터의 내부 연산이 2진수로 이루어 진다는 것을 모르는 개발자나 테스트는 위와 같은 오류를 예감하지 못할 것입니다. 저 또한 제니퍼소프트의 정성태 과장님을 통해 이러한 문제를 처음 알게 되었으니까요.

정성태 과장님의 설명에 의하면,

"2진수의 소수점 표현들이 자리수에 따라서 1/2, 1/4, 1/8, 1/16, 1/32, 1/64 와 같은 식으로 표현이 되는데, 십진수 0.5 는 다행히 정확하게 1/2 에 맞아 떨어지지만, 십진수 0.6 은... 겨우 0.1 차이일 뿐인데 0.10011001100110011001 와 같은 2진수로 되어 버립니다. 근데 이것도 근사치일 뿐이지 1001 패턴이 계속 무한 반복 되어버리죠. 정밀도를 높이면 0.6 은 0.010011001100110011001100110011001100110011001100110011 로 표현이 되어버립니다."
더 자세한 내용은 http://k.daum.net/qna/view.html?qid=3wykn&aid=3xIOa 참고하세요.

만약, 이러한 문제가 회계 업무나 우주 공학에 적용이 된다면, 수억, 수십, 수 조원이 투입된 프로젝트에서 불에 뻔하듯 우주선이 폭발하거나 궤도를 이탈할 수 도 있는 심각한 문제를 발생할 수 있습니다. 실제로 이러한 문제로 일부 고객은 손해 금액에 대하여 마이크로소프트를 대상으로 법적인 대응을 한 사례도 있습니다.

Microsoft 가 이 문제를 몰라서 그랬을까요? 그렇지는 않습니다. IEEE(Institute of Electrical and Electronics Engineers) 표준으로 사용되었던 C 언어와 Pascal 언어간의 원활한 데이터 전달을 위해 C# 의 Float 도 같은 방식의 연산이 사용된 것입니다. 더 자세한 내용은 http://support.microsoft.com/kb/42980/ko 를 참고하세요.

   

그럼 어떻게 해결하나?

위와 같이 int.Parse 는 결함을 유발하기 매우 쉽지만, float.Parse 의 경우 더 깊은 이해가 필요합니다. 만약 테스트 케이스(Test Case) 가 이것을 유추하지 못한다면 얼마 되지 않아 소송에 휘말릴 수 있는 충분한 근거가 되겠지요. 만약 구현 명세서를 간파한 SDET 라면 이 수치에 대한 근거를 요구할 것이며, 테스트 과정에서 IEEE 745에 대한 테스트를 수행했을 테니까요.

현명한 테스터라면 float.Parse 의 타입을 Decimal 로 변경하기를 권장할 것입니다. Decimal 은 부동 소수점의 오류나 반올림에 대한 이슈를 해결할 수 있는 구조체(Struct) 입니다. 즉, 아래와 같은 구현이 회계 업무에 버그가 없는 코드가 될 것입니다.

   

테스터의 역할

테스터(SDET) 는 위의 간단한 예시와 같이 다양한 테스트를 진행하는 역할을 수행합니다. 그리고 그 역할이 매우 단순하고 초보 개발자가 수행할 수 있는 단순한 작업이 아님을 알 수 있습니다.

테스트 케이스(Test Case) 를 만들고, 다양한 테스트 시나리오를 계획하는 테스트 계획(Test Planning) 을 함으로서 소프트웨어의 잠재적인 버그를 하나씩 제거하는 매우 막중한 임무를 수행하는 직군입니다. 그리고 SDET 의 역할이 개발자(SDE) 의 코드적인 목적을 정확하게 간파하지 못하거나, 제품 전체적인 아키텍처, 프로세스를 이해하지 못한다면 더욱 더 많은 문제에 봉착하게 됩니다.

본 회에서 SDET 가 가지는 역할을 강조하기 위한 것이며, 추후에 테스트를 수행하기 위한 공학적인 기법에 대해서 차근 차근 알아보도록 할 예정입니다.

테스터 역할 배경에 대한 오해

이전 단원에서 "왜 단위 테스트를 해야 하는가" 에 대해 이야기를 해 보았습니다.

[ALM-Test] 왜 단위 테스트를 해야 하는가? [1]
[ALM-Test] 왜 단위 테스트를 해야 하는가? [2]

그리고 테스터의 역할 정의를 아래와 같이 하였습니다.

  • 업무 도메인의 이해
  • 테스트 도구 사용
  • 전반적인 테스트 시스템 인프라 와 운영체제(OS) 의 이해

하지만 필자도 테스트에 대한 공부를 시작하면서 몇 가지 오해를 하였던 것이 사실이었습니다. 필자는 대부분 SI, 컨설팅, 솔루션 개발을 하였고, 개발자 대신에 테스트를 해 주는 역할이 테스트라는 엄청난 함정에 빠졌던 것입니다. 자칫 함정에 빠진 이유는 SI 개발과 SM 이라는 유지 보수 업무의 장기 선상으로만 빗댄 것이었죠. 더불어 테스터의 역할은 업무에 따라서 충분히 달라질 수 있다는 것을 알게 되었습니다.

아마 대부분의 IT 개발직에 몸 담으신 분들이라면 저와의 생각과 크게 다르지 않을 것이라고 생각합니다. 일반적으로 작은 조직에서는 테스터(Tester) 직무만 보유하지만, 특히 대기업, 솔루션 업체나 게임 업계에서는 QA(Quality Assurance-품질 보증) 팀을 자체적으로 보유하는 것으로 알고 있습니다.

QA(Quality Assurance) 팀은 주로 소프트웨어의 버그/결함을 발견하고 개선하기 위한 업무가 수행됩니다. 그렇다면 이 QA 팀의 테스터는 기술자인가? 아니면 그냥 그저 그런 테스터인가? 기술자라면 어느 정도의 기술 요구사항이 필요한지, 그냥 테스터라면 어떤 단순 업무가 수행되는지, 궁금하지 않으십니까?

   

소프트웨어 1위 업계는 어떻게 구성이 되었는가?

단연, 소프트웨어 1위 업계는 Microsoft 입니다. Microsoft 는 초기 솔루션(제품) 이 개발되기 시작하면서(당시 1979년 인턴부터 시작하여) 테스터를 모집하여 참여했다고 합니다. 초기에는 STE(Software Test Engineer) 와 SDE/T(Software Development Engineer in Test) 라는 두 개의 직함이 있었는데, STE와 SDE/T 의 직무는 사실상 약간의 차이를 보였습니다.

STE 의 직무는 테스트 플래닝(Test Planning), 핵심 테스트, 테스트 자동화와 같은 테스트를 리드하는 직무였고, SDE/T 는 테스트 코드 작성, 코드 리뷰, 테스팅 툴 개발 등 실제로 일선에서 테스팅을 수행하는 직무였습니다. 2002년도 부터 SDE/T 직함을 없애려고 하였고, 2005년도에 SDE/T 가 SDET 로 명명되었습니다. 실제로 당시 시대적 배경으로 암시해보면 STE 의 비중보다 SDET 의 비중과 직원 증가율이 높았습니다. 왜냐하면 STE 는 주로 자동화 테스팅과 관련된 직무를 수행했는데, 사실상 시대적인 기술 한계 등으로 많은 활성화가 되지 않았던 것 같습니다.

결국 SDET 로 테스트 관련 직군이 모두 통합이 되었지만, SDET 도 각 직급이 존재하였습니다.

  • SDET1 : 테스트 케이스를 구현
  • SDET2 : SDET1 과 큰 변화는 없지만, 영향력이 고객과 직접적으로 의견을 교환할 수 있습니다.
  • Senior Software Development in Test : 테스트와 관련된 아키텍처가 가능하고, 문제를 해결할 수 있는 능력
  • Principal Senior Software Development Engineer in Test : 조직을 관리하고 테스트 방법론, 테스트 기술 혁신을 제시
  • Partner Software Development Engineer in Test : 조직 및 제품 전반을 이해하고 기술 혁신을 선도

특히, 현재 Microsoft 의 SDET 의 인원은 9,000명 넘는 인원이 직무를 수행 중이며, Microsoft Office 2007 제품에는 3,000 여명의 SDET 가 투입되었다고 합니다. 아래는 2008년도 대비 전세계 80,000여명이 넘는 직원 중의 각 분야별로 인원입니다. 특히 '제품 개발 및 지원' 은 SDE/SDET/Op(Operations)/IPE(International Project Engineering-현지화) 등등 을 모두 합한 것으로 9,000명의 SDET 라는 것은 거의 SDE 보다 SDET 가 더 많다고 합니다.

Op(Operations)
IT 분야를 관리하고, 네트워크, 서버를 관리 및 유지보수 하는 분야입니다. 즉 Microsoft 의 인프라를 주로 담당하며, 효과적으로 비용을 절감하거나 품질 좋은 서비스를 제공하기 위한 분야입니다.

IPE(International Project Engineer)
Microsoft 제품은 대부분 다국어 제품으로 출시하는데 각 나라의 특성에 맞게 변형하는 역할 (참고 : 국제화(i18n, internationalization): (1) 그거 번역하는거 아냐?)

   

SDET 의 자격 요건!!

SDET 는 적어도 소프트웨어 업계 1인자인 Microsoft 에서는 매우 중요한 직무임이 틀림이 없습니다. 그것이 우리나라에서는 SDET 의 역할이 그리 중요하지 않거나, 빅3 SI 업계에서는 공학적인 측면만을 강조하고 있다는 느낌이 드는 것도 사실입니다. (적어도 .NET 분야에서는 말이죠^^;)  

SDET 는 소프트웨어나 제품이 출시하기 위해 매우 막중한 임무를 수행하는 직무입니다. 한 명의 SDET 가 최선을 다하지 못한다면 버그/결함이 고스란히 고객에게 영향을 미치게 될 것이 분명합니다. SDET 는 소위 우리나라의 '베타 테스터'와 같이 먼저 사용해보고 평가나 버그를 제작사에게 알려주는 것이 아닌, 버그/결함을 제거하는 사명을 띠는 매우 크리티컬한 분야입니다.

버그와 결함에 대해서는 다음 회차에 명확히 할 예정입니다.

그렇다면, SDET 는 어떤 자격 요건을 갖추어야 할까요?

  1. C# 과 같은 객체지향적 언어 또는 필요한 언어적인 기술을 완벽히 갖추어야 한다.
  2. 특정 버그/결함을 디버깅하거나 리팩토링/개선이 가능해야 한다.
  3. 제품에 대한 기술적인 배경 지식을 갖추어야 한다.
  4. 제품이나 도메인에 대한 전체적인 프로세스/아키텍처를 이해할 수 있어야 한다.
  5. 테스트 케이스를 계획하고 테스트 공학적인 지식을 갖추어야 한다.
  6. 다양한 방법/기법으로 테스트 케이스를 작성할 수 있어야 한다.
  7. 테스트 케이스를 작성하거나 테스트 자동화에 대한 지식이 있어야 한다.
  8. 개발, 기획, 운영 팀 등과 커뮤니케이션을 원활하게 할 수 있어야 한다.

만약, 이 중에서 5개 이상 스스로 가능하다고 판단되지 않는다면, 필자와 함께 "[ALM-Test]" 연재를 꾸준히 구독하길 바랍니다. 그리고 5개 이상 수행이 불가능하다면 이미 SDET 가 아닌, "베타 테스터"라고 자칭하셔야 합니다.

필자 또한 테스팅 분야에 관심이 많았지만, 본격적으로 막 뛰어는 풋내기나 다름이 없기 때문에, 꾸준히 저와 함께 정보를 공유하거나 경험이 많은 분들의 가르침이 필요하다고 생각을 합니다.^^

   

왜 테스팅 분야에 뛰어 들었나요?

저는 약 1.5년 전부터 애자일(Agile) 방법론과 프로세스에 매우 관심을 갖게 되었습니다. 그리고 결국 깨닫게 된 것은 애자일을 경험하면서 우리나리 현실과 부합되지 않는다는 것을 몸소 느꼈습니다. 물론 제가 잘못된 애자일을 수행했을 가능성도 없지 않겠지요. 애자일은 점진적이고 반복적인 프로세스로 단지 프로세스 뿐만 아니라 사람 그리고 인격을 강조한 기만한 방법론이지만, 사실상 우리나라에서는 조직의 작은 팀 내부에서만 불화음 없이 수행 가능하던 그저 그런 것이었습니다. (참고:애자일에 대한 고찰)

어떠한 고객도 관심 없는 XP(eXtreme Programming), Scrum 를 수행하면서 자기 만족 수준에 불과했으니까요. 하지만, 일부 애자일 프로세스가 권장하는 방법을 버리고, 개선/조합하니 왠걸??? ^^

어떤 미친 기업에서 SDE:SDET=1:1 비율로 배치가 가능하며, 아무리 좋은 사례를 가져와도 실패하고 맙니다. 뿌와쨔쨔님의 영어이야기 중 "한국 미국, 자기소개의 차이점?" 을 보면서 또 한번 느낀 것이, 조직 단위 뿐만 아니라, 개인 단위로 이미 상하관계가 형성된다는 것입니다. (물론 단지 이런 이유 뿐만은 아닙니다)

Visual Studio 와 .NET 은 이미 테스팅 분야에 혁신을 진행하고 있고, 우리나라에서 소외되는 테스팅 분야에서 많은 할 일이 남아 있을 것 같아요. 작은 경험이나마 공유하고 도움이 되는 실전 테스팅 기법에 대해서 차근 차근 공부하면서 여러분들에게 알려드릴 계획입니다. 그리고 함께 생각을 정리하는 시간이 되길 바랍니다.

협업이 필요한 이유

최근의 소프트웨어 개발은 점차적으로 엔터프라이즈화 되어 가고 있습니다. 대용량/대규모화 되어가고 있는 현대의 소프트웨어 생태계에서 마치 새로운 트랜드로 자리잡고 있는 엔터프라이즈 2.0 이 자리를 잡고 그 규모를 넓혀가고 있습니다. 엔터프라이즈 2.0 은 Web 2.0 과 결합된 의미로써 즉, Enterprise social software(http://en.wikipedia.org/wiki/Enterprise_2.0) 라고 보아도 크게 의미는 다르지 않습니다.    

엔터프라이즈 소프트웨어는 대용량/대규모/보안 등의 핵심 키워드로 그 아키텍처가 매우 민감한 부분이기도 합니다. 하지만 엔터프라이즈 2.0은 기존 엔터프라이즈에 개방/공유 등을 강조하면서 바로 협업과 맞물리는 부분이기도 합니다. 그리고 이러한 움직임은 국가적인 차원의 거버먼트 2.0(http://blog.powerumc.kr/252)과 매우 유사하기도 합니다.    

즉, 중요한 것 중 현대의 소프트웨어 개발은 더 이상 폐쇄적인 환경을 거부하며, 최소한의 자원과 리소스를 아끼고, 남은 자원을 극대화하여 새로운 가치를 생산하고자 한다는 것입니다. 단지, 소프트웨어 개발은 개발자 역량만 훌륭하다고 되는 것이 아니며, 개발자간의 원활한 커뮤니케이션, 각 팀과의 원활한 커뮤니케이션, 더 나아가 조직과의 커뮤니케이션과도 연관 고리가 존재하게 됩니다.    

콩 심은 곳엔 콩이 나고, 팥 심은 곳엔 팥이 나야 하지만, 실제 프로젝트에서는 콩 심은 곳에 팥이 나기도 합니다. 협업을 하다 보면 협업 자체가 어려운 것이 아니라, 사람을 대하는 것이 가장 어렵다는 것을 느낄 수 있을 것입니다. 그래서 애자일(Agile) 한 방법론이 최근 팀과 조직에서 관심의 대상이 되는 것과 같은 이치입니다. 애자일 방법론을 잘 하기 위해서는 사람과 인간성을 이해하고 신뢰를 쌓는 것이지만, 그렇게 애자일하게 너그러운 사람과 팀, 조직은 그리 흔하지 않습니다.    

그렇다면 뭐가 문제일까요? 사람을 대하는 것이 어렵고, 고로 협업을 하는 것이 어렵고, 고로 전체 프로젝트를 수행하는게 어렵습니다. 개개인의 인격과 인간성을 존중하기엔 시간이 넉넉치 않을 뿐더러, 그들 간의 업무를 조율하는 것은 더 어려워지고, 점점 위태로운 프로젝트가 되기도 합니다. 물론 필자 또한 이런 문제의 발원지가 되기도 해보았고, 이것을 조율하는 입장도 되어 본 경험입니다.    

그럼 이미 답은 나왔습니다. 바로 "강제성" 을 부여하는 것입니다. 강제성이라고 하면 오히려 비 애자일하다고 할 수 있겠지만, 바꾸어 말하면 "당신 하나 때문에~" 애자일을 하는 것이 아니라는 것입니다. 가장 표준적이면서도 쉬운 방법을 통해 목표의 방향성을 가지고 간다는 것이 더 중요할 수 있기 때문입니다.

      

어떻게 커뮤니케이션을 할 것인가?

사람과 사람, 팀과 팀, 조직과 조직, 기업과 기업, 이들 간의 커뮤니케이션은 매우 다양합니다. 메신저, 이메일, 그 밖에 다양한 방법이 존재합니다.    

   

사람마다 선호하는 방법은 틀리겠지만, 개인적으로는 메신저야말로 가장 업무적으로 방해가 되는 커뮤니케이션 방법이라고 생각합니다. 언제나 급한 분들에게는 가장 좋은 커뮤니케이션 방법이 메신저가 될 수 도 있을 것입니다.    

제가 가장 좋아하는 커뮤니케이션 방법은 이메일입니다. 제가 이메일을 열람하고 싶을 때 보고 업무를 처리하면 되니까요. 하지만 이메일은 기록되고 보관되기 때문에 가장 책임감을 발휘해야 하는 커뮤니케이션 방법이기도 합니다. 하지만 요즘 스마트폰의 열풍으로 직장이든 가정이든 이메일을 볼 수 밖에 없는 현실이 되었죠^^;    

최근에는 SNS 와 같은 방법으로 커뮤니케이션을 하기도 합니다. 우리가 흔히 알고 있는 트위터(Twitter) 와 같은 Public SNS 도 존재하지만, 기업 내에서 사용할 수 있는 Private SNS 도 있습니다. 간단 명료한 메시지라는 강점으로 최근 유행하는 방식이기도 합니다.    

 

Team Foundation Server 의 구성 요소를 통한 커뮤니케이션

Team Foundation Server(이하 TFS) 는 단독적으로 사용할 때 보다 여러 가지 구성 요소를 갖출 때 비로소 가장 효과적인 커뮤니케이션 방법을 제공해 줍니다.    

최소한으로 TFS 는 SQL Server 를 필요로 하며, SQL Server 는 TFS 를 통해 소스 제어(Source Control), 리포팅(Reporting) 서비스를 제공해 줍니다. Team Foundation Server 를 사용하는 목적으로 SQL Server 라이선스를 일부 무료로 제공하기 때문에 가장 저렴한 비용으로 커뮤니케이션을 할 수 있는 방법입니다.

이를 이용하여 최소한으로 이행할 수 있는 여러 가지 기능이 있습니다.

  • 소스 제어(Source Control)
  • 소스 코드 브랜치(Branch)
  • 리포팅 서비스 및 데이터 웨어하우스(Reporting Services and Data Warehouse)
  • 일부 오피스(Office) 제품 연동

       

   

하지만 위의 방법으로는 조금 부족한 감이 있습니다. 마찬가지로 Team Foundation Server 를 사용하게 되면, SQL Server, Sharepoint Server 의 일부 라이선스를 무료로 제공하기 때문에 더욱 효과적인 커뮤니케이션 인프라를 구축할 수 있습니다. 특히 SharePoint 는 팀 포털과 문서 관리의 이점 뿐만 아니라, 팀 워크플로우를 개선할 수 있는 다양한 방법을 제공합니다. 특히 큰 규모에서는 의사 결정권이라는 막강한 권한이나 프로세스가 존재하게 되는데, SharePoint 는 이러한 워크플로우를 상당히 효과적으로 개선할 수 있는 솔루션이기도 합니다.

  • 소스 제어(Source Control)
  • 소스 코드 브랜치(Branch)
  • 리포팅 서비스 및 데이터 웨어하우스(Reporting Services and Data Warehouse)
  • 다양한 오피스(Office) 제품 연동
  • 팀 포털, 문서 관리, 팀 프로세스 개선

   

최근 가상화(Virtualization) 를 기반으로 클라우드 서비스가 매우 큰 개발 및 비즈니스 영역으로 자리잡고 있습니다. 소프트웨어 가상화는 물론이고 우리가 흔히 알고 있는 하드웨어 가상화 등 이러한 서비스 가상화를 통해 이전에는 상상하기 힘들거나 환경을 구성하기 힘든 영역까지 모두 커버하고 있습니다. Microsoft 에서는 이것을 가리켜 Dynamic IT 라고 칭하고 있습니다.

   

그 중, System Center 솔루션은 매우 다양한 역할을 수행합니다. 가상화 인프라와 서버 모니터링을 위해 다양한 솔루션은 아래와 같습니다.

솔루션

설명

SCVMM

(System Center Virtual Machine Manager)

물리적인 서버 또는 가상화의 서버를 관리, 배포, 최적화하는 솔루션이다. Hyper-V 또는 VMWare 등 여러 가상화 플랫폼을 지원한다.

SCOM

(System Center Operation Manager)

데이터센터의 운영을 중앙 관리를 위한 솔루션이다. 분산되어 있는 서버의 상태, 성능 정보, 구성 또는 보안 상태를 감지한다. 윈도우 운영체제와 리눅스(Linux), 유닉스(Unix) 운영체제 의 리소스나 그 하위 구성요소를 모니터링 할 수 있다.

SCCM

(System Center Configuration Manager)

운영체제 배포, 보안 패치, 서버/데스크탑 정책, 모바일 정책 등 총체적인 서버 및 클라이언트의 구성을 관리하는 솔루션이다. 기업의 네트워크 내의 모든 컴퓨터를 대상으로 강제 업데이트, 필수 구성 요소 등을 정책적으로 강제화 할 수 있다.

   

SCVMM(System Center Virtual Machine Manager) 은 가상화를 통한 동적 서버 관리, 가상화를 통한 유지 관리 계획, 가상화를 통한 테스트 및 개발 환경 의 작업을 관리하고 단순화 위한 가상화 관리 솔루션입니다. 가상화 서버를 관리를 용이하게 하고, 물리적인 서버를 가상화로 쉽게 전환하거나 가상 호스트에 여러 개의 물리적 서버를 통합할 수 있습니다.

특히 이 솔루션은 ALM(Application Lifecycle Management) 솔루션 중 Team Foundation Server 2010 에서 테스트 가상화를 사용하기 위해 필요한 구성 요소이기도 합니다.

   

SCOM(System Center Operation Manager) 는 분산되어 있는 데이터 센터를 통합 관리를 하며 윈도우 운영체제 뿐만 아니라 다양한 리눅스, 유닉스 기반의 운영체제를 지원합니다. 이 솔루션을 이용하면 특정 장애나 서비스 성능, 가용성을 보장하기 위해 자동으로 조치를 취하도록 할 수 있습니다.

   

SCCM(System Center Configuration Manager) 는 네트워크 인프라에 존재하는 클라이언트 컴퓨터, 서버 컴퓨터 등의 구성을 중앙에서 관리합니다. 예를 들어, 일부 클라이언트 사용자의 컴퓨터는 윈도우의 업데이트를 꾸준히 사용하지 않는 경우가 있습니다. 이러한 경우 강제적으로 업데이트를 수행하도록 정책적으로 관리를 할 수 있습니다. 그 밖에 윈도우 방화벽 설정, 자동 업데이트 및 백신 프로그램 등을 정책적으로 설치되거나 구성하도록 강제화 할 수 있습니다.

   

   

현재 협업을 위한 기본적인 기반 환경은?

단지, 필자가 오늘 하고 싶은 이야기는 여러분들에게 여러 가지 솔루션이 이를 대체할 것이라는 암시를 주는 것이 아닙니다. 단지 협업은 혼자만의 노력으로는 불가능 한 것이며, 이것을 뒷받침해 줄 수 있는 도구가 있다는 것에 감사할 뿐입니다.    

대부분의 우리나라 조직은 상하 수직적인 관계입니다. 일을 던져주고, 그것을 받고 일을 하는 수직적인 줄타기 방식은 작업의 결과를 매우 가시적이고 평가하기 쉬운 방법입니다. 그리고 이런 방식에 저 또한 매우 길들여져 있으며, 일을 수행하는 입장에서도 매우 수월합니다. 수행 결과를 보여주기도 쉽고, 처리하기도 쉽습니다.    

다만 수평적인 조직(절대적인 수평은 없을 것이지만)에서는 오히려 상하 수직적인 방식과는 다릅니다. 항상 중간 과정에 서로의 동의와 협력이 필요하며, 그 성과 또한 개인의 성과가 아닌 우리의 성과가 될 테니까요.    

하지만, 여러 조직과 기업이나 프로젝트에서 일을 해 본 경험으로, 절대적인 상하 수직적, 수평적인 조직은 없다는 것입니다. 그리고 필자 또한 어떤 것이 바람직한지 아직은 확신을 하기 어렵습니다. 다만, "그때 그때 잘~" 이라는 것밖에는 ^^    

팀워크(Team Work) 란 팀이 무너지지 않고 존재할 수 있는 가장 큰 힘을 발휘합니다. 반대로 팀 워크가 수년간 같은 방식이고 개선되지 않고 제자리에 머물러 있다면 썩은 우물과도 같습니다. 왜냐하면 시대가 변함에 따라 개개인의 커뮤니케이션 방식은 바뀔 것이며, 점차적으로 개선되어 지지 않는다면 팀 워크가 아닌 커뮤니케이션 자체의 문제의 한계에 부딪히게 될 것입니다.    

일단 오늘은 협업에 대해 썰을 풀어 보았습니다. 그리고 협업을 위한 많은 노하우를 여러분들에게 알려드리고 개선해 나가고자 합니다. 언제든지 불편한 내용이나 피드백을 주시면 참고하여 개선하고자 하도록 하겠습니다.

이전 글
[Software Development/Agile] - [ALM-Test] 왜 단위 테스트를 해야 하는가? [1]


이미 이전 포스트에서 얘기 했듯이, 똑같은 "단위 테스트"라는 단어를 가지고 개발자, 테스터, 고객은 각자 그 의미를 전혀 다르게 생각하고 있습니다. 이런 단어의 해석 조차 각자 틀린데, 애자일(Agility)하게 어떻게 소프트웨어를 만들 수 있을까요. 이미 "단위 테스트" 라는 작은 주제를 가지고 벌써부터 고객과 개발 조직간의 불화음이 발생합니다.

아니, 이미 개발 팀 내부에서부터 어디서 부터 시작해야 할지 어디둥절 할 수 있습니다. 그렇다면 과연 "단위 테스트" 가 결함의 발생을 줄이는 약이 될지, 팀 간의 커뮤니케이션 장애를 발생시키는 독이 될지, 그것은 아마 이 글을 읽는 독자 분들의 실천에서부터 시작될 것입니다.

이렇게 말도 많고 탈도 많은 단위 테스트를 왜 꼭 해야 하는지부터 짚고 넘어가 봅니다. 단위 테스트는 기능 또는 단위 별로 결함을 조기에 발견하기 위한 테스트 방법입니다. 하지만 "단위 테스트" 라는 단어만으로는 그 이해는 너무나도 상이하게 틀리다는 것입니다.

  • 개발자 - 단위 테스트 코드를 만드는 것
  • 테스터 - 개발중인 웹 어플리케이션 또는 클라이언트 어플리케이션 등을 만져보면서 기능 결함을 발견 하는 것
  • 고객 - 문서!! 기능에 대한 산출물 또는 보고서

일단 "단위 테스트" 에 대한 이해가 달라도 현재까지는 상관이 없습니다. 왜냐하면 단위 테스트가 가지는 의미를 제대로 이해하고, 공감대를 형성하는 것이지 어떻게 수행할 지는 적어도 지금은 중요하지 않습니다.

단위 테스트에 대해, 국내에는 번역본이 대부분이라 사실 우리 나라 실정에 정말 맞는지에 대해 많은 고민을 하였고, 적어도 필자는 이런 고민을 방관하고 싶지는 않습니다. "NO" 를 외치고 싶을 때는 외쳐야 하지 않겠습니까?

   

왜 버그가 발생하는가?

일반적으로 버그나 소프트웨어의 결함은 어떻게든 발생할 수 밖에 없습니다. 아무리 기계적이고 단순한 코드를 개발한다고 하더라도, 코드 간의 상호 연동, 클래스 간의 연동, 컴포넌트(Components) 간의 연동, 레이어(Layer) 간의 연동, 더 나아가 시스템 간의 연동.. 즉, 연동 또는 상호 종속적인 관계가 발생하는 시점부터 버그는 이미 예견될 수 밖에 없습니다. 쉽게 얘기하면, A 란 코드와 B 란 코드가 있습니다. 이 두 개의 코드는 분명히 다른 목적에 의해 개발이 되었지만, 목적 자체가 틀린 코드가 상호 연동 또는 종속적인 관계가 발생하게 된다면, 과연 어떨까요? 이것은 코드 자체에서 발생되는 결함이라기 보다 상호 연관 관계에 놓이면서 발생하는 결함이라고 볼 수 있습니다. 그리고 대부분의 중요한 또는 큰 버그는 이러한 얽히고 설키게 되는 연동/종속 이란 문제로 발생됩니다.

만약 버그가 발생되지 않는 상황이라도 A와 B 코드는 언제든지 업그레이드가 될 수 있습니다. 기능이 변경될 수 도 있고, 기능이 추가될 수 도 있습니다. 아무것도 모르는 최종 사용자(End user) 는 잘 되던 기능이 갑자기 안된다면 좀 어이없어 할 것입니다. 일부 이러한 코드가 최종 사용자의 요구에 의해, 그리고 최종 사용자를 위해 변경되지만, 최종 사용자는 결함을 발생시킨 원인을 알고 싶지도 않고, 단지 개발 팀을 신뢰할 수 없을 뿐입니다.

즉, 이러한 버그가 조기에 발견되지 않는다면 버그는 지속적으로 증식을 하게 됩니다. 가장 대표적인 예라면, 월별, 년별 정산해 주는 기능이겠죠. 이곳에서 만약 버그가 발생한다면 몇 일, 아니 몇 주를 이 버그를 해결하기 위해 많은 시간을 소비해야 할 것입니다. 실제로도 필자는 주변에서 이와 유사한 버그로 인해 고생하는 동료 개발자들을 많이 보아왔습니다. 결과적으로 모든 코드에는 버그가 발생할 가능성이 있고, 그것은 바로 연동/종속적인 관계가 시작되면서 집중적으로 발생하게 됩니다. 그리고 잠재적인 모든 코드가 버그의 대상이 되고, 잠재적인 버그가 가장 위험하다는 것입니다. 잠재적인 버그는 지금의 나도, 너도, 우리 모두가 모르는, 언제 발생할 지 모르는 버그이기 때문입니다.

이러한 주제로 필자는 이미 Techday 2009 에서 온라인 세미나를 한 적이 있습니다. 아래의 링크를 통해 간략한 단위 테스트 기술에 대해 미리 익히는 것도 좋습니다.

http://www.techdays.co.kr/Sessions/View.aspx?Id=40&mSeq=43

   

단위 테스트가 주는 의미

단위 테스트는 많은 곳에서 장점을 이야기 합니다. 예를 들어, "결함을 줄이고, 잠재적인 버그를 줄이고, 코드를 리팩토링 하게 하며…." 등등… 단위 테스트가 실제로 이러한 많은 장점이 있는 것은 필자 또한 강력하게 권장하고 싶습니다. 하지만, 아시다시피 "단위 테스트" 에 대해 개발자, 테스터, 고객과의 공감대가 형성되지 않은 이 마당에, 저런 소리를 하면 정말 비즈니스적인 가치가 있을까요? 아마도 고객은 단위 테스트를 한답시고 비용과 시간이 늘어난다는 것을 절대 용납하지 않을 것입니다.

그렇다면 단위 테스트가 우리에게 주는 의미는 무엇일까요? 단위 테스트를 형용할 수 있는 모든 단어를 떠올려 보십시오. 참 많습니다. 하지만 고객과 개발 조직, 그리고 비즈니스 측면에서 어떤 단어가 가장 잘 어울릴까요.

바로 단위 테스트는 "신뢰" 입니다. 개발 조직에서 개발자와 개발자간의 코드에 대한 신뢰! 개발 조직과 테스트 팀간의 신뢰! 그리고 단위 테스트의 결과는 매우 명확해서 고객과의 신뢰로 이어질 수 있습니다. 이러한 단위 테스트로 인해 장기적인 비용이나 리소스 절감 효과 등은 잠재적인 비즈니스적인 신뢰로 이어질 수도 있습니다. 만약, 개발 팀 내의 단위 테스트는 다른 개발자가 만든 코드와 연동해야 할 때 대한 최소한의 신뢰를 가지는 매우 신사적인 행위입니다.

즉, 개발자, 테스터, 고객과의 단위 테스트에 대한 이해가 틀리다고 하더라도, 최소한 단위 테스트라는 것을 했고, 그 결과가 명확했을 때 그 관계에서 "신뢰" 가 형성될 수 있습니다. 젊은 개발자가 아닌 고객은 자신의 과거의 경험에 빗대로 단위 테스트라는 것이 어떤 것인지 잘 모르더라도, 매번 명확하게 결과를 보여준다면 비록 버그가 발생하였더라도, 버그의 발생 시점이 명확하고 이 버그의 해결 결과 또한 명확하다면 "버그" 라는 단어로 절대 날뛰는 일은 없을 테니까요.

   

애자일(Agile) 한 팀 모델! 무엇이 문제인가...

자! 이제 단위 테스트에 대해 어느 정도 확신을 갖게 되었다면, 이것을 수행하기 위한 팀 모델이 필요합니다. 하지만 이러한 팀 모델을 구축하기 위한 시도는 매우 말이 많고 신중해야 할 부분입니다. 애자일을 도입하여 실패했다는 많은 히스토리와 사례들이 범람하면서 과연 애자일이 좋은 것일까라는 고민을 해 보아야 할 시기인 것입니다.

애자일이라고 하면 일반적으로 통용되는 XP(eXtreme Programming) 의 팀 모델과 스크럼(Scrum) 의 팀 모델은 현저하게 차이가 납니다. 그리고 글로벌 소프트웨어 개발 업체 중 단연 1위인 Microsoft 의 정보 기술 솔루션인 MSF(Microsoft Solution Framework) 의 팀 모델은 모두 다 다르다는 것입니다.

일단 현재 우리나라의 팀 모델의 특색은 매우 다양하고 변칙적이며, 상하 수직적인 관계입니다. 예를 들어, 개발자를 동일 선상의 개발자가 아닌 "대리급", "과장급", 일부 "부장급" 도 코딩을 하기도 합니다. 그리고 단순히 "개발 조직"이라는 단어 조차 어색하게 사수, 부사수 달랑 두 명이 개발을 하기도 합니다. 편의상 아래와 같은 형태가 되는군요. (이 부분은 조직마다 매우 다른 형태를 띌 수 있습니다)

어떤 모델에서는 개발자, 아키텍처, 테스터로 구분하지만 필자는 이러한 팀 모델이 전혀 한국적이지 않다고 생각합니다. 애자일과 MSF(Microsoft Solution Framework) 에서도 언급하지만 개발 팀에서는 우두머리, 즉 대장을 두지 말라고 조언합니다. 위의 그림에서 PL(Project Leader) 는 바로 개발 팀의 우두머리이며, 가장 테크니컬 하거나 경력, 또는 업무 도메인 지식이 뛰어나야 합니다. 그리고 한국형 조직이나 문화 특성상, 윗사람 또는 상사에게 코드나 아키텍처적인 문제를 언급하는 것은 매우 조직력이 부족한 사람으로 비추어지기도 합니다.

예를 들어, 한국의 개발자는 코드에 굉장히 민감하고, 곧 코드가 자신의 자존심이라고 생각하는 경향이 짙습니다. 적어도 필자 또한 마찬가지 입니다. 개발자는 자신의 사수에게 코드적인 문제를 언급한다면 충분히 문제의 소지가 발생할 수 있습니다. 데이터베이스 개발자일 경우 자신의 사수에서 SQL 쿼리에 대한 성능적인 문제를 지적한다면 자신의 부사수가 잘난 체 한다거나, "경력도 얼마 안되는 놈이 좀 안다고 까부네" 라고 생각하기도 합니다. 상사와의 관계가 아닌, 동등한 개발자 간에서도 다른 사람이 자신의 코드에 대해 지적하는 것은 '거의 인간 관계를 포기한 것'과 다름이 없다고 봐도 무리는 아닐 것입니다. (물론 어떻게 얘기를 잘 하느냐는 문제도 있겠지만요)

결론적으로 애자일 또는 MSF 가 언급한 팀 모델은 굉장히 이상적이지만, 전혀 우리나라의 특성을 적용하기가 힘이 들 수 있습니다. 위에서 예를 든, 단편적인 예만 봐도 애자일 또는 MSF 의 자유분방한 팀 모델은 우리나라 현실에 도입되기는 매우 힘이 듭니다. 작은 조직이라면 모를까, 거대한 엔터프라이즈 프로젝트의 경우 많은 점점 더 큰 팀과 또는 다른 업체와 함께 일을 하는 경우가 발생하기 때문에, 팀 내부가 아닌 팀 외부로 까지 애자일한 행위는 절대 금물입니다.

   

한국적인 애자일(Agile) 한 팀 모델

많은 사람들이 오해하는 것 중에 하나가 애자일의 XP 와 스크럼을 도입하기 위해 그것이 요구 또는 원칙, 권장하는 방법들을 반드시 따라야만 한다고 생각합니다. 이미 지난 포스트에서도 언급했듯이 고객은 명확한 일정을 요구하는 폭포수 모델(Waterfall Model) 을 요구하는데, 팀 내외부적으로 애자일(Agile) 을 외치고 있다가는 고객이 원하는 어떠한 일정과 조건에도 맞출 수가 없습니다. 우리는 이 시점에서, 애자일이라는 단어가 주는 의미를 다시 한번 상기해 볼 필요가 있습니다. 어떠한 애자일, MSF 에서도 그것을 반드시 이행하라고 명시하지 않습니다. 다만, '이렇게 이렇게 해보니 좋으니 너희들도 이런 방법을 써봐라' 라는 권장의 의미이지 강요가 아니라는 것입니다.

어쨌든, 개발자라고 하면 아래와 같이 두 가지 형태의 개발자가 있을 것입니다. 유지보수 인력인 SM(System Management) 이 있겠고, 개발 인력이 있습니다. 두 형태는 같은 개발은 하는 것이 맞지만, 깊은 내막은 전혀 다른 개발을 하고 있습니다. 일반적으로 개발 인력은 개발이 마치면 유지 보수 팀 또는 인력에게 인수가 됩니다. 그리고 인도적인 차원에서 각종 산출물을 뽑아내어 유지 보수 인력에게 모든 추후 버그나 추가적인 기능 개발이 떠넘겨지게 됩니다. 즉, 유지 보수 인력은 1년 365일 전산 시스템이 잘 운영되고, 지속적인 국가 정책이나 기업 정책, 그리고 고객의 요구를 시스템에 반영하는 역할을 하게 됩니다. 이 과정에서 일부 개발 인력이 유지 보수 인력으로 자연스럽게 전환되기도 합니다.

하지만, 좀 더 큰 기업에서는 개발 팀만해도 매우 복잡한 형태를 띄게 됩니다. 일단 내부 개발자, 외부 개발자가 분리가 되며 기업의 내부적인 정보를 공유할 수 있는 권한이 있느냐 없느냐로 볼 수 있습니다. 뭐 이러한 경우 사적인 자리에 까지 이어져, 점심을 함께 먹는 동료가 정해지기도 합니다. ^^; 외부 개발자는 일반적으로 프리랜서나 개인 사업자를 등록한 사람들이 됩니다. 하지만 대부분 프리랜서나 개인 사업자는 기업의 하청 업체를 통해 계약이 되는 경우다 더 많죠.

필자 또한 이러한 팀 모델과 현실과의 많은 고민을 하면서, 과연 어떠한 것이 한국적인 팀 모델이 될 것인가에 대한 고민을 끝없이 하고 있습니다. 마찬가지로, 필자가 좀 더 성숙해 지면 아래에 언급하는 팀 모델에 대한 생각이 바뀔 수 도 있습니다. 어쨌든 필자의 경험상 아래와 같이 팀 모델을 권장합니다.

위의 선은 직접적으로 커뮤니케이션 할 수 있는 범위입니다. 자세한 롤 모델(Role Model) 까지는 언급하지 않겠지만, 대충 커뮤니케이션의 통로와 작은 하위 팀을 보면 이해가 갈 것입니다. 특히 핵심 개발자 팀은 그 관리자나 일반 개발자와만 커뮤니케이션이 이루어지며, 이 핵심 개발자 팀은 외부 또는 타 업체가 될 수 도 있습니다. 일반 개발자에서 파생되는 여러 종류의 개발자는 모두 일반 개발자로 들어갑니다. 그리고 고객은 오직 관리자와 직접적으로 커뮤니케이션이 이루어지며, 경우에 따라서 품질 유지 팀에 의해 보고를 받을 수 도 있습니다. 애자일의 자유분방한 커뮤니케이션의 트랜잭션(Transaction) 을 넓은 범위에서 최소한으로 우리나라의 실정에 맞도록 줄이는 것이고, 관리자가 권한을 일부 위임해 주는 형태가 되는 것입니다.

또 하나, 필자가 애자일(Agile) 에 대해 공부를 시작하면서, 가장 답답했던 것이 바로 "고객의 자발적인 참여"를 기대한다는 것입니다. 일반적으로 개발 팀 입장에서 느끼는 고객은 굉장히 권위적이며, 상하 수직적인 관계입니다. 과연 애자일하게 프로젝트를 하면서 점진적인 릴리즈(Release) 를 통해 1달에 한번의 반복(Iteration) 으로 총 1년 동안 12번의 반복을 통해 점진적으로 최종 릴리즈에 도달한다고 가정해 봅시다. 이 릴리즈마다 고객의 자발적인 참여와 의견을 교류하는 이상을 생각하며, 첫 번째 릴리즈를 보여줬을 때, 과연 고객은 소프트웨어 개선을 위해 적극적인 참여를 할까 아니면 "내가 원하는 소프트웨어는 이게 아닌데?" 라고 할까요.

과연 그렇다면 여러분은 애자일의 의미에 대해 고객에게 세미나를 할 것인가요, 아니면 어떻게든 설득을 할 것인가요? 이미 고객의 경향을 알고 있는데, 그러한 고객을 설득하고 이해시키는 계몽(啓蒙)을 할 수 있을지 의문입니다. 그렇다면 이미 답은 나왔습니다. 고객을 변화시키지 못할 바엔, 차라리 우리가 변하는 것입니다. 즉, 개발 조직 내에서 불필요한 소음을 줄이기 위해, 어디에서 문제가 발생하는지, 그리고 소통이 어떻게 이루어지는지에 대한 트랜잭션(Transaction) 에 대한 관찰이 필요하다는 것입니다.

그리고 위의 그림과 같이 필자는 최종적인 트랜잭션의 소통이 현재 한국적인 가장 이상적인 애자일이 아닐까 생각합니다.

각 역할 별로 간단히 정리하자면, 아래와 같은 마음 가짐과 자세가 필요하겠군요. 물론 모든 조건을 완벽하게 갖추기보다는 최소한의 자세와 지식이 갖는 것이 유리할 듯 합니다. 자신이 부족한 부분이 있다면, 팀 동료가 이것을 뒷받침 해 주어야 겠지요. (유지 보수 팀은 복잡성을 줄이기 위해 여기에서 제외합니다)

관리자

  • 고객을 이해하고 개발 조직을 관리
  • 소프트웨어 품질을 지속적으로 유지 및 팀 조율

핵심 개발 팀

(Core Developer)

  • 기술적인 기반 지식
  • 프레임워크
  • 업무 도메인의 이해
  • 개발자 보호(Care) 및 지원(Support)

품질 유지 팀

(Test Team)

  • 업무 도메인의 이해
  • 테스트 도구 사용
  • 전반적인 테스트 시스템 인프라 와 운영체제(OS) 의 이해

일반 개발자

  • 기본적인 개발 지식
  • 할당된 개발 업무에 대한 책임감

   

품질 좋은 소프트웨어를 위한 단위 테스트

필자가 단위 테스트에 대한 필요성을 얘기하다가 뜬금없이 버그와 팀 모델에 대해서 이야기 하는 것이 의문일 수 있을 것입니다. 하지만 이 내용 또한 이전 포스트에서 이야기 했듯이, 소프트웨어 품질이 떨어지는 것에 대해 어느 누구에게 몰빵(?)할 수도 없는 문제이며, 단위 테스트에 대한 공감대가 없다면 절대 할 수 없는 것이기 때문입니다. 애자일이 우리에게 많은 자율성(Autonomy) 와 타이트함(Tightly) 를 주는 것은 매우 환영할 일이지만, 일부 정책적인 강제가 없다면 애자일은 우리나라에서 이미 실패한 방법론 또는 프로세스일 뿐입니다. 왜냐하면 우리나라의 고객은 아직까지는 변하지 않을 테니까요.

   

어쨌든, 단위 테스트를 위한 팀 모델의 세팅을 이쯤에서 마칩니다.

애자일(Agile) 프로그래밍 기법 등이 대중화 되면서, 특히 XP(eXtreme Programming) 에서는 단위 테스트의 코드를 먼저 작성하라고 합니다. 그것이 바로 TDD(Test Driven Development) 입니다.! 그 이유는 다들 아시다시피 간단합니다. 바로 코드를 작성할 때 설계부터 하라는 것입니다. 좀 직설적으로 얘기하자면, 생각 좀 하고 만들라는 것이죠. 생각 없이 만들 코드를 나중에 리팩토링(Refectoring) 할 바에는 처음부터 리팩토링 비용을 줄이고, 좀 더 세련된 디자인으로 코드를 작성하라는 의미입니다.   

단위 테스트(Unit Test) 라는 의미에서도 사실 개발자와 테스터, 고객과는 굉장히 괴리감이 있는 단어이기도 합니다. "단위 테스트" 라는 똑같은 단어를 사용하지만 그것을 받아들이는 사람의 직책이나 파트(Job) 이 어디냐에 따라 틀리기도 합니다. 아마도 애자일(Agile) 이라는 트랜드를 아느냐 모르느냐의 기준이 될 수 도 있습니다.

  • 개발자 - "테스트 코드를 만들라는 의미군!"
  • 테스터 - "나더러 테스트 코드를 만들라거야? 아니면 각 기능별로 테스트를 하라는거야?"
  • 고객 - "기능별 테스트를 어떻게?"

   

단위 테스트에 대한 개발자의 입장

우선 개발자를 봅시다. 필자는 개발자에게 TDD 를 강요하기란 굉장히 어려운 문제라고 생각합니다. 테스트 코드를 작성하는 것은 만들어진 코드의 양에 비례하여 추가적인 테스트 코드를 작성해야 합니다. 테스트 코드를 만드는 것이 문제가 아니라, 시간이 아깝다는 것이죠. 테스트 코드를 만들 시간에 더 생산성 있는(폼-Form 빼는 작업) 이 훨씬 더 나을 것입니다. 사실 우리나라 SI 프로젝트의 문제가 일단 소프트웨어를 만들고 난 다음에, 유지 보수 계약으로 버그를 잡아 치웁니다.

이런 구조는 실제 개발했던 사람과 유지 보수 하는 사람이 교체되면서, 유지 보수 인력은 이미 떠난 개발 인력들에게 "뭐 이런 쓰레기 코드를..!" 이라는 말을 할 수 밖에 없죠. 다시 개발했던 당사자의 입장으로 돌아가 보면, 빨리 빨리 대충 돌아가는 기능을 만드느냐, 느릿 느릿하지만 완벽한 기능을 만드느냐라는 기로에 설 수 밖에 없습니다. 여기서 고객은 언제나 쉽게 맘이 변합니다. 기존의 기능이 추가되거나 변경되면서 이미 완성된 기능에 지속적으로 덧칠을 할 수 밖에 없습니다.

그럼 TDD 를 왜 해야 하는가에 대한 의문점을 가질 수 밖에 없습니다. 단위 테스트조차 여유로운 작업이 아님이 분명한데, 테스트를 먼저하라니!!! 만약 누군가가 그것을 저에게 강요한다면 충분히 해명하거나 변경의 근거가 다분할 것입니다. 아마도 필사적으로 반대 입장에서 논의를 할 지도 모릅니다. 잘 차려놓은 테스트 코드를 돌려보는 관리자의 입장에서는 완벽한 프로세스일지 몰라도 적어도 개발자의 입장에서는 테스트 코드, 아니 TDD 마저 그저 먼 산일 뿐입니다.

   

단위 테스트에 대한 테스터의 입장

일반적으로 엔터프라이즈 어플리케이션(Enterprise Application) 은 기반이 되는 어플리케이션 프레임워크(Application Framework) 를 구축합니다. 범용 프레임워크를 이용하여 개발자가 사용하거나 소프트웨어나 업무 구조에 맞도록 도메인 집약적인 프레임워크로 파생하거나 전환됩니다. 이 과정은 진정한 기반 프레임워크에서 파생될 수 도 있고, 단순한 라이브러리 형태로 파생될 수 도 있습니다.

일단 팀의 구성원은, 개발 팀, 테스트 팀으로 구분합니다. 개발 팀은 오직 기능을 구현하고, 테스트 팀은 구현된 기능을 수동 테스트(Manual Test) 를 하거나 단위 테스트 코드를 작성하여 테스트를 수행합니다. 즉, 역할이 완벽히 분리되어 개발 인력은 개발에만, 테스트 인력은 원칙에 따른 테스트만 수행하는 형태입니다. 테스터가 테스트를 진행하면서 개발자가 구현해 놓은 기능에 결함이 발견되면, 개발자에게 이것을 알리고 반복적으로 테스트만 전담합니다. 이 프로세스에서 팀 간의 커뮤니케이션은 문서가 될 수 도 있고, 메신저가 될 수 도 있고, 메일이 될 수도 있습니다. 그것은 테스터에게 그리 중요한 것이 아닙니다.

하지만, 점점 더 고객은 특정 프레임워크나 아키텍처에 종속되길 원하지 않습니다. 그 이유는 과거의 잘못된 방법론이나 Non OOP(Object Oriented Programming) 의 확장성에 매우 민감합니다. 즉 기존에 어떤 아키텍처를, 어떤 프레임워크를 쓰던지 간에 현재와 미래가 더 중요할 수 밖에 없습니다. 이러한 과도기에서 과연 테스터는 무엇을 할 수 있을까요?

OOP 기반 프로그래밍은 추상화입니다. 그리고 추상화를 하다 보면 다형성을 따라가게 됩니다. 개발자나 아키텍처에게는 박수를 쳐줘야 하겠지만, 테스터의 입장에서는 전혀 그렇지 않을 수 있습니다. 즉, 테스터는 테스트 코드를 작성하기 위해 전체적인 아키텍처까지 이해해야 하는 어처구니 없는 상황이 발생할 것입니다. 아마도 잘 나가는 개발자들은 Mockup 을 이야기 할 것입니다. 그런데 누가 Mockup 을 할 겁니까? 아무것도 모르는 테스터? 아니면 코드를 작성한 개발자?

Mockup 에 대해서 아래의 링크를 참고 하세요.

http://blog.powerumc.kr/222

   

단위 테스트에 대한 고객의 입장

얼마 전에 엔터프라이즈 시스템의 확장성과 안정성에 대해서 고객과 미팅을 한 적이 있습니다. 고객은 현재의 프레임워크는 특정 프레임워크에 종속되어 확장이 불가능하며, 다른 프레임워크로 교체마저 불가능하다고 합니다. 그리고 과거의 기술을 사용하기 때문에 특정 벤더의 지원이 부족하고 그것을 이해하는 내부 직원도 없을 뿐더러, 시스템이 간혈적으로 다운되기도 한다고 합니다. 시스템이 돈(Money) 과 직결되는 문제라면 어느 누구도 나서서 고치겠다고 할 사람 없지 않겠습니까?

차세대 시스템에 대한 목표를 언급하면서 SOA(Service Oriented Architecture) 의 구현 산출물인 ESB(Enterprise Services Bus) 에 대해서 열심히 설명하면서, 단위 테스트에 대해서 언급을 한적이 있습니다. 그리고 대부분 고객의 관리자가 젊은 개발자가 아니기에, 이러한 최신 트랜드의 아키텍처와 방법론(?) 을 설명하면 기대 반, 의심 반으로 기대 심리를 갖기도 합니다.

하지만, 고객에게 단위 테스트에 대한 이야기를 언급할 때는 전형적인 과거의 산출물을 상상합니다. 바로 테스트의 이력을 볼 수 있는 문서이죠. 하지만 현재는 이미 그런 단위 테스트의 자동화와 산출물은 자동화가 되었음에도 불구하고 오히려 고객은 과거의 자신의 경험이 비추어 이해합니다. 이미 현재 시스템도 단위 테스트를 수행했고, 철저히 감사했음에도 불구하고 현재 이지경에 이르렀다는 것이죠.

즉, "단위 테스트" 라는 똑같이 형용하는 문자임에도 불구하고, 서로의 이해가 너무나도 부족합니다. 아마도 단위 테스트의 개념조차 없었던 코볼(Cobol), 포트란(Fortran) 의 원시 언어로 돌아가는 기분이 들었습니다. (학문적으로 고급 언어에 속하지만 과연 현재도 고급 언어일까?…) 즉, 그들과 눈높이를 맞출 수 있는 방법은 목표대로 보여주던가, 아니면 우리를 믿지 못하고 과거의 경험에 빗대어 비교할 것인가…

   

그렇다면 누가 단위 테스트를 수행해야 하는가?

아마도 이 섹션은 특히 필자의 개인적인 생각이기도 합니다. 어쨌든 "단위 테스트"에 대해 이렇게 이해 관계가 얽히는 풀기 힘든 문제이기도 합니다.

그럼 결론적으로 과연 누가 테스트를 수행해야 하는가 입니다. 아마도 필자의 개인적이고 경험적인 부분이므로, 다른 의견이 있다면 조언 부탁 드립니다.

우선 개발 팀과 테스터 팀의 조직적인 분할이 필요합니다. 즉, 팀 별로 역할 범위를 정확하게 명시함으로써 프로세스적인 측면에서 해결해야 할 문제라고 생각합니다. 이러한 문제는 Microsoft Solution Framework(MSF) 에서 잘 설명을 하고 있습니다.

아래의 필자의 분류는 우리나라의 전형적인 프로젝트 진행 구조를 고려하였습니다.

개발 팀

코드 개발, 단위 테스트 코드 개발

테스트 팀

매뉴얼 테스트(Manual Test), 테스트 인프라 관리

관리자

코드 및 테스트 조율 및 소프트웨어 품질 조율

고객

소프트웨어 품질에 대한 논의 및 제안

즉, 필자가 이렇게 구분한 의도는 어느 누군가에게 책임을 소프트웨어의 품질에 대해 소위 몰빵(?) 할 수 없다는 것입니다. 결국 가장 유연해야 할 책임과 역할의 구분이 명확하지 않는다는 것은 스스로의 무덤을 파는 것과 다를 바가 없습니다.

   

단위 테스트에 대한 적절한 대안은 있는가?

필자는 위와 같은 이유로 팀과 역할을 구분하여 단위 테스트를 수행하는 것을 권장합니다. 물론 위의 팀별 역할은 정답은 아니고, 조직의 형태에 따라 유연하고 적절하게 배분이 되어야 할 것입니다.

필자는 "단위 테스트" 라는 주제로 개인적인 견해를 이야기했지만, 더 나아가 소프트웨어를 개발하기 위한 방법론(SDLC-Software Development LifeCycle) 과 고객이나 기업의 거버먼스와 비즈니즈 가치가 결합되지 않으면, 좋은 소프트웨어를 절대 나올 수 없다고 생각합니다. 즉, 절대적인 방법론이 있고, 방법론을 적용한 경험이 있다고 해서 좋은 소프트웨어가 나올 수 없습니다. 극단적으로, 전산화가 제대로 되지 않은 업무 부처가 있음에도 불구하고 SOA 를 적용한다고 해서 절대 통합과 공유라는 컨셉을 가질 수 없는 것과 마찬가지 입니다.

애자일(Agile)의 대가인 켄트 백(Kent Back)은 아래와 같은 이야기를 한 바 있습니다.

Individuals and interactions over processes and tools
프로세스와 도구보다는 개인과 상호작용을

대부분은 애자일 선언의 이러한 용어로 인해, 매우 혼란스러워하거나 기존의 프로세스를 갈아치우려고 합니다. 마치 애자일의 XP 에서 이야기하는 원칙에서 하나라도 빠트리면 애자일이 아닌 것처럼 말입니다. 애자일의 주요 키워드는 "변화" 이지, 절대 강요가 아닙니다. 만약, 고객은 철저한 기간 엄수를 요구하는 폭포수 모델(Waterfall Model) 을 강요하지만, 개발 팀은 애자일(Agile) 만 고집한다면 그것은 서로 파멸로 가는 길이며, 애자일의 진정한 의미를 이해하지 않았다고 볼 수 있습니다.

켄트 백(Kent Back) 은 아래의 링크를 통해 위의 원칙에 대한 오해를 풀어내고 있습니다.

Tools for Agility - A White paper by Kent Beck, Three Rivers Institute

http://www.microsoft.com/downloads/details.aspx?FamilyId=AE7E07E8-0872-47C4-B1E7-2C1DE7FACF96&displaylang=en

.NETXPERT 의 안재우 수석님께서 저에게 조언을 주신 문서입니다.

오늘은 "단위 테스트" 에 대한 주제로 언급을 했습니다. 점차적으로 개발, 테스트에 대한 괴리감을 어떻게 줄이고 진정한 통합이라는 큰 주제를 통해 조금씩 파해쳐 보기로 하겠습니다. 

다음 글
[Software Development/Agile] - [ALM-Test] 왜 단위 테스트를 해야 하는가? [2]

애자일에 대한 고찰

Agile Development 2010. 3. 15. 08:30 Posted by POWERUMC

애자일에 대한 고찰에 앞서 먼저 '정말 TDD 필요한가?' 대해 이야기 부터 시작해봅니다.


애자일에 대한 고찰

애자일 프로그래밍이 도마에 오르면서 단연 단위 테스트(Unit Test)와 TDD(Test Driven Development) 를 빼놓을 수 없습니다. 단위 테스트와 TDD는 상호 공생 관계에 놓이면서, 둘 중 어느하나 포기하기 쉽지 않습니다. 왜냐하면 TDD에 대한 이상론자들은 TDD의 중요성을 매우 높이 강조하고 있기 때문입니다.

필자는 이에 대해 정말 개발에 TDD가 얼마나 좋고 효과가 좋은지 사실 산술적으로 검증할 수는 없다고 생각합니다. 좋은 것이 있는 많큼 잃는 것도 있을테니까요.


TDD 를 해야한다는 관점

일반적으로 코드를 작성한 후에 그 기능을 테스트하는 코드를 작성하는 것을 단위 테스트라고 합니다. 단위 테스트를 작성함으로써 결함없는 소프트웨어를 만들기 위한 지속적인 통합(CI-Continuous Integration) 라는 관점에서 상당히 효과적인 방법입니다.

여기에서 TDD 는 단위 테스트를 작성하는 단계의 순서를 기존의 Last 에서 First 로 바꾸면서, 단위 테스트 코드를 먼저 작성하도록 하는 방법입니다. 처음 오류가 날 수 밖에 없는 코드를 테스트하면서 Red, Green, Refactor 단계로 옮겨가도록 하는 기법입니다.

사실 이런 저런 TDD 의 효과중에 단연, 코드가 매우 견고해진다는 큰 장점이 있습니다.    

 

처음부터 기능을 구현하는 코드를 작성하게 된다면, 클래스와 메서드를 잘 분리한다고 하더라도 한 클래스나 메서드는 생각지도 않게 기능의 크기가 커질 수 밖에 없습니다. 왜냐하면 코드 작성자는 코드를 만드는 목적이 기능이 정상적으로 작동해야 한다는 전제하에 코드를 만들기 때문에 오류 없는 코드가 목적이기 때문입니다.

또 한가지 TDD를 하지 않는다면 코드의 리팩토링을 코드가 완료된 이후에만 가능하다는 것입니다. 지속적으로 이런 문제는 소프트웨어의 디자인이 바뀌거나 오류가 발생하지 않을 경우 굳이 리팩토링을 하지 않게 되죠.

결국 어떤 이유에서든지 좋은 코드를 만들기 위해서는 TDD가 매우 좋은 기법이 될 수 있습니다. 쉽게 Database 를 예로 들자면, 초기에 테이블을 정규화할 것인지, 나중에 문제가 생길 경우 정규화를 할 것인지의 고민과 유사하기도 합니다. 하지만 절대 변하지 않는 진리는, 처음부터 갈귀갈귀 정규화를 한 것을 합치는 것은 쉬워도, 통짜를 분리하는 것은 사실 엄청난 리스크가 됩니다.


TDD 를 하지 말아야한다는 관점

개인적으로 필자는 이 부류에 속하기도 합니다. 누구든 TDD를 알게 되면 그것이 가지는 이상적인 효과를 이해할 수 있습니다. 하지만 살짝 TDD에 발가락을 담구어보면 금방 TDD에 대해 의심을 하게 됩니다. 바로 TDD를 해보면 너무 어렵다는 것입니다.

첫번째로 Red, Green, 그리고 최종적으로 Refactor 단계로 가는 과정이 오래 걸리고 어렵습니다. TDD코드를 만들기 시작하는 순간부터 리팩토링의 시작이며, 길지 않은 코드조차 굉장히 버겁다는 것을 알 수 있죠. 정말 지루하고도 기계적인 과정입니다.

두번째는 이미 언급했다시피 지루하고도 기계적인 과정입니다. 즉 TDD기법으로 생상되는 코드는 기존에 코드를 만들고 테스트하는 예상 시간이 +a 가 됩니다. 코드의 양에 비례하여, 'stub(코드의 양) * alpha(가중치) = TDD 수행시간' 이라는 대략적인 예측 소요 시간이 걸릴 것입니다.

 

TDD의 시작은 곧 리팩토링의 연속입니다. 아무리 개발 도구가 좋아진다고 하더라도 사람이 하던 리팩토링을 대신해줄 수는 없을 것입니다. 즉, TDD기법을 도입하기 위해서 기존 방식의 산술적인 계산법으로 더 이상 기간과 공수를 예측할 수 없습니다. 분명 시간과 비용이 터무니없이 증가할 것입니다.

아마도 우리나라에서는 TDD를 조직내에서 개발 방법으로 채택하는 곳은 없다고 봅니다. 우리나라에서는 소프트웨어의 생산 기간을 어떻게 줄일까에 집중하고 있기 때문에, TDD는 팀과 조직의 goal 에 방해 요소만 뿐입니다. 효용성 측면에서 TDD 본다면 그저 좋은 개살구로 보이기 쉽기 때문입니다.


애자일을 명목으로 스스로 족쇄를 차고있는 우리 조직

애자일이라는 이름과 이상적인 가이드를 이행하려는 조직에서 특히 불화음이 많을 것입니다. 그리고 그들은 애자일을 해 본 결과 애자일은 왜 실패하냐는 물음을 던집니다. 사실 애자일이 가지는 그 사상은 굉장히 높이 살만 합니다. 기존의 폐쇄적인 조직을 개방하려는 의지를 보인다는 것으로 시작하여 팀간의 커뮤니케이션을 향상시키도록 합니다.

그런데 애자일을 도입하려는 사람들은 큰 함정에 빠집니다. 팀을 위한다는 명목으로 너무 많은 것을 팀에게 강요합니다. 자신이 바라보기엔 좋은 기법들이 많고 팀에게 전파하려고 노력하겠지만, 팀은 이미 기존에도 잘 되고 있는 부분을 왜 뜯어고치려는지 이해할 수 없기 때문이죠. 팀에게 변화라는 명목으로 팀원들의 공감을 얻지 못한채로 강요를 시작하게 됩니다.

사실 애자일한 팀과 애자일한 프로그래밍을 위해 애자일은 아무것고 강요하지 않습니다. 그런데 누군가의 손에 애자일이 쥐어지면 은근히 강요로 변질되는 경우가 대부분입니다.

 

애자일 중에, 특히 XP(eXtreme Programming) 는 우리나라 실정이 전혀 반영되지 않았습니다. XP 의 여러가지 기법 중에 특히 코드 리뷰 와 짝 프로그래밍이 대표적이죠. 짝 프로그래밍은 짝이 되어 서로의 생각과 노하우를 전수해 주는 기법이지만, 필자로써는 '글쎄…'

필자는 오히려 짝 프로그래밍을 함으로써 개인 업무 시간을 너무 할애당한다는 생각이 듭니다. 필자가 메신저의 채팅보다 이메일을 좋아하는 이유도 여기에 있습니다. 업무 진행에 탄력을 받다가도 채팅으로 내 생각의 컨텍스트가 강제로 전환됩니다. 생각이 정리되지 않은 상대편이 타자를 치고있는 것을 멍하니 바라만 봅니다. 기술적인 것을 물어볼땐 답을 알려줘도 채팅이라는 특성상 한번에 한줄의 글로 모든 것을 표현하기가 힘듭니다. 만약 이메일이었다면 보낸 사람도 생각을 정리해서 보냈을테고, 또한 내가 보고싶을 때 보고, 명쾌한 MSDN 링크와 곁들여 오히려 짧은 시간에 높은 성과를 낼 수 있을텐데요...

결국 짝 프로그래밍은 그것을 성취한 후의 성과가 소비된 리소스에 비해 턱없이 낮으며, 짝 프로그래밍의 특성상 지속성을 유지하기에 한계가 있습니다.

 

또, 코드 리뷰를 진행하기 위해 다양한 기법들과 절차를 선보입니다. Self Review, Pair Review, Team Review 등 전혀 현실을 고려하지 않고 단지 그 기법들에 대해서만 매달리는 사람들이 많습니다. 특히 코드 리뷰는 도구를 이용한 자동화를 하지 않을 경우 있으나 마나한 기법입니다. 장기적으로 코드 리뷰는 형식적일 수 밖에 없습니다.

더 중요한 것은 코드 리뷰 기법이 아니라, 프로세스적으로 이것을 통제하여 코드 리뷰 책임자를 두는 것이 효과적일 수 있습니다. 보안이나 성능 등에 관련하여 코드 리뷰의 책임을 위임하고, 보안이나 성능 문제 발생시에 책임을 물을 수 있도록 체계화된 프로세스 말입니다.

사실 이런 면에서 기존의 애자일인 XP(eXtreme Programming) 이나 스크럼(Scrum) 보다 MSF(Microsoft Solution Framework) 기존 애자일 방법론을 현실적이고 수행가능하도록 체계화시킨 프로세스이기도 합니다.

   

입장이 서로 다른 애자일

대부분 현장에서 개발하시는 분들은 내 옆의 동료나 우리 팀보다 자기 개인이 더 중요할 것입니다. 개인 업무 성과가 팀과 조직이 나를 판단하는 기준이 대부분의 경우이기 때문입니다. 또 어떤 경우는 개발자의 특성상 발언권이 없는 경우도 있을 것입니다.

이에 반해 팀의 관리자의 평가는 자신이 관리하는 팀 전체의 성과가 조직이 관리자를 판단할 것입니다. 팀 프로젝트나 팀의 업무 성과가 낮다는 것은 관리자의 능력과 비례하기도 합니다.

 

결과적으로 애자일이라는 공통 분모로 애자일의 목표를 이루고자하는 시각이 전혀 다르다는 것이죠. 서투른 애자일은 팀원의 불만만 증가할 뿐, 팀원과 공감대를 이루기 힘듭니다. 관리자의 입장에서는 팀원간의 커뮤니케이션을 높이고 팀원 스스로 변화하길 기대하고 이것이 소리없는 강요가 될 수 있습니다.

   

애자일을 성공시키기 위해

앞서 이야기한 바와 같이 애자일이라는 목표와 사상은 굉장히 좋습니다. 그것이 팀과 조직뿐만 아니라, 개인, 가족, 단체, 사회, 국가적으로 비유해도 좋은 모델이 될 것입니다. 하지만 애자일, 특히 XP 가 이루는 그 구성 요소들은 조금은 허무맹랑한 것들이 많습니다. TDD나 짝 프로그래밍, 코드 리뷰 등 현실성이 부족한 것들을 이행하기를 권장합니다. 적어도 우리나라에서는 그것을 이행하기 위한 주변 여건이 좋지만은 않지요.

 

예전 트로이 목마라는 전쟁 이야기에서 나오듯이, 적진에게 해를 가하기 위해 트로이 목마를 적진에게 가져다 놓았습니다. 적진은 트로이 목마를 보며 마치 신이 주신 선물로 생각하겠지만 정작 트로이 목마는 적군에게 해가 되는 무시무시함을 가졌습니다.

과학에서 모든 물체는 현재 상태를 유지하려는 힘, 관성을 가지고 있듯이 우리의 팀과 조직도 마찬가지 입니다. 애자일도 마찬가지로, 그것이 좋아보인다고 자신의 팀과 조직에 구역구역 쑤셔넣다보면 상태를 유지하려는 관성을 가진 구성원과 바로 맞닿을 수 있습니다. (물론 애자일이 해를 가한다는 의미는 아닙니다)

   

 

애자일이 추구하는 여러 구성 요소는 짧은 반복으로 결과물의 품질을 높이고 결함을 줄이고자 합니다. 애자일의 대부분의 구성 요소는 짧은 반복으로 인한 높은 위험성을 줄이기 위한 보조적인 수단이라는 것입니다. 예를 들면, 스크럼(Scrum) 을 도입한다고 해서 대시보드와 붙이는 메모지를 준비하고, 매일 매일 스크림 미팅을 할 필요는 없습니다. 스크럼 미팅이라는 형식에 갇히는 순간부터 자멸의 길이라는것을 뒤늦게 깨닳게 될 것입니다. 즉 스크럼 미팅은 매일할 필요도 없으며 어떤 다른 모습으로 바뀔 수 있고, 동료와 담배를 피거나 커피를 먹으면서 알게 모르게 나타날 수도 있습니다. 어떤 경우는 상대편 알게 모르게 하는것이 자연스러운 참여에 도움이 되는 경우도 있지요.

결론적으로 팀과 조직, 구성원 개인의 차이를 인정하고, 팀과 조직의 문화를 최대한 존중하는 것이 성공하는 애자일이 되는 것입니다. 필자 또한 이것을 깨닿기까지 많은 시행 착오를 겪으며 애자일로 인한 물음표에 종지부를 찍을 수 있었습니다. 즉, 애자일로 스스로에게 족쇄를 차지 마십시오. 족쇄를 끊은 후에야 진정한 애자일이 당신의 곁에 있음을 느낄 수 있을 것입니다.

 


오랜만의 포스팅입니다.

지난 글에서 말씀 드렸듯이, 이번 글에서는 새롭게 추가된 Data Flow Rules에 대해서 소개 드리겠습니다.

새롭게 추가된 8개의 Data Flow 규칙들

일단, 새롭게 추가된 규칙 목록을 먼저 보도록 하겠습니다.

CA1062 ValidateArgumentsOfPublicMethods: 함수의 인자유효성 검사 여부
CA1303 DoNotPassLiteralsAsLocalizedParameters: 문자열 인자의 Globalization 처리 여부
CA2100 ReviewSqlQueriesForSecurityVulnerabilities: SQL Injection 취약점 파악
CA2202 DoNotDisposeObjectsMultipleTimes: Dispose 메서드를 여러 번 호출하는지 여부
CA2204 LiteralsShouldBeSpelledCorrectly: 스펠링 체크
CA2215 DisposeMethodsShouldCallBaseClassDispose: Base 클래스의 Dispose 메서드를 호출하는지 여부
CA2241 ProvideCorrectArgumentsToFormattingMethods: Format 함수 인자 검사
CA2000 DisposeObjectsBeforeLosingScope: Dispose 메서드를 호출하는지 여부

이 규칙들 중에서, CA2000을 제외하면 모두 Visual Studio Team System 2005에서 이미 지원했었던 규칙입니다. 그리고 사실 CA2000도 VSTS 2005에 없었다 뿐이지, FxCop 1.35버전에서는 있었구요. 하지만 이 규칙들은 FxCop 1.36과 Visual Studio Team System 2008에서는 빠져있습니다.

이 규칙들이 빠졌던 이유에 대해서는 아래 URL을 보시면 됩니다.

http://code.msdn.microsoft.com/codeanalysis/Release/ProjectReleases.aspx?ReleaseId=556

즉, FxCop 1.35와 VSTS 2005에 있었던 Analysis 엔진에 성능의 결함, 버그, 일관적이지 못한 분석 결과 등의 문제가 있어서, 그 엔진을 VSTS 2008과 FxCop 1.36에서는 완전히 없애 버린 것입니다.

하지만, 이번 Visual Studio 2010에서는 화려하게 복귀가 되었습니다. 


Phoenix Framework의 탑재


그게 가능했던 이유는 새롭게 탑재된 Phoenix Framework 덕분입니다. 피닉스 프레임워크는 향후 마이크로소프트 컴파일러 기술을 위한 새로운 코드 최적화/분석 프레임워크입니다. C++/CLI 기반으로 만들어진 피닉스 프레임워크는 컴파일러, 코드 최적화, 자동 코드 생성 등 여러 분야에 사용될 수 있는 프레임워크인데요. 자세한 정보는 아래 URL에서 보실 수가 있습니다.

http://research.microsoft.com/en-us/collaboration/focus/cs/phoenix.aspx

https://connect.microsoft.com/Phoenix


그러면 다음 글을 통해서, 새로운 Analysis Engine인 Phoenix 프레임워크에 대해서 더 자세히, 그리고 어떻게 우리가 사용할 수 있을지 알아보도록 하겠습니다.

[Testing] Moq.NET (T/B Driven Development)

Agile Development 2009. 6. 29. 12:36 Posted by POWERUMC

 

Moq.NET

Moq 는 "Mock-you" 또는 "Mock" 로 부른다고 합니다. Moq.NET 3.0 은 C# 3.0 과 .NET Framework 3.5 를 통해 Linq Expression Tree 와 Lambda Expression(람대 표현식) 으로 직관적이고 생산적이라고 합니다.

이전에 봤던 웹 사이트 로그인 사용자 스토리를 다시 봅시다. 단, 이 예제에서는 복잡성을 만족하는 항목을 삭제합니다.

웹 사이트의 로그인 사용자 스토리

  • 사용자 아이디는 영문만 입력 가능하고 한글은 입력할 수 없다
  • 사용자 아이디는 최소 3자리, 최대 10자리까지 입력가능하고 초과시 경고 메시지를 보여준다
  • 사용자 비밀번호는 최소 5자리, 최대 20자리까지 입력 가능하고 초과시 경고 메시지를 보여준다

   

위의 사용자 스토리를 Mocking Framework 인 Moq.NET 을 이용하여 TDD와 BDD 형태로 테스트를 작성해 나갈 수 있습니다.

아래의 소스 코드는 Login 인터페이스를 정의한 코드입니다.

public interface ILogin
{

LoginResult Login(string id, string password);

LoginInputResult Valide(string id, string password);

}

   

public enum LoginResult

{

Authentication,

NoAuthentication

}

   

public enum LoginInputResult

{

Success,

MinLengthId,

MaxLengthId,

MinLengthPassword,

MaxLengthPassword

}

   

이제 Login 의 Behavior(행위) 측면에서 주도적인 개발을 하고자 합니다. BDD 이용하여 [그림1] 의 Clean up code 를 얻기 위한 목적이 아닙니다. 좀 더 TDD 에 가깝고, 디자인과 설계에 초점을 맞추고자 합니다.

class Program
{

static void Main(string[] args)

{

var id = "powerumc";

var pwd = "aaaa";

var mock = new Mock<ILogin>();

}

   

private static string minString(int length)

{

return Match<string>.Create( o => o.Length <= length );

}

   

private static string maxString(int length)

{

return Match<string>.Create( o => o.Length >= length );

}

}

   

위의 코드를 통해 Mocking Object 를 생성하도록 Mock<T> 생성자를 볼 수 있습니다. 바로 Mock<T> 를 통해 Mocking Object 를 생성합니다.

아래의 코드는 위의 로그인 사용자 스토리에서 입력되는 아이디/비밀번호의 유효성을 검사하도록 Mocking Object 를 설정합니다.

// Validate

mock.Setup( o => o.Valide(minString(3), It.IsAny<string>()))

.Returns(LoginInputResult.MinLengthId)

.Callback(()=>Console.WriteLine("ERROR> MinLengthId"));

mock.Setup( o => o.Valide(maxString(10), It.IsAny<string>()))

.Returns(LoginInputResult.MaxLengthId)

.Callback(()=>Console.WriteLine("ERROR> MaxLengthId"));

mock.Setup( o => o.Valide(It.IsAny<string>(), minString(3)))

.Returns(LoginInputResult.MinLengthPassword)

.Callback(()=>Console.WriteLine("ERROR> MinLengthPassword"));

mock.Setup( o => o.Valide(It.IsAny<string>(), maxString(20)))

.Returns(LoginInputResult.MaxLengthPassword)

.Callback(()=>Console.WriteLine("ERROR> MaxLengthPassword"));

   

아래의 코드는 유효성을 통과한 아이디/비밀번호로 로그인을 시도하고 결과값을 리턴하는 Mocking Object 입니다.

// Login

mock.Setup( o => o.Login(It.IsAny<string>(), It.IsAny<string>()))

.Returns(LoginResult.NoAuthentication)

.Callback(()=>Console.WriteLine("No Authentication"));

mock.Setup( o => o.Login(id, pwd))

.Returns(LoginResult.Authentication)

.Callback(()=>Console.WriteLine("Success Login"));

   

자, 그럼 가상의 Mocking Object 를 통해 인터페이스만으로 로그인 시도를 해보도록 하겠습니다.

var obj = mock.Object;

var loginInputResult = obj.Valide(id,pwd);

   

if( loginInputResult != LoginInputResult.Success ) return;

   

obj.Login(id,pwd);

   

입력 변수 값에 따라 비록 Mocking Object 지만, 테스트 시나리오를 충분히 검증할 수 있습니다.

Id="aaa", pwd="aaa" 일 경우는 아래와 같은 결과가 나타나겠죠~?

 

Id="powerumc", pwd="aaaa" 일 경우는 아래와 같이 모든 테스트 시나리오를 통과한 결과입니다.

 

그럼, Microsoft Research 프로젝트의 일환인 Pex 를 이용하여 Mocking Object 를 Testing 해보겠습니다. Pex 테스트 프로젝트를 생성하고 아래의 PexMethod 를 만들었습니다.

아래는 테스트 결과입니다. 총 31개의 테스트 케이스 중에 통과되는 1개의 테스트를 확인할 수 있습니다.

자 어떻습니다~? 전혀 구현 코드를 구현하지 않았음에도 인터페이스를 통해 TDD-테스트 주도 개발이 가능합니다. BDD-행위 주도 개발을 통해 번거로운 TDD 의 Red, Green, Refector 의 유한반복 사이클 없이도, 실제 인터페이스의 디자인과 설계에 초점을 맞추어 테스트를 진행하였습니다.

단순히 BDD 가 최고야~ 라는 말은 아닙니다. 우리가 BDD 를 통해 TDD 를 좀 더 쉽고, 근접하게 접근할 수 있습니다. 그리고 코드의 구현이 전혀 없이 오직 디자인과 설계에 초점이 맞추어져 있다는 사실을 알면 됩니다. 바로 Moq.NET 은 Mocking Object 를 통해 TDD 와 BDD 개발을 통해 좀 더 품질 좋은 WhiteBox Testing 의 기대효과를 누릴 수 있습니다.

데이터베이스의 데이터를 조회하여 테스트한다고 할 때에도, 반드시 데이터베이스가 존재하지 않아도 됩니다. 가상의 데이터베이스 커넥션 객체를 만들어서 쓰면 됩니다. 쇼핑몰 사이트에서 결재 프로세스를 테스트해야 하나요? 그렇다면 가상의 객체를 통해 설계된 결재 프로세스가 합당한지 Mocking Object 를 통해 테스트를 하면 됩니다. 그 이후에는 잘 설계된 인터페이스를 구현하기만 하면 되겠죠?

   

이 외에도 WikiPedia 에 Mock Library 의 종류가 있네요. 아무튼 테스트와 Moq.NET 에 대한 내용은 여기까지 하는 것으로 마치도록 하렵니다.

 

참고 문헌

http://en.wikipedia.org/wiki/Mock-object
http://behaviour-driven.org/

그렇다면 BDD (Behavior-Driven Development) !

TDD 는 그렇다고 치고, 이제는 BDD(Behavior-Driven Development-행위 주도 개발) 가 왠말이냐 -_-; 저 또한 Moq 에 생소한 나머지 여기까지 추적하게 되었습니다. 모두가 TDD 가 좋은 줄은 압니다. 종속적인 기능이나 코드가 정상적임을 증명하고 점진적으로 테스트 코드를 만듦으로써 자연스럽게 세부 설계를 생각하게 할 수 있습니다.

나에게 "TDD" 를 요구한다면 나에게 "시간"을 달라

어째든, BDD 는 소프트웨어 품질을 향상하기 위해 개발자간에 협력할 수 있는 Agile Software Development 기법입니다. BDD 의 목표는 TDD 를 수행하기 위한 것이며 TDD 의 접근법을 전환한 것입니다. TDD 의 딱딱한 어휘를 정리하고 설계나 디자인에 초점이 맞추어진 패러다임의 전환이라고 합니다. 그리하여 TDD 를 수행한다는 본질은 변하지 않지만, TDD 를 수행하기 위해 BDD 를 통해 행위 자체는 변할 수 있다는 것입니다.

더 자세한 내용은 아래의 Behavior-Driven Development 공식 사이트를 참고하십시오.

Behaviour-Driven Development
http://behaviour-driven.org/

또한 Agile Software Development 에서 각 이터레이션(Iteration)에서 수행하게 될 사용자 스토리를 통해 기능이나 구현에 대한 스팩을 정의할 수 있습니다. 즉, 애자일의 사용자 스토리는 바로 테스트를 수행하는 테스트 시나리오로 이어지게 됩니다. 헌데, TDD 로만 수행되는 테스트 시나리오는 실제로 변화에 능동적으로 대처하지 못할 수 있는 경우도 존재합니다.

예를 들어, 설계자는 개발자에게 아래의 스팩이 만족하는 로그인 기능의 "사용자 스토리" 를 정의합니다.

웹 사이트의 로그인 사용자 스토리

  • 사용자 아이디는 영문만 입력 가능하고 한글은 입력할 수 없다
  • 사용자 아이디는 최소 3자리, 최대 10자리까지 입력가능하고 초과시 경고 메시지를 보여준다
  • 사용자 비밀번호는 최소 5자리, 최대 20자리까지 입력 가능하고 초과시 경고 메시지를 보여준다
  • 사용자 비밀번호는 복잡성 만족도를 우측에 색깔과 메시지로 보여준다

위의 사용자 스토리에 만족하도록 TDD 를 수행해야 하는데, TDD 를 수행하기 위해서는 반드시 스토리의 우선 순위대로 진행해야 다음의 테스트 코드를 작성할 수 있습니다. 그런데 여기에 엄청난 함정이 있을 수 도 있습니다.

  • 초/중반의 우선순위의 사용자 스토리의 규모가 한 이터레이션의 주기와 맞먹는 경우라면 TDD 를 어떻게 수행할건가요?
  • 또는, 로그인 시나리오(에피소드, 테마) 안에 고객의 쉽지 않은 요구사항이 추가되었다면 어떻게 할건가요?

예를 들면, 설계가 진행 도중 아래와 같은 요구 사항이 추가가 되었다고 가정해 봅시다.

  • 로그인은 SSO(Single Sign On) 을 통해 로그인하며, SSO 중앙 서버를 통해 인증해야 합니다.

 

기가 막히군요. 아직 SSO 서버는 구축이 되지 않은 상태이고, 단일 시스템간에 명확한 프로토콜도 정의되지 않은 시점입니다. TDD 를 수행하기 위해 SSO 중앙 서버와 프로포콜이 구축되지 않는다면 더 이상 로그인과 관련된 작업은 진행할 수 없게 됩니다.

자! 바로 이런 경우 행위 주도 개발-BDD 가 빛을 발할 때입니다. BDD 의 행위 주도 개발은 인터페이스와 구현을 분리하고 인터페이스에 집중할 수 있습니다. 즉, 어떠한 구현 코드가 없이도 BDD 를 통해 인터페이스만으로 테스트나 코드를 통해 설계 작업을 진행할 수 있게 되는 것입니다.

구현 코드가 없이 인터페이스만으로 테스트를 진행한다니요? 이거 말장난 아닙니까? 아닙니다. 객체의 구현은 전혀 알 필요 없습니다. 단, 내부적인 테스트 시나리오를 알고 있는 것만으로 테스트를 진행하게 됨으로써, 인터페이스의 디자인이나 설계에 집중하게 됩니다.

이번에 Moq.NET 3.0 버전이 릴리즈 되었습니다. Moq.NET 는 Mocking Object 를 통해 특정 테스트를 진행하고 훨씬 TDD 기반에 근접한 테스팅을 가능하게 합니다. 즉, Mocking Object 는 실제 클래스나 개발이 완료되지 않는 시점에서부터 테스트를 가능하도록 합니다.

그런데 필자는 Moq.NET 를 이해하는 과정에서 내가 알고 있던 것보다 더 깊은 배경이 있었다는 것을 알게 되었습니다. 예를 들어, TDD 외에 BDD 또한 애자일 개발 방법론에 포함된다는 사실과, 조금은 낯설은 BDD-행위 주도 개발을 직접 체험해 보는 과정에서 말입니다. ^^ 

   

왜 TDD (Test-Driven Development) ?

TDD 가 좋으면서 쓰지 않는 이유는 뭘까요? 일반적으로 완벽한 TDD 를 수행하는 과정은 매우 힘듭니다. TDD 에 대한 이론을 들었을때는 확 가슴에 와닿지만, 이것을 몸소 체험하는 과정에서 개발자의 인내력의 한계를 올려놨다 내려놨다 하는 극한을 체험하게 합니다^^; 그러므로 일반적인 TDD 사이클인 Red, Green, Refactor 는 사람을 금방 지치게 만들죠^^; 한 사이클을 마치기 위해서는 많은 시간이 투자되어야 한다는 겁니다.

[그림1] TDD Process

하지만 우리가 TDD 를 수행하는 목적은 이러한 과정에서 코드에 대한 신뢰도를 향상시키고 품질을 향상시키고자 하는 것입니다. 그렇기 때문에 하고자 하는 목적이 보다 나은 품질을 보장하기 위해서라면 TDD 가 필요하다는 것이 머릿속으로만 느낌이 팍팍 옵니다^^;

이제 슬슬 스스로에게 딜레마다 옵니다. 좋은 줄은 알지만 누군가 나에게 TDD 를 강요한다면 아마도 전 "Oh~ No!" 라고 할 것 같네요 -_-;

 

WhiteBox Testing & BlackBox Testing

Moq 를 이야기 하기도 전에 정말 딴소리를 많이 하네요. 일반적으로 테스팅은 크게 WhiteBox Testing 과 BlackBox Testing 으로 구분할 수 있습니다. 이 두 가지 테스팅의 차이는 좁은 범위에서 내부적인 프로세스를 아느냐 모르느냐의 차이고요, 넓은 범위에서는 테스트 레벨의 차이라고 보시면 됩니다.

다음의 그림을 보면 좀 더 이해가 쉬울 겁니다.

[그림2] BlackBox Test 와 WhiteBox Test

즉 BlackBox Test 와 WhiteBox 테스트는 그 목표의 설정이 다르게 됩니다.

BlackBox Test 는 로그인 기능에 대해 요구사항이 있고, 그 기능이 반드시 가져야 할 스팩이 있을 것입니다. 요구사항을 통과하기 위해서는 로그인 기능의 스펙을 만족하면 되고, 실제 단위 테스트 등으로 그런 케이스를 통과를 하면 됩니다. 즉, 내부적으로 어떻게 동작하는지는 알아야 할 필요가 없으므로 수십/수백가지의 테스트 케이스를 통과하여 기능이 정상적으로 동작하는 것을 보장하기 위한 목표입니다.

WhiteBox Test 는 해당 기능에 대해 내부적인 구조를 기반으로 테스트를 진행하게 됩니다. 테스터는 이미 위의 로그인 기능이 내부적으로 어떤 프로세스로 진행되는지 알고 있으며, 예측 가능한 테스트 시나리오를 작성하여 테스트를 진행하게 됩니다. 이 테스트의 목적은 테스트 케이스를 통과하는 BlackBox Test 를 한 단계 뛰어넘어 잠재적인 오류까지 테스트를 통해 잡아내는 것이 목표입니다.
즉, 코드상의 Memory Leak 이나 SQL Injection, Stack Overflow 등 잠재적인 오류를 미리 찾는 경우도 있습니다. 이미 이런 기능은 Visual Studio 2005 이상부터 지원되는 정적 코드 분석(Static Code Analysis) 가 제공이 됩니다. 또, WhiteBox Test 는 코드 커버리지(Code Coverage) 의 수치를 높임으로써 테스트가 안된 코드의 양을 최소화 시키고, 궁극적으로 소프트웨어의 품질을 향상시키는데 있습니다.(Software QA)

[Better Code]Visualize Code Relationships

Agile Development 2009. 5. 2. 18:40 Posted by kkongchi

image

위 그림처럼 이번 Visual Studio Team System 2010에서는 Analyze(분석) 메뉴에 새로운 기능이 하나 더 추가되었습니다. 바로 Visualize Code Relationships 메뉴입니다. (아직 한글로는 어떻게 번역될 지 잘 모르겠네요)

이 기능은 제목 그대로 코드의 관계를 시각화해서 보여 줍니다. UML 다이어그램과도 조금 다르고, 모델링 용의 DSL 다이어그램과도 조금 다르긴 하지만, 꽤 괜찮은 그림을 보여줍니다.

그림을 한 번 보기 위해서, 아래와 같은 아주 간단한 Visual Studio 솔루션을 한 번 구성해봤습니다.

image

구조는 간단합니다. WebApplication1이 WebService1을 Web Reference를 해서 호출하고, 다시 WebService1은 ClassLibaray1을 내부적으로 Reference해서 호출하는, 아주 흔한 형태의 Application 구조입니다. 그리고 ClassLibrary1 내부에서 Class2는 Class1을 사용합니다.

이 구조가 어떻게 시각화 되는지 한 번 볼까요?

1. Visualize Call Dependency – By Assembly

image

오른쪽 옆의 버튼을 누르면, 내부로 펼쳐지면서, 내부에 들어있는 클래스도 보입니다.

image 

2. Visualize Call Dependency – By Namespace

image

3. Visualize Call Dependency – By Class

image

프로젝트가 성숙하고 발전되면, 코드도 따라서 많아지면서 구조도 복잡해지기 마련입니다. 복잡도가 높아지면 높아질 수록 유용한 툴이 되지 않을까 싶습니다.

하지만, 지금 그림을 보시면 아시겠지만, WebApplication1이 Web Service1를 Web 참조를 하고 있습니다만 그림에는 그 참조 관계는 표시가 제대로 되질 않네요. 결국 직접적인 참조 외에는 다이어그램에서 보기가 힘든 것 같습니다. 쉽지 않겠지만, 그런 부분들도 표시할 수 있었더라면 정말 환상적이었을 텐데 하는 생각이 듭니다.

 

지난 번 글에서 Visual Studio Team System 2010의 향상된 Unit Test 기능에 대해서 살펴 본 바가 있었습니다. 오늘 소개드릴 PEX는 Microsoft Research 그룹에서 개발한 Automated Whitebox Testing Framework 입니다. 꽤나 긴 정의입니다만, 간단히 말하자면 자동으로 코드를 분석해서 WhiteBox Unit Test를 만들어주는 Visual Studio Extension입니다.

Blackbox Test – Blackbox Test는 우리가 코드 내부에 대한 지식이 없다는 것을 전제로 합니다. Blackbox Test에서는 코드의 노출된 API를 소비하는 Consumer의 입장에서 Function을 테스트하게 됩니다. 비교적 초기에 작성되는 Unit Test들은 이 Blackbox Test가 됩니다. 아직 Code가 성숙되지 않은 상태에서 API의 Requirements, Specification 등만을 가지고 테스트를 작성하게 되기 때문입니다. 하지만 코드 개발이 점점 진행됨에 따라서 Unit Test는 Whitebox Test로 이행되게 됩니다.

Whitebox Test – Whitebox Test는 코드 내부를 알고 있다는 것을 전제로 하는 테스트입니다. 우리는 코드를 알기 때문에 모든 가능한 성공/실패 시나리오를 모두 알 수가 있고, 특정 데이터나 입력 조건이 어떤 Flow를 따르는지에 대해서 충분하게 알 수 있습니다. 이런 가능한 모든 시나리오에 대해서 Unit Test를 작성하고 수행하게 되면 그것을 Whitebox Test라고 말할 수가 있습니다.

* 이는 Blackbox Test, Whitebox Test에 대한 일반적인 정의가 아니라, Unit Test관점에서 바라본 정의입니다. 일반적인 정의에 대해서는 Wikipedia의
Whitebox Testing, Blackbox Testing 항목들을 참고하시기 바랍니다.

Unit Test를 수행할 때에 대개 Code Coverage Test를 같이 수행하는 이유가 바로 우리가 작성한 Unit Test가 어느 정도 수준의 Whitebox Testing에 도달했는지를 알 수가 있기 때문입니다. 당연히 우리가 작성한 모든 코드에 대해서 완벽한 Whitebox Testing을 Unit Test를 통해서 수행했다면 Code Coverage Test의 결과는 100%가 되어야 합니다. 하지만, 실제로 Unit Test건 Manual Test Case건 Code Coverage Test결과가 100%에 도달하기는 참으로 힘듭니다. 일반적으로 80%정도를 목표로 하지만, 그 이하가 되는 경우가 대부분입니다. 그것은 복잡성의 문제이기도 하고, 비용 대비 효과의 문제이기도 합니다. 코드의 모든 경로를 통과하는 Unit Test를 작성하려면 엄청난 시간이 소요될 테니까요.

이 점이 PEX라는 제품이 나오게 된 배경이라고 할 수 있습니다. PEX는 Visual Studio의 코드를 분석해서, Input과 output 조합을 찾아서 자동으로 테스트 코드를 만들어 줍니다. 자동으로 생성된 테스트 코드이지만, 높은 Coverage를 보여 줍니다. PEX를 사용하면, Unit Test 작성에 들이는 수고를 상당히 줄일 수 있을 것 같습니다.

 

PEX 홈페이지는 http://research.microsoft.com/en-us/projects/pex/default.aspx 이며, 현재 Visual Studio Team System 2008과 2010에서 사용할 수 있다고 되어 있습니다. 즉, 현재 VSTS 2008을 쓰고 계시는 개발자 분이라면 다운로드 받아서 써 보실 수 있다는 의미입니다. 현재 정식 버전은 아니고 Pre-release 버전입니다. 그리고 Visual Studio 2008 Professional 버전을 위한 비 상업용 Academic 버전도 다운로드 받을 수 있습니다. 다운로드 링크는 http://research.microsoft.com/en-us/projects/pex/downloads.aspx 입니다.

이번 글은 개요이니까, PEX Tutorial에 나오는 간단한 샘플만 잠시 보도록 하겠습니다.

   1:  [PexMethod]
   2:  public void ParameterizedTest(int i)
   3:  {
   4:       if (i == 123)
   5:           throw new ArgumentException("i");
   6:  }

Integer 타입의 매개 변수를 받는 간단한 메소드입니다. 매개 변수가 123일 때에는 ArgumentException을 일으키는 딱 두 줄의 구현만 있을 뿐입니다. PexMethod Attribute는 이 메소드가 PEX Test method라는 것을 의미합니다. 이 메소드에 대고 마우스 오른쪽 클릭을 하게 되면 컨텍스트 메뉴에 다음과 같이 PEX 관련 메뉴들이 보이게 됩니다.

여기서 Run Pex Explorations를 선택하게 되면, PEX가 자동으로 코드를 분석해서 가능한 모든 매개 변수를 대입해 본 다음 그 결과를 바탕으로 아래처럼 결과를 보여주게 됩니다.

이 부분 – Run Pex Exploration 실행 - 에서 저는 예상치 못했던 에러를 만났습니다.

[critical] unexpected failure during exploration
System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Z3, Version=2.0.30325.1, Culture=neutral, PublicKeyToken=9c8d792caae602a2' or one of its dependencies.


위와 같은 에러였는데, 이 에러는 Visual C++을 설치하지 않았을 때에 발생하는 것으로 보입니다. 아직 PEX 설치 파일이 어떤 조건에서도 완벽하게 모든 필요한 파일들을 설치하지 못하는 것 같습니다. 이 에러는 Visual C++ 2008 SP1 Redistributable Package를 다운로드해서 설치하는 것으로 해결할 수 있습니다. 이 정보는 http://social.msdn.microsoft.com/Forums/en-US/pex/thread/5862d522-0c2e-481c-b537-864e7427a7e5 에서 얻었습니다. 혹시 Visual C++ 가 설치되지 않은 분들은 참고하시기 바랍니다.

예상대로 123이라는 매개변수가 입력되었을 때에 ArgumentException이 발생한 것을 볼 수가 있습니다. 그리고 여기서 또 다시 마우스 오른쪽 컨텍스트 메뉴를 통해서 Go To를 선택하게 되면 실제 자동으로 생성된 테스트 코드를 아래 그림처럼 볼 수가 있습니다.

   1:  [TestMethod]
   2:  [PexGeneratedBy(typeof(HelloWorldTest))]
   3:  public void ParameterizedTest01()
   4:  {
   5:      this.ParameterizedTest(0);
   6:  }
   7:   
   8:  [TestMethod]
   9:  [PexGeneratedBy(typeof(HelloWorldTest))]
  10:  [PexRaisedException(typeof(ArgumentException))]
  11:  public void ParameterizedTest02()
  12:  {
  13:       this.ParameterizedTest(123);
  14:  }

간단한 샘플이긴 하지만, PEX의 강력한 자동 테스트 코드 생성 기능을 볼 수 있으셨을 거라고 생각합니다. 다음 포스팅에서는 PEX에 대해서 더 깊이 들어가 보겠습니다. 아 물론, Code Analysis에 대한 글들도 계속 올릴 예정입니다. 읽어주셔서 감사합니다.

지난 번 포스팅에서 말씀 드렸던 것처럼 Visual Studio Team System 2010에서 이루어진 Code Analysis 기능 개선에 대해서 더 깊게 다뤄 보겠습니다. 그 첫 번째로 새롭게 추가된 Rule Sets 개념에 대해서 알아보도록 하겠습니다.


Visual Studio 2005, 2008에서의 코드 분석 설정

Visual Studio의 코드 분석 시스템에는 약 200개 정도의 규칙이 있습니다. 하지만, 사실 이 규칙들을 모두 준수를 해야 하는 것은 아닙니다. 모든 규칙이 나름의 이유와 정당성을 갖고 있다고 해도, 프로젝트의 성격에 따라, 모듈의 성격에 따라서 꼭 지켜야 할 규칙, 그렇지 않은 규칙, 심지어는 어쩔 수 없이 위반해야 하는 규칙도 있을 수 있습니다.

그래서 코드 리뷰를 할 때, 대부분의 경우 모든 규칙을 다 검사하지는 않습니다. 각각 케이스 바이 케이스로 규칙을 적절하게 조절하게 됩니다.

Visual Studio Team System 2005와 2008 버전에서는, 이런 설정을 Visual Studio Project Configuration에서 각 프로젝트 별로 할 수가 있습니다.

이 규칙 설정은 프로젝트 파일(.vbproj 혹은 .csproj)에 CodeAnalysisRules라는 Property 이름으로 아래와 같이 저장되게 됩니다. 내용을 보면 아시겠지만, “-“ 기호와 규칙 ID를 붙여 놓은 모양으로 되어있습니다. 즉, 거기에 열거된 규칙 ID를 Analysis Rules에서 빼는 형태로 저장이 되는 것입니다. 아래 샘플은 그래서 이 프로젝트는 코드 리뷰를 할 때에 Design Rule의 CA1000번 규칙을 검사하지 않는다라는 의미가 됩니다.

<CodeAnalysisRules>-Microsoft.Design#CA1000</CodeAnalysisRules>

이런 형태로 Visual Studio 프로젝트마다 다른 규칙을 적용할 수 있다는 것은 대단히 유연한 디자인이긴 하지만, 많은 수의 Visual Studio Project가 존재한다면, 관리가 참으로 어렵습니다. 그래서 예전에 Visual Studio Team System 2005 를 사용했던 프로젝트에서 전체 Visual Studio 프로젝트의 분석 규칙들을 통일하기 위해서, 개별 개발자들에게 위임하지 않고 제가 직접 모든 프로젝트를 텍스트 에디터로 열어서 저 부분만 Copy & Paste로 넣어서 Check-In하는 엄청난 단순 반복 작업을 한 적도 있습니다.

 

Visual Studio Team System 2010의 Rule Sets Feature

그래서 새롭게 출시될 Visual Studio Team System 2010에서는 Rule Sets라는 개념이 도입되었습니다. 이 Rule Sets 기능은 이름에서도 알 수 있듯이 Rule들을 미리 정해진 Set으로 관리할 수 있는 기능입니다. 이제 Visual Studio 프로젝트 별로 Rule을 하나 하나 빼는 수고를 할 필요가 없이 Visual Studio 프로젝트에 Rule Set을 지정하는 것으로 Code analysis를 커스터마이징할 수 있게 된 것입니다. 아래 그림에서 볼 수 있듯이, 하나 이상의 Rule Set을 선택하는 것도 가능합니다. (가장 아래의 Choose Multiple Rule sets를 선택하면 됩니다.)


Visual Studio Solution 전체에 Rule Set을 적용하는 것도 가능합니다. Solution Property에서 아래와 같이 설정할 수 있습니다.

 

위 그림에서 보시는 것처럼 마이크로소프트는 기본적으로 7개의 기본 Rule Set을 제공합니다. 이 기본 Rule Set의 목록은 다음과 같습니다.

  • Microsoft All Rules – 전체 Rule이 모두 포함된 Rule Set입니다.
  • Microsoft Basic Correctness Rules – 로직 에러와 자주 저지르는 실수를 예방하는 규칙들로 이루어진 Rule Set입니다.
  • Microsoft Basic Design Guideline Rules – Framework API 작성 상의 Best Practice에 집중된 Rule Set입니다.
  • Microsoft Extended Correctness Rules – Basic Correctness Rules를 확장하여, COM Interop이나 Mobile Application에도 사용 가능하도록 만들어진 Rule Set입니다.
  • Microsoft Extended Design Guideline Rules – Basic Design Guideline Rules를 확장해서, 사용성이나 유지 보수성도 체크할 수 있도록 만들어진 Rule Set입니다.
  • Microsoft Globalization Rules – Application의 Globalization에 있어서 문제가 있는지 검증하는데 집중된 Rule Set입니다.
  • Microsoft Minimum Recommended Rules - MS가 제안하는 최소한의 Rule Set입니다. 50개 정도의 규칙으로 이루어져 있습니다. 다른 대부분의 Rule Set들이 이 Rule Set을 포함하고 있습니다.
  • Microsoft Security Rules – 이름 그대로 보안에 집중된 Rule Set으로, 모든 Security 관련 규칙들이 모두 포함되어 있습니다.

 

물론 이 외에도 사용자가 직접 Rule Set을 편집할 수 있습니다. Rule Set은 .ruleset이라는 확장자를 가지는 XML 파일 포맷으로 되어 있습니다. 기본적으로 Visual Studio 2010에서 아래와 같은 UI를 통해서 편집할 수 있도록 되어 있습니다.


 

아래는 Rule Set 파일을 직접 Notepad로 열어본 것입니다.

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="Microsoft Basic Correctness Rules" Description="These rules focus on logic errors and common mistakes made in the usage of framework APIs. Include this rule set to expand on the list of warnings reported by the minimum recommended rules." ToolsVersion="10.0">
  <Localization ResourceAssembly="Microsoft.VisualStudio.CodeAnalysis.RuleSets.Strings.dll" ResourceBaseName="Microsoft.VisualStudio.CodeAnalysis.RuleSets.Strings.Localized">
    <Name Resource="BasicCorrectnessRules_Name" />
    <Description Resource="BasicCorrectnessRules_Description" />
  </Localization>
  <Include Path="minimumrecommendedrules.ruleset" Action="Default" />
  <Rules AnalyzerId="Microsoft.Analyzers.ManagedCodeAnalysis" RuleNamespace="Microsoft.Rules.Managed">
    <Rule Id="CA1008" Action="Warn" />
    <Rule Id="CA1013" Action="Warn" />
    <Rule Id="CA1303" Action="Warn" />
    <Rule Id="CA1308" Action="Warn" />
    <Rule Id="CA1806" Action="Warn" />
    <Rule Id="CA1816" Action="Warn" />
    <Rule Id="CA1819" Action="Warn" />
    <Rule Id="CA1820" Action="Warn" />
    <Rule Id="CA1903" Action="Warn" />
    <Rule Id="CA2004" Action="Warn" />
    <Rule Id="CA2006" Action="Warn" />
  </Rules>
</RuleSet>

 

Team Foundation Server Check-In Policy

이 Rule Set 기능은 Team Foundation Server의 Check-In Policy에도 쓰이게 됩니다.

 

맺으며..

이번 Rule Set Feature를 통해서 확실히 이전 버전보다는 Code Analysis를 사용하는 것이 쉬워지고 편리해진 것 같습니다. 하지만, Code Analysis에서 중요한 것은 편의성보다는, Rule의 문제라고 생각됩니다. 그런 면에서 아직 FxCop이 처음 나왔을 때의 200개 정도의 Rule에서 많은 추가가 없다는 것은 굉장히 아쉽습니다. 특히 직접적인 경쟁 제품이라고 볼 수 있는 Compuware의 DevPartner Code Review가 처음 버전부터 600개 이상의 Rule을 가지고 있다는 점에 비교해 본다면 더욱 그렇습니다.

이어지는 포스팅에서는 새롭게 Code Analysis에 추가된 Phoenix 엔진과 그에 따라 다시 복귀한 Data Flow 관련 규칙들에 대해서 한 번 알아보겠습니다.

Visual Studio Team System 2005 에서 코드 분석(Static Code Analysis) 기능이 처음 소개된 바가 있습니다. 이 코드 분석은 Microsoft에서 제안하는 닷넷 프레임워크에서의 디자인 가이드라인과 성능이나 보안, 신뢰성 등의 요소에 대한 Best Practice 등으로 이루어진 200개 이상의 Rule을 기반으로 Code를 검사하고 결함을 발견해 줍니다.

 

원래 이 Code Analysis는 FxCop이란 이름의 독립된 툴로써 세상에 먼저 선을 보인 바 있습니다.

이 FxCop이 Visual Studio 2005 Team System에서 통합되면서 현재의 코드 분석 기능이 나오게 된 것입니다. 실제로 비주얼 스튜디오에서 코드 분석 기능을 담당하는 실행 파일의 이름은 아직도 FxCopCmd.exe입니다.

앞으로 나오게 될 Visual Studio Team System 2010에서는 현재까지 알려진 바로는 다음 세 가지 부분에서 코드 분석의 기능 향상이 이루어 졌습니다. (출처: http://blogs.msdn.com/fxcop/archive/2008/10/30/new-code-analysis-features-in-visual-studio-2010-september-08-ctp.aspx)

  1. Rule Sets – 드디어, 규칙을 프로젝트 별로 하나 하나 빼던 수고스러움을 덜 수 있게 된 것 같습니다. DevPartner Code Review와 같은 상용 툴에서는 진작에 제공되던 기능이었지만, 이제 드디어 Visual Studio 2010에서는 Rule들을 Set으로 만들고 그 Rule Set 기반으로 코드 리뷰를 할 수 있게 되었습니다.
  2. Check-In Policy – 당연한 말이겠지만, 바로 위에서 소개한 Rule Sets 기능이 Team Foundation Server의 Check-In 정책에도 적용할 수 있게 됩니다.
  3. 8개의 새로운 Data-Flow 규칙MSDN Code Gallery의 VS2005와 VS2008 코드 분석 비교 문서를 보시면 아시겠지만, VS2008에서 7개의 규칙이 빠진 바 있습니다. Data-Flow Analysis Engine의 각종 버그와 낮은 성능으로 말미암은 결과라고 하는데, 이번 Visual Studio Team System 2010에서는 Phoenix라는 새로운 분석 엔진의 탑재와 함께 다시 7개의 규칙들이 복귀했고, 새롭게 추가된 하나를 합쳐서 총 8개의 새로운 규칙이 추가되었습니다. 그리고 이번에 추가된 Phoenix 분석 엔진은 당연히 기존 엔진이 가지고 있었던 버그나 성능 문제를 해결한 새롭고 강력한 엔진입니다.

그러면 다음 포스팅을 통해서 이 세 가지 개선점들에 대해서 더 자세히 다뤄보도록 하겠습니다.

안녕하세요. 이번에 Visual Studio Team System 2010 공식 블로그에 새롭게 참여하게 된 LazyDeveloper.Net의 kkongchi라고 합니다. Better Code 시리즈를 통해서 Code Analysis, Unit Test 등에 대한 포스팅을 해보도록 하겠습니다. 부족한 부분 많이 지적해 주시길 바랍니다.

 

TDD?

eXtreme Programming의 창시자 중 하나인 Kent Beck의 eXtreme Programming explained라는 책을 보면 Test를 작성하는 방법에 대해서 이렇게 기술하고 있습니다.

  • If the interface for a method is at all unclear, you write a test before you write the method. (메서드의 인터페이스가 클리어하지 않다면, 메서드를 작성하기 전에 테스트를 먼저 작성해라)

  • If the interface is clear, but you imagine that the implementation will be the least bit complicated, you write a test before you write the method. (메서드의 인터페이스가 클리어하더라도 당신이 생각하기에 구현이 조금 복잡할 것 같다면, 메서드를 작성하기 전에 먼저 테스트를 작성해라)

  • 이런 eXtreme Programming의 Test-Before-Writing 전략을 개발 프로세스에 전면적으로 도입하는 것을 Test Driven Development, 즉 TDD라고 합니다. TDD에 관한 위키피디아 페이지에서 소개하는 TDD의 개발 사이클은 다음과 같습니다. “Red, Green, Refactor”라고 표현하기도 합니다.

    다들 아시다시피, Visual Studio에서는 2005 버전에서부터 Team System의 일부로써 Testing Framework을 제공하고 지원해왔습니다. 그리고 드디어 이번 Visual Studio Team System 2010에서는 완벽하게 TDD의 개념이 Visual Studio Team System안으로 녹아 들어가게 된 것 같습니다. 바로 새롭게 추가된 기능 “Generate” 기능을 통해서, Test를 먼저 작성한 후에 그 Test로부터 코드를 자동으로 Generate해주는 기능이 추가된 것입니다.

     

    TDD Development in VSTS 2010 by “Generate”

    지난 11월에 나온 Visual Studio 2010 and .NET Framework 4.0 Training Kit의 Lab을 통해서 이 기능에 대해서 좀 더 자세히 알아보도록 하겠습니다.

     

    당연히 먼저 테스트를 작성하는 것부터 시작합니다. 하지만, 아직 만들어지지 않은 클래스이기 때문에 아래 그림처럼 빨간색 물결 라인으로 경고가 뜹니다. 여기서 마우스 오른쪽 버튼을 눌러보면, 새로운 “Generate” 기능을 볼 수가 있습니다.

    Generate class를 선택하면 같은 프로젝트에 Class가 추가됩니다. 하지만 Generate other..를 선택하면 아래와 같은 팝업 윈도우가 나옵니다. 클래스를 만들 수 있는 Wizard 개념이라고 보시면 되겠습니다.

    이 Wizard를 통해서 클래스의 Access 한정자, Type, 그리고 파일을 만들 프로젝트까지 설정을 할 수가 있습니다. 이 과정을 통해서 우리는 완벽하게 Test로부터 시작해서 뼈대 코드를 만들어 낼 수가 있습니다. 아래 그림처럼 말이죠..

    이제 이 자동으로 만들어진 뼈대 코드에 구현을 추가하게 되면 여러분들은 다음과 같이 Test를 통과했다는 기분 좋은 화면을 보실 수 있으실 것입니다.


    위에서 보신 Demo Code의 시연은 http://channel9.msdn.com/shows/10-4/10-4-Episode-5-Code-Focused-in-Visual-Studio-2010/#Page=4 에서 Video로도 감상하실 수 있고, http://www.microsoft.com/downloads/details.aspx?FamilyID=752CB725-969B-4732-A383-ED5740F02E93&displaylang=en 에서 Lab Document와 소스 코드도 얻으실 수 있습니다.
     

    지금까지 보신 것처럼 앞으로 출시될 VSTS 2010에서는 IDE 자체에서 완벽한 TDD 지원 기능이 통합되었습니다. TDD가 만능의 도구는 아닙니다. 하지만, 적어도 개발자가 자신의 코드에 대한 이해도가 통상적인 개발 방법보다는 훨씬 크고 깊을 것이라 기대합니다. 어설픈 문서보다는 잘 만들어진 테스트 코드들이 오히려 실제 구현 코드를 이해하는 데 더 도움이 되는 경우도 많습니다. Visual Studio Team System 2010은 효율적인 Test Driven Development를 가능하게 해주는 최고의 도구가 될 것 같습니다.

    부족한 글 읽어주셔서 감사하고, 많은 의견 부탁 드립니다.