부하테스트 이야기, 테스트 데이터 분석 문제 풀어보세요.

부하테스트 이야기

부하 테스트는 테스트 분류 상 '비기능 테스트'에 속하는 매우 정교한 테스트 중의 하나다. 부하 테스트는 수치화된 데이터를 통해 성능 지표를 도출한다. 대부분 부하 테스트는 클라이언트 응용 프로그램보다 서버 응용 프로그램에 주로 사용한다. 웹 서버나 통신과 관련된 서버, 그리고 데이터베이스가 대표적이다.

일반적으로 테스트라고 하면 '성공/실패'가 매우 명확하다. 그리고 '성공/실패'라는 결과에 대해 객관적으로 판단할 수 있고, 특별한 경우가 아니고서 '성공/실패'를 재연할 수 있는 시나리오를 가지고 있다.

반면 부하 테스트는 '성공/실패'는 경험적으로 판단해야 하며, 성공인지 실패인지에 대해 다른 사람과 의견이 일치하지 않는 경우가 대부분이다. 그래서 경험적으로 성공과 실패의 기준점을 정하곤 한다. 하지만 매번 성공/실패가 같은 결과를 내지 않으며, 환경적인 요건에 따라 얼마든지 결과가 뒤바뀔 수 있다. 실패한 테스트를 다시 수행 했을 때, 재연할 수도, 못할 수도 있는 있다. 결과적으로 테스트 대상의 환경적인 요건과 더불어 누가, 어떻게 테스트를 수행하였는지도 테스트 결과에 반영이 될 수 있다.

필자는 4년이 넘도록 현장에서 수많은 부하 테스트를 수행해왔다. 매우 재미있는 것은 어떤 서버 응용 프로그램도 성능 요건을 통과한 적이 단 한번도 없었다. 수 년 동안 문제 없이 잘 써왔다는 서버 응용 프로그램도 부하테스트를 통해 문제를 발견하고 더 나은 성능을 낼 수 있도록 개선된 사례들도 매우 많다.

숨겨진 많은 버그나 이슈들이 부하 테스트를 통해 여실히 드러난 것이다. 그로 인해 이전에 다니던 N모 게임사의 인프라는 부하테 스트로 성능 요건을 반드시 통과해야 라이브로 서비스할 수 있는 엄격한 규칙도 생겼다. 물론, 이 때에는 필자가 전담하여 테스트를 수행했었을 때였다.

부하 테스트라는 주제 하나 만으로도 책 한 권 정도의 분량이 넘을 것 같다. 그 만큼 현장에서 부하 테스트에 대한 오해도 많았으며, 개발자와 실무진 간의 성공/실패에 대한 이해관계, 테스트 데이터 분석, 또 이를 보고서화 및 시각화 하는 과정의 자동화 등 많은 재미있는 경험이다.

왜 부하 테스트가 중요할까? 그 이유는 아무것도 눈에 보이지 않기 때문이다. 문제가 있어도 금전적/물질적으로 어떠한 손해를 입었는지 조차 알 수 없다. 테스트를 통해 문제를 발견하지 않는 이상 아무런 문제가 되지 않는다. 그러므로 '비기능 테스트'인 부하 테스트 자체의 필요성 조차 느끼지 못할 것이라 생각한다. 하지만 전문적인 '비기능 테스트' 활동을 시작함과 동시에 많은 문제들을 발견할 수 있을 것이다.

재미로 풀어보는 부하테스트 분석 문제

부하 테스트는 테스트 활동 자체에 큰 의미를 부여할 수 있지만, 부하 테스트 데이터를 분석하는 것도 테스트를 수행하는 것 만큼이나 중요하다. 아니, 이 분석 과정이 더 중요한 경우도 많았다.

이 데이터들은 테스트 툴이 보여주는 성능 지표 뿐만 아니라, 디스크 IO와 네트워크 대역폭과 같은 하드웨어적인 측면과 쓰레드(Thread), 프로세스(Process) 등과 같은 운영체제와 소프트웨어적인 측면 모든 것을 분석해야 한다. 놓칠 수 있는 많은 데이터들이 문제나 이슈의 원인과 직결되는 경우도 있기 때문이다.

