Search

'Application Lifecycle Management'에 해당되는 글 6건

2011.01.10 2011년 .NET 개발자의 생존전략 1
2011.01.04 [ALM-Test] 7. TDD vs 계약기반 테스트
2010.08.04 [ALM-Test] 4. 테스터(SDET) 의 역할
2010.08.03 [ALM-Test] 3. 테스터에 대한 오해와 진실 1
2010.04.07 Visual Studio 2010을 활용한 ALM (1-5) - ALM 이란 무엇인가
2010.03.15 [세미나] 차세대 응용 프로그램 구축 방법 및 사례 소개 세미나

2011년 .NET 개발자의 생존전략

VSTS 2010 팀 블로그 2011. 1. 10. 08:30 Posted by POWERUMC

최근 2년 동안 다양한 개발 분야의 기술들이 물망에 오르는 굉장히 뜻 깊은 해였습니다. 2년 전이면 Microsoft 강성재 차장과 함께 처음으로 "Visual Studio 한국 공식 팀"을 창설하면서 http://vsts2010.net 이 탄생한 시기이군요. 2008년 12월에 팀이 창설되고, 2009년 1월 5일이 팀 블로그 2주년이 되는 날이었군요.

바로 저희 "Visual Studio 한국 공식 팀" 블로그에서 한홀 한홀 정성스럽게 작성된 포스트들이 2년 여간의 기술 흐름을 대변해 주고 있으며, 그리고 2011년의 기술도 짐작해 볼 수 있는 짧지만 굵은 변화의 흐름과 함께 여기까지 온 것 같습니다.

우리 팀이 함께 해왔던 핵심 키워드의 태그는 무엇이었을까요?

Visual Studio 2010
.NET 4.0, .NET Framework 4.0
ASP.NET MVC
C# 4.0
C++0x, C++/CLI
Parallel Computing
WCF
Cloud
Application Lifecycle Management

그리고 위의 태그들에 대해 더 자세히 살펴보더라도 생소한 기술과 이름, 아키텍처, 환경 등이 2년 동안 격변을 일으키며 변화를 해왔다는 사실입니다.

2011년 이전까지는 여러분들에게 선택권이었던 것들이, 이제는 필수가 되어야 한다고 해도 과언이 아닐 겁니다. 비즈니스 요구사항의 단면을 보면 업무적인 요인, 시대적인 배경 등인데, 이 시대적인 배경에는 트랜드+시장+기술+… 이 있을테고요. 그리고 '우리가 이 시대적인 배경 중 '기술'에 한 배를 타고 흐르고 있는가…?' 에 다시 한번 생각해 볼만 합니다.

예전 2010년 6월 1일 REMIX10 세미나에서 여러분에게 말씀 드린 마지막 문구가 다시금 생각이 나네요.

http://www.techdays.co.kr/2010spring/remix10/session3_1.html

여러분의 생존전력은 바로 아래에 해답이 있습니다. 여러분들에게 필요한 것, 그리고 그 가능성이 있다고 판단하시면 2011년 생존을 위하여 달려보는 것은 매우 멋진 2011년 한 해가 될 것입니다.

.NET 프레임워크

애자일 개발

Agile Development [Better Code]TDD의 개념이 완벽히 녹아 들어간 VSTS 2010
Agile Development [Better Code]Visual Studio 2010 Code Analysis Enhancements - 1.개요
Agile Development [Better Code]Visual Studio 2010 Code Analysis Enhancements - 2. Rule Sets Feature
Agile Development [Better Code]PEX, Automated Whitebox Testing for .NET - 1. 개요
Agile Development [Better Code]Visualize Code Relationships
Agile Development [Testing] TDD (Test-Driven Development-테스트 주도 개발)
Agile Development [Testing] BDD (Behavior-Driven Development?행위 주도 개발)
Agile Development [Testing] Moq.NET (T/B Driven Development)
Agile Development [Better Code]Visual Studio Code Analysis Enhancements - 3. Data Flow Rules and Phoenix Engine
Agile Development 애자일에 대한 고찰
Agile Development [ALM-Test] 1. 왜 단위 테스트를 해야 하는가?
Agile Development [ALM-Test] 2. 한국적인 애자일 모델의 필요성
Agile Development [협업 1] 협업 도구의 통일성과 협업 인프라 관리
Agile Development [ALM-Test] 3. 테스터에 대한 오해와 진실
Agile Development [ALM-Test] 4. 테스터(SDET) 의 역할
Agile Development [ALM-Test] 5. 테스트 계획
Agile Development [ALM-Test] 6. Load Runner vs Visual Studio 2010 테스팅 비교 분석 - http://willstory.tistory.com/4 제공
Agile Development [ALM-Test] 7. TDD vs 계약기반 테스트
Architect Development Architect Development ?
Architect Development 몽당연필과 함께하는 VSTS 2010 모델링 0/4
Architect Development 몽당연필과 함께 하는 VSTS 2010 모델링 1/4
Architect Development Windows Server AppFabric - Velocity 란?
Architect Development WCF=SOA 에 대한 고찰

ASP.NET 4.0

C# 4.0

C++/CLI

C++/CLI C++/CLI는 미운 오리새끼 or 백조
C++/CLI .NET에서의 C++/CLI의 의미
C++/CLI [Step 01] 'C++/CLI가 뭐야?'에 답하기 && 가장 많은 프로그래밍 언어로 만드는 프로그램 만들기
C++/CLI [Step 02-1] 클래스(class), 핸들(^), 그리고 구조체(struct)
C++/CLI [Step.02-2] 클래스(class), 핸들(^), 그리고 구조체(struct)
C++/CLI [step.03] 배열
C++/CLI [Step. 04] nullptr, interior_ptr, pin_ptr
C++/CLI [Step. 05] 관리 코드의 array를 비관리 코드에 포인터로 전달
C++/CLI [Step. 06-1] 관리코드의 문자열과 비관리코드의 문자열 변환
C++/CLI [Step. 06-2] 관리코드의 문자열과 비관리코드의 문자열 변환
C++/CLI [Step. 07] 비관리 클래스에서 관리 클래스를 멤버로, 관리 클래스에서 비관리 클래스를 멤버로
C++/CLI [Step. 08] 프로퍼티 ( property )
C++/CLI [Step. 09] 델리게이트 (delegate)
C++/CLI [Step. 10] 이벤트 ( event )
C++/CLI [Step. 11] 열거형( enum )
C++/CLI [Step. 12] for each
C++/CLI [Step. 13] parameter array
C++/CLI [Step. 15] static 생성자, initonly, literal
C++/CLI [Step. 14] 인터페이스 ( interface )
C++/CLI [Step. 16] array 클래스에 non-CLI 오브젝트 사용
C++/CLI [Step. 17] 델리게이트에 비관리 함수를 할당하기 그리고 다음 예고
C++/CLI [Step. 18] 순수 가상 함수
C++/CLI [Step. 19] char* -> 관리코드, 관리코드 -> char*
C++/CLI [Step. 20] 닷넷에서 HalfNetwork를 사용하자 - 1
C++/CLI [Step. 21] 닷넷에서 HalfNetwork를 사용하자 - 2
C++/CLI [Step. 22] 닷넷에서 HalfNetwork를 사용하자 ? 3
C++/CLI [Step. 23] 닷넷에서 HalfNetwork를 사용하자 ? 4
C++/CLI [Step. 24] 닷넷에서 HalfNetwork를 사용하자 ? 5
C++/CLI [Step. 25] 닷넷에서 HalfNetwork를 사용하자 ? 6(마지막)

C++0x

클라우드 컴퓨팅

게임 개발

F# Welcome to F#(1) - 첫만남.
F# Welcome to F#(2) - 두번째 만남.
F# Welcome to F#(3) - 사소한 탐색전.
F# Welcome to F#(4) - 과거와 배경을 좀 더 알고싶어.
F# Welcome to F#(5) - 아주 조금씩 심화되는 탐색전.
F# Welcome to F#(6) - 비교본능.
F# Welcome to F#(7) - 클리프 행어.
F# Welcome to F#(8) - 은총알과 엄친아.
F# Welcome to F#(9) - 메이져 데뷰.
F# Welcome to F#(10) - 인도음식 카레.....?
F# Welcome to F#(11) - 차별을 권장하는 언어인거임?!?!
F# Welcome to F#(12) - 공동작업 좋치아니항가

MFC

MFC [MFC] 리스타트 매니저(Restart Manager) - (1/3) : 기능 소개
MFC [MFC] 리스타트 매니저(Restart Manager) - (2/3) : 사용하기
MFC [MFC] 리스타트 매니저(Restart Manager) - (3/3) : 활용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - (1/3) : 기능 소개
MFC [MFC] 태스크 대화상자(Task Dialog) - (2/3) : 사용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - (3/3) : 활용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - 예제 코드 올립니다.
MFC [MFC/윈도우 7 멀티터치] #2 : 제스처(gesture)를 이용한 구현(上)
MFC [MFC/윈도우 7 멀티터치] #3 : 제스처(gesture)를 이용한 구현(下)
MFC [MFC/윈도우 7 멀티터치] #4 : WM_TOUCH 메세지를 이용한 구현(上)
MFC [MFC/윈도우 7 멀티터치] #5 : WM_TOUCH 메세지를 이용한 구현(下)
MFC [MFC/윈도우 7 멀티터치] #6 : 예제 코드 올립니다

RIA