가령, 데이터베이스 서버의 병목의 원인을 규명하고자 할 때 대부분 많은 트랜잭션과 락(Lock)이 걸리는 이유일 것이다. 하지만 간혹 디스크 IO가 권장하는 임계치를 벗어난다면 병목의 원인을 구진 디스크로 밝혀질 수도 있기 때문이다.

필자가 재미있는 문제 하나 준비했다!

아래의 그림은 .NET WCF(Windows Communication Foundation)의 부하 테스트 결과이다. 딱 보고 '무엇이 문제인지' 원인을 안다면 당신은 충분히 멋진 개발자이다. 하지만 뚫어져라 쳐다봐도 문제점이 보이지 않는다면 기본기가 부족한 개발자인 스스로를 자책하기 바란다.

이 테스트 결과의 분석 결과는 무엇이 문제인지는 다음 아티클을 기대하기 바란다.

  • Smoke 테스트 결과

  • Stress 테스트 결과

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. shunman 2013.04.03 13:29 Address Modify/Delete Reply

    결과가 어떻게 나오는지 궁금하네요. 어서 다음 아티클 부탁드립니다 ㅋ

메뉴얼 테스트 vs 테스트 자동화 (1)

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

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

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

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

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

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

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

실제로 소프트웨어 세계 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) 에 대한 내용은 잠시 보류하고, 매뉴얼 테스트를 다루어 본 이후에 다시 원점에서 다시 논의해보도록 하겠습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

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

최근 여러 달 동안 블로그를 관리하지 않아 이렇게 다시 글을 올리는 것이 약간은 부담이 되네요. 거의 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장도 읽어 보지 않은 사람들이 대부분이라는 것도 테스트를 수행하는데 큰 걸림돌입니다.
  • 종합해보면 테스트라는 일련의 단계에 대한 최소한의 이해가 부족하고, 스스로 부족한 것을 알고 받아들일 줄 아는 이해심도 부족합니다.

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

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

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

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. asd 2011.10.24 11:05 Address Modify/Delete Reply

    asdasdasd

  2. demum 2011.10.24 12:42 Address Modify/Delete Reply

    오랜만에 좋은글 잘 봤습니다.

  3. 김용규 2011.12.21 10:38 Address Modify/Delete Reply

    품질 보증의 중요성은 개발만큼 중요하다고 생각합니다.

    고객들은 그 제품의 코드가 얼마나 잘 짜여있다는 것을 보는것이 아니라

    완성된 제품을 보고 평가를 하는 것이니깐요..

    좋은글 정말 잘 읽었습니다^_^

TDD vs 계약기반 테스트

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

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

  • 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 를 할 수 있다고 생각을 하며 이만^^

Posted by 땡초 POWERUMC

댓글을 달아 주세요

테스트 가상화...

몇 해 전부터 클라우드(Cloud) 붐이 일어나면서 굉장히 다양한 클라우드 인프라와 서비스가 여러 벤더에 의해 발전해 왔습니다. 그 중 Microsoft 는 가상화 기술을 기반으로 플랫폼, 인프라 서비스 등이 결합하여 Azure 라는 훌륭한 클라우드 서비스 환경을 구축하였습니다. 이런 클라우드 서비스의 가능성은 가장 최하위 기반이 되는 가상화 기술이 바로 그것입니다.

필자는 처음에는 클라우드라는 것이 도대체 GREEN IT 를 마케팅 용어로 벗삼고, TOC 절감과 관리적인 요소들에 그저 불편한 심기를 내비쳤습니다. 왜냐하면 늘 그래왔듯이 거품이 빠지고, 걸음마 수준의 기술과 마케팅으로 수 많은 것들이 기억 속에서 사라진 것들이 더 많기 때문입니다.

다시 본론으로 돌아와서, 테스트 가상화란…? 가상화 기술은 여러 가지 기술이나 트랜드와 접목시킬 수 있습니다. 그 중 하나가 바로 테스트 가상화 기술입니다. 현대의 소프트웨어는 다양한 방면에서 애자일(Agility) 하길 원합니다. 개발 팀은 당연하고 소프트웨어를 사용하는 사용자도 매우 능동적이며 한층 눈높이가 높아졌습니다. 즉, 기존의 개발 방식이 변하듯이 기존의 테스트 방식도 이제 진화해야 할 시기입니다. 그리고 이것을 가능하게 해 주는 것이 바로 테스트 가상화 입니다.

------------------------------------- 절취선 ^^ ------------------------------------

서두는 이쯤 마무리 하고(^^), 아래의 자료는 Microsoft 고객사를 대상으로 하는 Visual Studio Ultimate 맴버쉽 세미나에서 발표할 예정이었던 프레젠테이션 자료입니다. 2010년 12월 22일 예정이었던 세미나를 위해 급하게 만들었던 프레젠테이션인데 일정이 변경되면서 먼저 공유해 드리겠습니다. (나중에 더 알차게 만들어 드리겠습니다 ^___^;)

그림만 있어서 내용은 이해하는데 충분히 설명을 드릴 수 없습니다만, 다음 기회에 더 좋은 내용으로 정보를 공유하도록 하겠습니다.

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. dotnetpower 2010.12.22 09:13 Address Modify/Delete Reply

    좋은 자료 잘 보았습니다. 22일이면 오늘이군요 세미나 무사히 잘 하시기 바랍니다. 좋은 하루 되세요 :)

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 님께 감사합니다.


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% 라도 테스트가 완전히 완료된 것은 아니라는 것입니다. 차후에 테스트 패턴에 대해서 알아보면서 다룰 예정입니다. 

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

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 지송 2010.08.06 15:47 Address Modify/Delete Reply

    잘보고 갑니다. float 연산관련해서는 글보고 처음 알았네요.

    다음에 또 들리겠습니다. 더운 여름 잘 보내세요.