RIA Expression Blend3 preview - 1.인터페이스
RIA Expression Blend3 preview - 2. Photoshop import
RIA Silverlight 3 & Blend 3 RC 공개!!!
RIA Silverlight 4 Beta 공개
RIA .Net Ria Service + IIS6 + Silverlight 4 Troubleshooting!!
RIA 실버라이트 비하인드 코드에서 바인딩하기.
RIA .Net Ria Service 와 Entities 그리고 Stored Procedure 하다가 생긴일..
RIA 실버라이트 프로그래머가 할 수 있는 최소한의 블랜드 디자이너를 위한 배려

SharePoint 2010

Team Foundation Server

Visual Studio 2010

우리 블로그 소식

WCF

WCF WCF란 무엇인가?
WCF 기본 WCF 프로그래밍 - 첫 WCF 서비스 만들기
WCF 기본 WCF 프로그래밍 - 첫 WCF 서비스 만들기 2
WCF WCF의 기본 - Service Contract
WCF WCF의 기본 - Data Contract
WCF WCF 서비스의 동시성(Concurrency) - 1
WCF WCF 서비스의 동시성(Concurrency) - 2
WCF WCF - Serialization
WCF WCF Hosting - WAS를 이용한 Hosting
WCF 도메인을 여러개 등록했을때 WCF 서비스를 호스팅 할수 없어요 ㅠㅠ
WCF WCF Hosting(2) - ASP.NET 호환성(Compatibility)
WCF WCF Hosting (3) - Windows Service를 이용한 Hosting
WCF WCF Security (1) - SSL을 이용한 전송계층에서의 보안 설정
WCF WCF Security (2) - 전송 계층에서의 메세지 인증 (사용자 지정 인증)
WCF WCF Troubleshooting (1)
WCF WCF Service Configuration Editor
WCF WCF Troubleshooting (2)

저작자표시 비영리 동일조건

'VSTS 2010 팀 블로그' 카테고리의 다른 글

[공지사항] VS Korea 공개 세미나 (0)	2011.05.24
[세미나] Visual Studio 공식 팀 - Your Smarter Visual Studio 2010 (1)	2011.03.25
[후기] C++ & 게임 개발자를 위한 개발 생산성 및 퍼포먼스 향상 전략 세미나 (3)	2010.11.10
[세미나 발표 자료] Visual Studio Seminar #1 (0)	2010.10.12
[세미나 후기] Visual Studio Seminar #1 (0)	2010.10.12

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

저작자표시 비영리 동일조건

'Agile Development' 카테고리의 다른 글

[ALM-Test] 9. 메뉴얼 테스트 vs 테스트 자동화 (1) (0)	2011.10.25
[ALM-Test] 8. 소프트웨어 테스트 후진국 "대한민국" (0)	2011.10.24
[ALM-Test] 6. Load Runner vs Visual Studio 2010 테스팅 비교 분석 - http://willstory.tistory.com/4 제공 (1)	2010.09.02
[ALM-Test] 5. 테스트 계획 (1)	2010.08.10
[ALM-Test] 4. 테스터(SDET) 의 역할 (0)	2010.08.04

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

저작자표시 비영리 동일조건

'Agile Development' 카테고리의 다른 글

[ALM-Test] 6. Load Runner vs Visual Studio 2010 테스팅 비교 분석 - http://willstory.tistory.com/4 제공 (1)	2010.09.02
[ALM-Test] 5. 테스트 계획 (1)	2010.08.10
[ALM-Test] 3. 테스터에 대한 오해와 진실 (1)	2010.08.03
[협업 1] 협업 도구의 통일성과 협업 인프라 관리 (0)	2010.07.07
[ALM-Test] 2. 한국적인 애자일 모델의 필요성 (0)	2010.06.25

[ALM-Test] 3. 테스터에 대한 오해와 진실

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

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

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