테스터에 대한 오해와 진실

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

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

  • 업무 도메인의 이해
  • 테스트 도구 사용
  • 전반적인 테스트 시스템 인프라 와 운영체제(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 은 이미 테스팅 분야에 혁신을 진행하고 있고, 우리나라에서 소외되는 테스팅 분야에서 많은 할 일이 남아 있을 것 같아요. 작은 경험이나마 공유하고 도움이 되는 실전 테스팅 기법에 대해서 차근 차근 공부하면서 여러분들에게 알려드릴 계획입니다. 그리고 함께 생각을 정리하는 시간이 되길 바랍니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. dekorasyon 2012.04.19 22:11 Address Modify/Delete Reply

    아주 좋아요. 감사

  2. boya badana 2012.06.30 02:24 Address Modify/Delete Reply

    아주 좋아요. 감사

  3. 감사합니다 2019.01.31 15:23 Address Modify/Delete Reply

    본문 내용중에
    일부 애자일 프로세스가 권장하는 방법을 버리고, 개선/조합하니 왠걸???
    이런 내용이 있는데 개선 / 조합을 통해 어떤 프로세스가 탄생했는지 궁금합니다^^

이전 글
[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) 를 주는 것은 매우 환영할 일이지만, 일부 정책적인 강제가 없다면 애자일은 우리나라에서 이미 실패한 방법론 또는 프로세스일 뿐입니다. 왜냐하면 우리나라의 고객은 아직까지는 변하지 않을 테니까요.

   

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

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. resisa 2010.02.05 18:00 Address Modify/Delete Reply

    스크롤의 압박이 느껴지는 포스트네요~ ^^;

  2. 박중석 2010.02.08 10:54 Address Modify/Delete Reply

    핵심개발자와 일반개발자의 구분이 공감이 갑니다. 항상 좋은 포스팅 감사!

  3. 귀뫄뉘 2010.02.12 13:17 Address Modify/Delete Reply

    좋은 글 잘 읽었습니다. 특히 애자일과 팀구성에 관한 이야기에 완전 공감이 가네요 ^^

애자일(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]

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. tack 2010.02.04 10:12 Address Modify/Delete Reply

    잘 읽었습니다. 어제 TDD 책을 구입했는데 오늘 이런 글을 읽게 되네요 ^^
    예전엔 뭔소린지 모르고 대충 읽고 팔았다가 요즘 수개월 전의 버그들을 접하며 다시 구입했는데 당장은 책 내용대로 수련? 을 해야겠습니다

  2. @_@ 2010.02.04 10:14 Address Modify/Delete Reply

    단위테스트의 중요성과 효용성(?)은 여러가지 매체를 통해 접하고 있긴 하지만 '지금은 아닌거 같아!' 라는 생각들이 많아서 실전에 활용하고 있지 못합니다. 다음 이야기가 기다려집니다.

  3. dotnetpower 2010.02.04 16:31 Address Modify/Delete Reply

    좋은 글 잘 읽었습니다.
    저도 TDD에 대한 고민이 많고, VS 에도 TDD 가 추가되는 이슈가 있는데 국내 실정을 미뤄 봤을때 막연하게 좋지만은 않다고 생각을 했었거든요...
    엄준일MVP님의 글이 많은 도움이 되었습니다. 감사합니다. :)

  4. 구경꾼 2014.09.11 19:16 Address Modify/Delete Reply

    간만에 자바 설치하다가 junit 설치를 묻길래 뭔가하고 찾아보는데. 설명들이 이해가 안되네요... 실용적인 용도는 그냥 버그테스트 인가요..?

  5. dotnetchobo 2019.06.27 14:16 Address Modify/Delete Reply

    매뉴얼 테스트(Manual Test)가 정확히 뭔지는 찾아봐도 잘 나오진 않았지만.. 기능을 일일히 하나씩 테스트 하는거라고 보면 되나요 ? 그것을 작성하는거 같은데...

    워낙 제가 초보자다 보니 테스트팀이 왜 있어야하는지도 솔직히 의문이 들긴하지만.. 정확히 하는 업무가 파악이 잘 되지가 않네요...
    보통 개발자선에서 어느정도 유닛테스트부터 통합테스트까지 작성을 얼추 맞춰놓기때문에 테스터의 역할이 중요한가 싶기도해요...

목차

[Testing] TDD (Test-Driven Development)-테스트 주도 개발

[Testing] BDD (Behavior-Driven Development)–행위 주도 개발

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

 



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/

Posted by 땡초 POWERUMC

댓글을 달아 주세요

목차

[Testing] TDD (Test-Driven Development)-테스트 주도 개발

[Testing] BDD (Behavior-Driven Development)–행위 주도 개발

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



그렇다면 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 를 통해 인터페이스만으로 테스트나 코드를 통해 설계 작업을 진행할 수 있게 되는 것입니다.

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

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 까꿍 2010.04.18 16:47 Address Modify/Delete Reply

    서비스를 기획하는 초기 단계에 고객 또는 사용자에게 서비스 필요성을 납득 시킬 필요가 있을 경우에도 BDD 적용하여 진행하면 되는건가요?

    • 땡초 POWERUMC 2010.04.19 10:00 신고 Address Modify/Delete

      훔... 어려운 질문이네요.
      개인적으로는 BDD 를 구현과 아키텍처링의 일부로 보고 있습니다.
      물론 Express Blend 분야에서 BDD 와 같은 역할을 하는게
      스케치플로가 아닐까란 생각이 드네요.

 

목차

[Testing] TDD (Test-Driven Development)-테스트 주도 개발

[Testing] BDD (Behavior-Driven Development)–행위 주도 개발

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

이번에 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)

Posted by 땡초 POWERUMC

댓글을 달아 주세요