[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 는 어떤 자격 요건을 갖추어야 할까요?

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

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

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

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

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

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

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

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

저작자표시 비영리 동일조건

'Agile Development' 카테고리의 다른 글

[ALM-Test] 5. 테스트 계획 (1)	2010.08.10
[ALM-Test] 4. 테스터(SDET) 의 역할 (0)	2010.08.04
[협업 1] 협업 도구의 통일성과 협업 인프라 관리 (0)	2010.07.07
[ALM-Test] 2. 한국적인 애자일 모델의 필요성 (0)	2010.06.25
[ALM-Test] 1. 왜 단위 테스트를 해야 하는가? (1)	2010.06.24

Visual Studio 2010을 활용한 ALM (1-5) - ALM 이란 무엇인가

Team Foundation Server 2010. 4. 7. 08:30 Posted by POWERUMC

본 원고는 월간 마이크로소프트 2010년 3월호에 기고한 원문입니다.

Visual Studio 2010을 활용한 ALM(Application Lifecycle Management)

ALM 이란 무엇인가?
효율적인 프로젝트를 위한 애자일한 프로세스 – 프로세스 강요
명확한 작업의 관리와 지속적인 통합 – 추적성
과거와 현재를 알면 미래가 보인다 – 가시성
ALM 과 가상화의 만남 – Test and Lab Management

엄준일 : 닷넷엑스퍼트(.NETXPERT) 에 선임 컨설턴트로 재직 중이며, Microsoft Team System MVP 로 활동하고 있다. 많은 대기업 프로젝트와 컨설팅 경험을 바탕으로 좀 더 좋은 소프트웨어를 만들기 위한 기반을 만들며, .NET 은 우리의 미래 동반자임을 확신하고 꾸준히 새로운 기술을 전파하고 있다. (http://blog.powerumc.kr)

작성자: 엄준일 선임/ Microsoft MVP

감수자:안재우 수석/Microsoft MVP

ALM(Application Lifecycle Management) 의 개요

최근 몇 해 사이에 ALM(Application Lifecycle Management)라는 용어를 자주 듣게 되었고, ALM에 대해 논의를 하게 되고, ALM 을 해야 한다라는 말을 자주 듣게 됩니다. 최근 들어, 실제로 많은 기업이나 조직에서 ALM 도입을 검토하고 있고, 왜 ALM에 대해 열광하는지에 대해서도 궁금한 부분이 아닐 수 없습니다. 그렇다면 우리는 이제 ALM이 무엇이고, 왜 등장하였으며, ALM에 대한 오해와 진실에 대해서 충분히 이야기를 나눌 가치가 있다고 생각합니다.

ALM 이란?

ALM(Application Lifecycle Management, 이하 ALM)을 한글로 번역하면 "응용프로그램 수명주기 관리" 라고 합니다. 현대 사회는 문화, 언어, 가치관, 기술 등이 빠르게 발전하고 있습니다. 문명의 발전이 없다면 죽은 문명이고, 마찬가지로 소프트웨어가 변화하고 발전하지 않으면 죽은 소프트웨어나 마찬가지 입니다. ALM 을 쉽게 말하면 바로 이런 소프트웨어가 생산되고 릴리즈, 유지, 관리하기 위한 기술을 총칭합니다.

ALM 등장배경

예전부터 소프트웨어를 개발하는 방법이 꾸준히 연구되었으며, 그 중 가장 대표적인 방식이 SDLC(Software Development Lifecycle) 입니다.

SDLC 의 대표적인 개발 방법론 중에 폭포수 모델(Waterfall Model)이 있는데, 로이스(Royce) 라는 사람에 의해 정의된 폭포수 모델은 요구사항, 디자인, 구현, 통합, 테스트, 릴리즈, 유지보수라는 단계로 구분이 되며, 각 단계는 순차적으로 진행되게 됩니다. 요구 사항이 없으면, 디자인을 할 수 없고, 디자인을 하지 않으면 구현을 할 수 없는 형태의 개발 방법으로 현 단계에 문제나 오류가 발생하게 반드시 위험 요소를 제거한 후에 다음 단계로 이동하게 됩니다. 이러한 개발 방법은 각 단계별로 상하 연관성이 없고 명확하게 구분되어 있으며, 최근에도 이러한 개발 방법으로 많은 프로젝트가 진행됩니다.

그림 1 일반적인 폭포수(Waterfall) 모델

하지만 최근 이러한 Top-Down 방식의 수직적인 개발 방식에 많은 비판을 받고 있습니다. 초기 계획이 완벽하지 않으면 전체 일정 또는 계획이 완벽하지 않다는 의미이기 때문입니다. 고객도 자신의 정확한 요구 사항을 알지 못합니다. 이런 과정에서 프로토타입(Prototype) 을 고객에게 시연하고 고객의 정확한 요구 사항을 도출해야 합니다. 하지만 고객의 요구 사항은 언제나 변할 수 있습니다. 즉, 완벽한 요구 사항을 정의한 후에, 다음 단계로 넘어간 이후에도 고객의 요구 사항은 변할 수 있고, 그렇다면 어찌되었건 초기 계획이 잘못될 수 밖에 없습니다. 이미 구현과 테스트로 검증이 끝난 기능에도 기능적인 기능의 추가 및 변경, 디자인 요소의 변경 등을 이유로 고객의 요구 사항은 변할 수 있고, 그렇다면 다시 원점으로 돌아가 이전의 계획은 수정이 되어야 하며, 이미 이러한 경우는 최초 계획이 잘못되었다고 생각할 수 밖에 없습니다.

그 이외에도 초기 계획을 얼마나 정확하게 수립할 것인지는 굉장히 민감한 문제이기도 합니다. 초기 계획 단계를 지나치게 명확하게 강조할 경우 그만큼의 비용이나 시간이 추가되는데, 전체 프로젝트의 일정과 대비하여 그것이 지나칠 경우 실제로 구현이나 테스트를 해야 할 시간은 촉박해 질 수 밖에 없습니다. 프로젝트의 기간은 6개월인데 정확한 프로젝트의 계획 수립을 위해 3개월의 시간을 소비한다면 분명 구현이나 테스트를 여유 있게 할 수 없을 것입니다. 고객을 이해시킬 수 있는 신뢰된 계획안을 보여줄 수 있겠지만, 오히려 불필요한 문서의 양산할 수 있을 가능성이 충분합니다. 이런 경우 프로젝트의 단계별로 거꾸로 기간을 산정하는 역산법 등을 이용하기도 합니다.

폭포수 모델(Waterfall Model)은 여러 가지의 문제 제기를 통해 다양하게 변형된 모델로 발전해 왔습니다. 여기에서는 설명하지 않을 예정이지만, 소프트웨어 개발 방법론은 여러 가지 변형된 형태로 발전해왔음을 알 수 있습니다.

그렇다면, ALM 의 등장 배경을 얘기 하기 위해 왜 이렇게 긴 SDLC(Software Development Lifecycle) 이야기를 했을까요? 위의 이야기에서 볼 때 SDLC 는 바로 소프트웨어를 개발하기 위한 방법론이라는 것입니다. SDLC 는 소프트웨어 공학에서 정의하는 용어로써, 소프트웨어를 효과적으로 개발하기 위한 다양한 방법을 이야기 한다는 것입니다. 즉, SDLC 은 소프트웨어를 개발하는 기술적인 관점을 이야기 합니다.

ALM 은 바로 소프트웨어를 개발하기 위한 기술적인 관점과 더불어 비즈니스적인 가치를 융합하도록 합니다. 소프트웨어의 개발은 기술적이거나 방법적인 문제와 더불어, 실제로 조직 간의 이해 관계, 그리고 비즈니즈 관계의 영역까지 확대됩니다. 소프트웨어를 개발하기 위해 프로젝트의 비전이나 목표 그리고 이것을 이행하기 위한 여러 방법론적인 단계는 통합되고 유기적인 관계입니다. 단지 기술적인 관점에서 바라보는 것이 아닌, 비즈니스 관점에서의 이해 관계나 조직의 측면도 ALM 에서 포괄하고 있습니다.

그렇다면 ALM 은 전혀 새로운 기술이 아님을 알 수 있습니다. ALM 은 이미 오래 전부터 조직적으로 알게 모르게 수행하였고, ALM 을 수행하기 위해서는 어떠한 프로세스적인 요소를 강제하고 있었습니다. 마치 군대에서 기상->아침 구보->보고(점호)->아침 식사-> … -> 저녁 식사->청소->보고(점호)->취침 과 같이 매일 반복되는 프로세스와도 유사할 수 있습니다. 그리고 이런 프로세스가 잘 진행되는지의 여부를 알기 위해 상사에게 "보고" 하는데 소프트웨어 개발 측면에서는 각종 산출물이나 보고서가 필요합니다. 그리고 병사들이 야간 근무를 교대하고 활동을 추적하기 위해 교대 시간마다 기록을 하게 됩니다.

프로세스 강요(Process Enactment)	일관된 프로세스를 강요해야 함
가시화(Visibility)	모든 전반적인 활동에 대한 진행 상황을 볼 수 있어야 함
추적성(Traceability)	모든 활동이나 산출물 등 연관 관계를 추적할 수 있어야 함

표 1 ALM 의 3대 구성 요소

하지만, 이러한 일련의 통일되고 융합된 활동을 한다는 것은 쉽지 않습니다. 문서화나 정형화된 프로세스조차 없는 팀이나 조직이 있는 경우도 있고, 암묵적인 프로세스가 존재하지만 어쨌든 이런 프로세스를 강요한다는 것은 쉽지 않습니다. 또한 팀의 매니저 또는 PM(Project Manager) 나 그 위의 상부 조직은 일이 잘 진행되는지 궁금해 하기 때문에, 이러한 이유로 개발자는 팀장 또는 상사에게 일일 보고서나 주간 보고서를 작성하고, 이것을 다시 취합하여 최종 보고서로 작성합니다. 프로젝트의 단계가 진행될수록 보고서의 양은 늘어나고, 그 종류도 다양해질 것입니다. 어찌 보면, 프로젝트를 위한 프로젝트가 아닌, 보고서를 위한 프로젝트가 되어버리는 셈입니다.

이젠 활동이나 작업을 추적하는 것도 어려울 것입니다. 수십 수백의 여러 가지 종류의 보고서는 이제 버전 관리 하기 조차 버거워질 수 있습니다. 또한 각 역할 담당자들은 결과물, 인도적 차원, 유지보수 차원에서 다양한 산출물을 양산해 냅니다. 필요에 의해 과거의 산출물을 찾는 것도 어렵고, 산출물 자체를 유지 보수 하는 것도 어려워 집니다. 그 외에도 변화하는 모든 활동들은 어떻게 변화했는지조차 알 길이 없습니다. 다양한 산출물과 활동, 그리고 변화에 대한 추적이 불가능 하다면 이미 양산된 문서를 관리하는 것은 결국 의미 없는 활동일 수 있습니다. 실제로 컨설팅 의뢰로 기업을 방문하여 문제를 진단하기 위해 몇 가지 산출물을 요청하여 받은 적이 있으나, 아키텍처가 실제 시스템과 너무 달랐고, 언제, 어떻게 달라졌는지 아는 사람은 아무도 없었던 적도 다반사이기도 합니다.

ALM 의 3대 구성 요소를 조직 전반적으로 융합하기 위해서는 ALM 솔루션이 필요합니다. 관리가 어렵고 정확성을 요구하는 ALM 을 좀 더 쉽게 실현할 수 있는 도구가 필요하다는 것입니다. 초기의 ALM 은 마케팅적인 용어로 사용되면서 초기 ALM 솔루션도 매우 난해했습니다. 단순히 이슈 추적 기능과 소스 제어 기능을 합하여 ALM 이라고 하였으며, 어떤 ALM 솔루션은 테스팅 도구만을 통합하여 ALM 솔루션이라고 하기도 하였습니다.

그림 2 ALM 의 전체적인 컨셉

최근에 ALM 이 정착하는 단계에 들어서면서, 현재의 ALM 과 미래의 ALM 을 분류하기도 합니다. 그리고 아직 이러한 분류 단계는 미성숙한 단계이므로 여러 방면으로 각기 해석을 하고 있습니다. 내용을 정리해 보면 아래와 같이 요약할 수 있습니다.

ALM 0.5 (미성숙 단계)	단순히 여러 가지 소프트웨어 개발 도구를 통합한 제품
ALM 1.0	개발 프로세스의 일관성과 소프트웨어 개발 도구를 통합하고, ALM 실현이 가능한 제품
ALM 2.0	다양한 플러그인의 조합 가능하고 크로스 플랫폼 간의 표준적인 방안을 제시. 조직 내부 뿐만 아니라 시장에서의 각종 요구 사항 또는 변화에 대응

표 2 ALM 의 단계별 정의

위의 내용으로 볼 때, 앞으로 알아볼 Visual Studio 2010 과 Team Foundation Server 2010 은 이미 ALM 2.0 에 매우 근접해 있습니다. 기본적인 ALM 1.0 요소를 충분히 충족하고 있으며, 각 제품은 확장성이 뛰어나고 다양한 클라이언트를 지원하기 위한 크로스 플랫폼을 실현하였습니다.

ALM 의 오해와 진실

ALM 은 아직까지도 많은 오해와 진실 속에 자주 언급되는 용어입니다. 사실 ALM 을 알고 보면 SDLC(Software Development Lifecycle) 처럼 정형화된 어떤 유형의, 또는 무형의 지식으로 갑자기 나타난 기술이 아닙니다. 그리고 무언가를 해결하기 위한 완벽한 솔루션도 아닙니다. 아직도 마치 ALM 에 대해 뜬 구름 잡는 듯한 느낌이 든다면 아래의 몇 가지 질문 답변 형식으로 좀 더 ALM 에 대해 오해와 진실을 이야기 해보도록 하겠습니다.

Q: 그럼 도대체 ALM 은 무엇인가요?

A: 마치 Web 1.0 과 Web 2.0 을 비교하는 것과 같습니다. 기존 Web 1.0 은 기업이나 서비스 제공자에 의해 제공되고 그 주체가 바로 기업이나 서비스 제공자였습니다. 하지만 Web 2.0 의 컨셉은 개방, 협력, 참여, 공유라는 요소를 중심으로 차츰 주체가 사용자에게로 이동하는 트랜드화된 용어이기도 합니다. Web 2.0 의 대표적인 것이 바로 UCC 나 위키피디아(Wikipedia) 와 같은 것들이 있습니다.

ALM 도 이런 트랜드에 크게 벗어나지 않는 용어입니다 ALM 은 궁극적으로 3대 구성 요소를 쉽게 실현할 수 있도록 하였지만, 이것을 실현하기 위해 설계, 개발, 테스트, 유지 보수 등 개발 조직, 운영 조직, 비즈니스 조직 등 여러 조직간에 의사 소통이나 각 단계별로 독립적인 활동을 유기적으로 통합하고 신뢰할 수 있는 데이터를 제공할 수 있도록 ALM 솔루션은 여러 가지 도구와 연동하거나 통합하고 자동화하였습니다.

최종 소프트웨어를 사용할 고객은 품질 좋은 소프트웨어를 사용하길 기대합니다. 요구 사항, 아키텍처, 개발, 테스트, 릴리즈, 유지 및 관리, 추적 등 모든 과정을 ALM 솔루션 안에서 이루어 집니다. 이후에 설명한 Visual Studio 2010 과 Team Foundation Server 2010 을 이용하여 개발 프로세스가 어떻게 개선되고 편리해지며, 어떻게 ALM 을 실현하는지에 대해 천천히 짚고 넘어갈 예정입니다.

Q: 그럼 ALM 을 실현하려면 ALM 솔루션이 필요한가요?
A: 아닙니다. ALM 을 실현하기 위해서 반드시 ALM 솔루션이 필요하지 않습니다. 위에서 군대를 예로 든 ALM 의 3대 구성 요소를 설명한 바 있습니다.

실제로 여러 프로젝트를 경험하면서 ALM 과 유사한 경험을 많이 해 보았을 것입니다. UML 도구를 사용하고 엑셀로 요구 사항이나 개발 진행 관리, 그리고 엑셀의 함수나 스크립트를 이용하여 보고서를 만들고, 테스트와 테스트 문서 및 코드 리뷰 과정을 수동적으로 한 바 있습니다. 사실 관리적인 부분만 본다면 엑셀만큼 뛰어난 도구도 없을 것입니다.

하지만 실제로 수동적인 ALM 실현은 많은 어려움이 따릅니다. 가장 먼저 문서를 매번 업데이트해야 하는 시간적인 문제와 문서의 버저닝(Versioning), 변화에 따른 계획의 수정 및 문서 수정, 테스트를 위한 테스트 케이스 관리 및 테스트 결과 문서화, 그리고 수동적인 코드 리뷰는 사실상 있으나 마나 한 단계이기도 합니다. 특히 반복적인 짧은 릴리즈는 밤을 새게 하는 주요 원인 중의 하나이기도 합니다. 릴리즈 계획도 문제였지만, 버그의 발생은 곧바로 버그의 상황을 문서로 만들어져야 하는 산출물이 되기도 하기 때문입니다.

분명 ALM 솔루션은 여러 가지 어려웠던 요소들을 통합하고 자동화하였습니다. 결과적으로 ALM 은 도구가 없이도 가능하지만, 실현하기 위해서 훨씬 많은 노력이 필요하다는 것입니다.

Q: 우리 팀은 형상 관리(소스 제어) 만으로도 프로젝트가 잘 됩니다. 과연 ALM 솔루션이 필요한가요?

A: 맞습니다. 현재 자신의 팀이나 조직에서 정형화된 프로세스나 암묵적인 프로세스가 존재하고, 개별적인 문서 관리와 소스 제어만으로 ALM 을 실현할 수 있습니다. 그렇다면 현재 자신의 조직이나 팀은 ALM 레벨은 ALM 0.5 세대에 있다고 보시면 됩니다.

소프트웨어의 품질을 높이기 위해서는 많은 노력이 필요합니다. 소스 코드나 문서의 버전 관리, 테스트, 보고서, 빌드, 이슈나 작업의 추적은 한 두 명의 개인이 수행하기는 매우 힘듭니다. 그렇기 때문에 보다 도구를 통합하고 자동화된 솔루션을 통해 ALM 을 수행한다면 훨씬 많은 이점이 있습니다.

Q: 그럼 ALM 을 원활하게 수행하기 위해서는 통합된 ALM 솔루션이 필요한가요?

A: 그렇지 않습니다. 현재 소프트웨어를 개발에 필요한 많은 도구들이 오픈 소스 또는 무료로 제공이 되고 있습니다.

아래는 오픈 소스 중에 .NET 환경에서 사용할 수 있는 도구들을 정리한 표입니다.

	Feature	Visual Studio Team Foundation Server	Open Source
요구 사항 및 변화 관리	요구 사항 관리 이슈 관리 제품 관리	TFS Work Item Tracking	Trac Trac Explorer Redmine
설계	모델링 디자인	Visual Studio UML	Objecteering StarUML UmlDesigner
구현	개발	Visual Studio	SharpDevelop MonoDevelop
구현	소스 관리	TFS Source Control	SVN TortoiseCVS
테스트	단위 테스트	Visual Studio	NUnit NUnit Addin for Visual Studio Test Driven.NET
	성능 테스트	Visual Studio	FWPTT load testing web applications NTime
	테스트 관리	Visual Studio Test and Lab Management	?
	UI 테스트	Visual Studio	.NET Framework UI Automation Library Avignon (HTML, Winform Test based java)
지속적인 통합	빌드 자동화	TFS Team Build	NAnt
지속적인 통합	통합	TFS Source Control TFS Team Build	CruiseControl.NET
코드 리뷰	코드 인스펙션	Visual Studio	FxCop StyleCop
	코드 메트릭스	Visual Studio	Reflector Addin
	코드 커버러지	Visual Studio	NCover
	팀 코드 리뷰	Visual Studio	Review Board SmartBear
프로세스	프로세스 강요	TFS Process Template	?
팀	보고서	SQL Server Reporting Service	?
	역할 구분/보안	TFS	?
	팀 포털/정보 공유	Sharepoint	FlexWiki ScrewTurn Wiki
	다른 도구와 통합	Microsoft Office Sharepoint 등	?
	확장성	TFS Object Model Visual Studio Extensibility	?

표 3 Team Foundation Server 와 오픈 소스 기반의 도구를 통한 ALM 도구 비교

하지만 오픈 소스를 사용하는 것은 저렴하게 ALM 환경을 갖출 수 있지만, 이음매 없는 매끈한 끈과도 같습니다. 도구들 간에 서로 연관성이 없거나 업그레이드가 되지 않는 것들도 상당히 존재하기 때문입니다. 통합되지 않은 각 도구들은 누가 관리를 할 것이며, 연관성이 없는 각 도구들 간의 프로세스를 어떻게 강요할 것인가도 고민해 보아야 할 부분입니다.

저작자표시 비영리 동일조건

'Team Foundation Server' 카테고리의 다른 글

Visual Studio Team Foundation Server 2010 를 설치해보자 (1)	2010.05.03
Team Foundation 트러블 슈팅 가이드 (0)	2010.04.07
TFS 2010 설치 과정 중에 TF255040 문제 (0)	2010.01.26
TFS 2010 Build Service 설치 (0)	2010.01.26
TFS 2010 설치 하기 (0)	2010.01.26

[세미나] 차세대 응용 프로그램 구축 방법 및 사례 소개 세미나

VSTS 2010 팀 블로그 2010. 3. 15. 09:00 Posted by POWERUMC

최근에 많은 기술이 쏟아지고, .NET 의 생태계에도 새로운 국면을 맞이했습니다. 바로 Microsoft 에서 야심차게 준비하고 있는 .NET 4.0 플랫폼과 Team Foundation Server 기술은 상상과 생각을 현실로 이루어주는 강력한 밑거름이 되기 때문입니다.

지금이 아마 우리도 함께 변화할 수 있는 최고의 시점이며, 본 세미나는 그 길을 열어주는 가장 효과적인 세미나가 될 것입니다.

본 세미나는 프로젝트를 주도하는 관리자나 프로젝트 매니저를 위한 세미나입니다. 세미나 신청은 아래 "세미나 등록하기" 버튼을 클릭하십시오.

ALM 의 도입과 그 필요성

여러분의 조직은 효율적이라고 생각하나요? 바꾸어 보십시오. 효과적인 팀의 관리 방법과 한발 앞의 미래를 먼저 바라보는 노하우를 알려드립니다.

기업용 LOB 프로그램의 테스트 환경 구축
오늘날 소프트웨어 개발부터 운영까지 최신의 테스팅 기법과 기술을 직접 눈으로 확인하십시오. 테스트 자동화와 테스트 가상화는 분명 여러분들의 감탄과 탄성을 자아낼 것입니다.

WPF 기반 스마트클라이언트 적용 고객 사례
최신 프레젠테이션 기술인 WPF 를 이용하여 UX 와의 교감, 개발까지 아우르는 현장감있는 그들의 고민과 재미있는 경험을 들을 수 있을 것입니다.

저작자표시 비영리 동일조건

'VSTS 2010 팀 블로그' 카테고리의 다른 글

한국 Visual Studio 2010 사용자를 위한 트위터 커뮤니케이션 (0)	2010.04.14
Visual Studio 2010 팀에서 팀원 모집합니다. (3)	2010.04.06
VSTS 2010 공식 블로그 Viva 2010팀 멤버 추가 모집 공고 (2)	2009.12.07
TECH DAY 2009 행사 오픈!!! (0)	2009.10.22
VSTS 2010 팀 트위터를 오픈하였습니다. (0)	2009.10.07

«이전 1 다음»

Visual Studio 2010 공식 팀 블로그 @vsts2010

카테고리

Search

'Application Lifecycle Management'에 해당되는 글 6건

2011년 .NET 개발자의 생존전략

'VSTS 2010 팀 블로그' 카테고리의 다른 글

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

'Agile Development' 카테고리의 다른 글

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

'Agile Development' 카테고리의 다른 글

[ALM-Test] 3. 테스터에 대한 오해와 진실

'Agile Development' 카테고리의 다른 글

Visual Studio 2010을 활용한 ALM (1-5) - ALM 이란 무엇인가

ALM(Application Lifecycle Management) 의 개요

ALM 이란?

ALM 등장배경

ALM 의 오해와 진실

'Team Foundation Server' 카테고리의 다른 글

[세미나] 차세대 응용 프로그램 구축 방법 및 사례 소개 세미나

'VSTS 2010 팀 블로그' 카테고리의 다른 글

tag cloud

공지사항

최근댓글

최근기사

최근트랙백

글보관함

링크

티스토리툴바

« 2024/4 »
일	월	화	수	목	금	토
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30