Oct 31
alonesComputerScience/SE/SQA MS VC++, SE, SQA, Testing, VC++, 소프트웨어공학, 요구사항, 테스팅
MS의 Viusal C++ 팀 블로그에 이 번에도 재미있는 포스트가 올라와서 소개합니다.
이 번 주인공은 VC++ IDE QA팀에서 일하고 있고 근무한 지 5년 정도 된 베테랑인 Alvin Chardon입니다.
6개월 전 새로운 SDET (MS에서는 테스트를 목적으로 테스트 프로그램을 작성하는 사람을 SDET (Software Design Engineer in Test)라고 한다 )를 뽑았고 팀장은 그의 멘토로 우리의 주인공 Alvin Chardon을 지정했다.
Alvin은 멘토가 된 것에 기뻐하며 자신의 경험을 비추어봤을 때, 성공한 과제들은 좋은 계획 (plan)과 일관성있는 설계가 따른 것을 알고, 요구 사항 수집과 스펙 (specification) 작성 위주로 신입을 가리키기로 했다.
새 SDET와 미팅을 한 후 IDE QA팀에서 일을 하기 위해 그가 무엇을 배워야 할지를 알고 작은 과제를 그에게 지시했다.
그가 하고 있는 일과는 관계가 없었지만 그가 C++/CLI과 IDE 관련 기술을 익힐 수 있을 것 같은 일을 시켰다. IDE 팀이 테스트해야하는 것이니 이에 대한 기술을 잘 아는 것도 중요하다고 생각했다.
스펙을 아는 것이 중요하니, 그는 새 SDET에게 요구 사항과 과제의 목적, 그가 결과 물로 원하는 것 등을 명시한 문서를 보냈다.
그 문서를 요약하면 (우리가 새로운 무언가 – 프로그래밍 언어를 포함해서 – 를 배울 때 제일 먼저하는) “Hello World”를 세 가지 다른 언어로 출력하는 것이고 C++/CLI와 .NET을 이용한 프로그램을 작성하는 것이었다.
…
하루 정도가 지나서 신입 SDET는 그에게 자신이 일을 다 마쳤다고 메일을 보내왔다. 우리의 주인공은 확인을 위해 결과물을 보내라고 했는데 신입 SDET는 그에게 자신의 사무실로 와달라고 요청했다.
※ 내가 알고 있기로는 MS 본사는 개인마다 방이 있다.
Alvin이 신입 SDET의 사무실에 도착했을 때 신입 SDET는 Alvin에게 헤드폰과 사운드 카드에 대한 설명을 하기 시작했다. 물론 Alvin은 왜 그가 과제를 확인하로 온 자신에게 헤드폰을 건네며 사운드 카드에 대해서 신입 SDET가 설명을하고 있는지 도무지 이해할 수 가 없었다. 그래서 그냥 신입 SDET가 자신의 사운드 카드에 문제가 있어 도움을 필요로 하는지 알았다.
Alvin이 헤드폰을 썼을 때, 신입 SDET는 Ctrl+F5를 눌렀다 (코드로 짠 프로그램을 실행 시키는 Visual Studio의 단축키).
그 순간…
“Hello World, Hola Mundo and Bonjour Monde!”
이라고 세 개 언어로 헤드폰에서 음성이 출력되었다. 세상에…
Alvin은 “이걸 음성 출력하는 것으로 해버렸군요. 왜 그랬죠?” 라고 (당혹스러웠을 것이다. 이걸 원한 게 아니었을 건데) 신입 SDET에게 물었다.
그의 대답은 “그렇게 하라고 하셔서 한 것입니다” 였다.
Alvin은 자신의 사무실로 돌아가서 자신이 그에게 준 문서를 다시 읽어 보았다.
“HelloWorld 프로그램을 만드시오. 콘솔 (도스 창과 같은) 또는 윈도우 응용 프로그램으로 Visual C++과 .NET 플랫폼을 이용해서 만들고 “hello world”를 세 가지 다른 언어로 말하게 (to say)하시오.”
원문
Create a HelloWorld application, console or windows, using Visual C++ and the .NET platform to say hello world in three different languages.
그랬다. 그는 화면에 출력하는 것을 의미했지만 “to say”라는 것을 신입 SDET는 음성 출력으로 받아들인 것이다.
물론, “say”가 “말하다” 이지만 프로그래밍을 하는 사람들은 일반적으로 그 것이 화면 출력을 의미하지 실제 음성 출력을 의미하지 않는 것을 알 것이고 그럴 경우는 한 번더 물어볼 것이다.
하지만 Alvin은 자신이 요구 사항을 좀 더 명확히 하지 못한 것을 부인할 수 없었다. 신입 SDET가 장난스럽게 과제를 수행했다고 하더라도 문제의 시발점은 Alvin의 모호한 요구 사항에서 출발한 것이다.
웃고 넘길 수 있는 일화이지만, 이 이야기는 중요한 것을 말하고 있다.
자신이 아닌 타인이 볼 문서 – 요구 사항이든, 설계 문서이든 – 를 작성 시 조금만 모호하게 써도 결과는 재앙을 부르기 쉽다. 특히 회사 내 조직을 벗어나 회사 대 회사 간에는 법정 분쟁도 일으킬 수 있을 것이다.
모호한 요구 명세서나 설계 문서는 그 것을 바탕으로 개발하는 다른 개발자를 엉뚱한 방향으로 몰고 갈 수 있고, 그 것을 바탕으로 테스트 케이스를 작성하고 테스트를한 테스트 엔지니어에게는 중요한 결함이나 요구 사항을 테스트하지 못해 시장 결함을 만들 수도 있다.
사람마다 목적과 배경 지식 (스키마)가 틀리니 이를 잘 고려 해야 할 것이고. 프로세스상으로는 리뷰 (Review)나 인스펙션 (Inspection)을 꼭 시행해서 이런 의사소통의 문제를 해결해야 할 것이다.
일정에 쫓기고 사람이 없다고 리뷰 활동을 하지 않는다면, 조금만 시간이 지나서 코드를 갈아엎고 다시 개발하는 악순환을 벗어나지 못할 것이다.
Oct 30
alonesME/People 권투 선수, 무하마드 알리, 인물
저는 그저 무하마드 알리 (Cassius Marcellus Clay)가 세계적으로 유명한 전설의 헤비급 챔피언으로 알고 있었고 “나비처럼 날아 벌처럼 쏘겠다” 라는 명언 정도만 알고 있었습니다.
하지만 최근 EBS 프로를 보고 관련 글들을 찾아 보고 그의 새로운 모습들을 보았습니다.
그의 일생을 돌아보며 그의 강인한 명언들을 살펴봅니다.
1942년 미국에서도 인종 차별이 심한 캔터기 주 루이스빌에서 태어났고 동네 깡패에게 맞지 않고자 권투를 시작해서 17세에 골든 글러브 챔피언이 되고
1960년 로마 올림픽에서 라이트 헤비급 금메달을 땁니다.
고향으로 금의환향했지만 백인 전용 레스토랑에서 노예출신 흑인이라는 이유로 쫓겨나자
금메달도 인종 차별과 가난을 해결해주지 못한다며
금메달을 허드슨 강에 던지며 “당신들이 원하는 챔피언이 되지 않겠다” 라고 했습니다.
1964년 2월 헤비급 챔피언이 되었고 이슬람으로 개종 후 비난을 받았습니다. 그리고 노예로 태어날 때 주인의 성을 딴 이름인 “캐시어스 클레이” 라는 이름을 버리고 “무하마드 알리”로 개명했습니다.
이런 개명을 미국 매 보수 세력이 못마땅하게 생각해 그에게 월남 참전 징집 명령을 내렸지만
“베트남은 우리 흑인을 공격하지 않았고 아무런 원한이 없다. 흑인의 인권마저 보장해주지 않는 미국이 무엇을 위해 전쟁을 하느냐”
며 징집 명령을 거부했습니다.
결국 그는 타이틀뿐만 아니라 권투 선수 면허도 정지되었습니다.
3년 5개월의 법정 투쟁 끝에 무죄 선고를 받았지만 그는 이미 32세 노장 선수가 되어버렸습니다.
주위의 은퇴 권유에도 아랑곳 하지 않고 그는 40연승을 달리던 24세의 조지 포먼을 누르고 두 번째로 헤비급 세계 챔피언이 됩니다 (1974년).
이때 그가 한 말이 “나비처럼 날아서 벌처럼 쏜다” 입니다.
그 이후 젊은 포먼과의 재대결을 앞두고 “나는 복싱보다 위대하다” 라는 말로 자신감을 과시하기도 했습니다.
1978년 형제 복서인 레온 스핑커스에게 패해 타이틀을 내주었지만 재대결해서 다시 한번 세계 챔피언이 됩니다. 세계 최초로 세계 챔피언을 세 번 복귀한 것입니다.
통산 성적 61전 56승(37KO) 5패(1KO) 세 번의 세계 챔피언 복귀
지금까지는 세계 최고의 권투 선수로써의 알리이야기 였습니다.
이후 알리는 권투로 머리에 손상을 받아 1984년부터 파키슨씨 병에 걸렸습니다.
하지만 병으로 떨리는 손과 뒤틀어진 몸도 그의 강인한 의지를 꺾을 수 없었습니다.
1996년 애틀랜타 올림픽 개막식에 성화가 도착하자 관중의 환호성은 울려 퍼졌습니다.
최종주자의 손에 성화가 건네졌습니다. 그러나 전 세계인의 시선이 집중한 성화의 마지막 주자는 살이 늘어지고 초점 없는 눈과 쉴새 없이 떠는 손을 가진 중년의 장애인이었습니다.
뒤틀어진 몸으로 겨우겨우 성화를 점화한 것은 그 광경으로 전 관중을 기립 박수를 하게한 이는 바로 무하마드 알리였습니다.
그는 장애을 극복하기 위해 투지를 발휘했고 선수 시절 벌어들인 돈으로 대학과 뜻있는 단체를 후원하며 세계 빈곤국과 장애인 지원사업에 앞장섰고 여러 자선행사와 봉사활동 참여, 사회빈곤층과 장애인들에게 열정적인 삶의 에너지를 퍼트렸다.
이런 그의 활동이 알려졌는지 2005년, 그는 유엔 평화상을 수상합니다.
20세기 가장 위대한 복서이고 최고 인품의 스포츠맨인 그는
“나는 모든 이의 권리를 존중하는 유머 있는 흑인으로 기억되길 바랍니다. 또, 자유와 정의, 평등을 위해 싸운 인간으로 기억되길 바랍니다. 흑인이면서 장애인인 내가 희망의 끈을 높지 않고 싸워온 것처럼 사회로부터 소외받는 많은 사람들이 세상과 맞서 승리하길 바랄 뿐입니다. 포기하지 않는다면 성공은 가까이에 있습니다. 당신들께 영감을 주었다면 난 그것만으로도 충분합니다.”
라고 말합니다.
Ref
- 전설의 복서, 무하마드 알리
- 무하마드 알리 인물 정보
- 무하마드 알리 관련 지식인 정보
- [게티 파일] 무하마드 알리 14-26
Oct 28
alonesweb2.0 blog, blogging, syntax highligher, SyntaxHighlighter, 블로그, 블로깅, 포스트
SyntaxHighlighter는 Jepung님등 몇 분이 사용하고 있는 Java Script 도구로써 아래와 같이 코드를 포스팅할 때 유용합니다.
그리고 프린트나 카피와 같은 메뉴를 내장하고 있어서 더욱 유용하다.
SyntaxHighlighter는 다음과 같은 언어에 대해서 하이라이트 기능을 제공합니다.
| Language |
Aliases |
| C++ |
cpp, c, c++ |
| C# |
c#, c-sharp, csharp |
| CSS |
css |
| Delphi |
delphi, pascal |
| Java |
java |
| Java Script |
js, jscript, javascript |
| PHP |
php |
| Python |
py, python |
| Ruby |
rb, ruby, rails, ror |
| Sql |
sql |
| VB |
vb, vb.net |
| XML/HTML |
xml, html, xhtml, xslt |
설치 & 사용법
■ 호스팅을 받는 경우
호스팅을 받는 경우는 SyntaxHighlighter에서 파일을 받아 서버에 올리고 올려진 위치에 맞게 java script 코드를 스킨에 써주면 된다.
- 설치 방법 –
1. SyntaxHighlighter에 접속해 우측에 있는 Featured Downloads에서 rar로 압축된 파일을 다운로드 받는다.
2. 다운로드 받은 파일을 압축을 풀고 서버에 올린다.
이 때 “www” 폴더 아래에 폴더를 만들어서 올린다. 스킨 파일에서 주소로 java script 파일이나 css 파일을 접속해야 한다.
나의 경우는 www/blog가 블로그 주소여서 www/blog/HighLighter라는 폴더를 만들어서 압축을 푼 파일을 모두 올렸다. 
3. 스킨의 </body> 앞에 다음과 코드를 작성한다.
※ <올린위치> 라고 되어 있는 부분은 압축을 푼 파일의 위치를 입력하면 된다.
나의 경우는 http://alones.kr/blog가 주소이고 www/blog에 HighLighter라는 폴더를 만들어서 압축을 푼 파일을 올렸기 때문에
<올린위치> 가 http://alones.kr/blog/HighLighter 가 된다.
- 사용 방법 –
<pre> tag와 <textarea>를 사용하는 방법이 SyntaxHighlighter에 소개되어있는데 <pre>는 ‘<’등을 “<”와 같은 html에 충돌이 나지 않는 것으로 변환해야 하기 때문에 <textare>를 권장한다.
1. 다음과 같은 c++ 코드를 멋지게 작성하려면 일단 소스를 Ctrl+C로 복사한다.
※ 물론, 위에서 거론했듯이 html, java, javascript, c/c++, phyton 등 모든 코드가 가능한다.
#include <iostream>
int main(int argc, char *argv[])
{
std::cout<<”Hello world!~”<<std::endl;
return 0;
}
2. 포스트 작성 시 html 모드로 전환하고 아래와 같이 <textarea>로 붙일 부분을 작성한다.
<textarea name="code" class="cpp" cols="60" rows="10">
... 여기에 코드를 복사 ...
</textarea>
3. 위에 작성한 <textarea>에 코드를 복사하가 cols와 rows를 조정한다.
그리고 class=”cpp”와 같이 어떤 코드인지를 명시한다. 상기에 있는 표에서 해당 언어의 Aliases 의 해당 이름을 써주면 된다.
■ Tistory등 서비스를 받는 경우
이 경우도 사용법은 동일하고
설치는 포스트를 하나 작성하고 압축을 푼 폴더 내에서 java script와 css, swf 파일을 첨부로 한다. 그리고 스킨을 수정할 때 해당 경로를 포스트에 첨부한 경로로 해주면된다.
예) Jepung님의 이 포스트의 소스 보기를 해보면 알 수 있다.
Oct 26
alonesComputerScience/SE/SQA ms, Software Testing, SQA, Testing, 테스트, 테스트 사례
최근 MS VC++ 라이브러리 개발팀의 테스트 자동화에 대해서 소개해 드렸습니다.
이 번엔 MS VC 컴파일러 개발팀의 QA팀에 대해서 소개해드리겠습니다.
이 전 포스트와 마찬가지로 Visual C++ Team Blog에 게시된 내용입니다.
먼저 두괄식으로 정리를 하면 다음과 같습니다.
■ QA (Quality Assurance)팀 일원들이 자신의 일을 자랑스럽게 여긴다.
■ SQA (Software Quality Assurance)팀은 우리가 잘 알고 있지만 행하지 않는 Software Testing의 해야 할 일들을 그 어떤 조직보다 체계적으로 잘 수행하고 있다.
글을 쓴 사람은 Smile Wei로 VC++ 컴파일러 팀 내에 있는 QA 팀 (SDET)에 3개월 반 전에 합류했고 VC 컴파일러에 대한 QA일을 하고 있습니다.
그는 자신의 포스트를 쓴 목적이 (위에서 정리한 것과 같이)
Microsoft, 특히 VC 팀에서일하는 것을 좋아하느냐? (정확히는 QA팀)
VC 팀의 QA팀에서는 매일 무슨 일을 하느냐?
에 대한 답변을 위해서 글을 쓴다고 합니다.
1. Microsoft, 특히 Visual C++ 컴파일러 팀에서일하는 것을 좋아하느냐? (정확히는 QA팀)
이에 대한 답변으로 Smile Wei는 (당연하겠지만) QA 일을 하는 것을 사랑하고 자랑스럽게 생각합니다.
그리고 “일반적으로 QA 엔지니어가 개발자보다 기술적으로 떨어진다는 생각을 여기서는 하지 말라” 라고 단호하게 이야기 합니다.
흔히 생각하는 메뉴얼 테스트나 단순한 테스트 input을 넣은 코드 베이스의 (like unit test) 테스트를 하는 일이 아니란 것입니다.
VC 컴파일러의 테스트니 당연히 테스트 input은 소스 코드이고 (이 것만으로 일반적인 테스트와는 구분될 것입니다), 테스트는 x86, amd64또는 ia64의 여러 형태의 머신에서 수행되고 수많은 컴파일러 옵션을 조합해서 테스트를 수행한다고 합니다.
즉, 동일한 테스트 케이스도 다른 머신, 다른 수행 환경 (컴파일러 옵션 등)에서 성공되기도 하고 실패하기도 하며 그것의 원인을 분석하는 것도 힘든 작업이라고 합니다.
그래서 QA팀에서는 테스트 input을 만들 때 내부에서도 고민을 많이 하지만 개발자와도 많은 논의를 한다고 합니다.
그래서 이와 같이 기술적으로 난이도 높은 (일반 개발자가 하기 힘든)일을 하는 것이 자랑스럽다고 하고 자기 주변의 개발자들이 한 주 씩 끙끙거리며 버그를 찾는 것을 자신이 쉽게 찾아 내는 것에 대해서 희열을 느낀다고 합니다.
※ [제 생각]잠시 생각해보면, 제 주위 뿐만 아니라 많은 사람들이 테스팅을 하든 테스트 기법을 연구든, 테스트 도구를 만들든 “테스트”와 관련된 일을 하는 것을 이와 같이 자랑스럽게 생각하는 것을 본적이 없습니다. 저도 마찬가지 이구요.
그 이유는 무엇일까요? 바로 (기술적) 전문성이 다른 분야에 비해 떨어져 보인다고 생각하기 때문일 것입니다. (일용직 아르바이트 또는 신입 사원에게 테스트를 맡기는 국내의 현실을 보면 당연하겠죠) 하지만 테스팅 (도구이든 기법이든, 행위든)이라는 분야가 그렇게 기술적 도메인 지식이 얕은 곳은 결코 아닌 것 같습니다. 이에 대해서는 다음에 포스팅 하겠습니다.
2. VC 팀의 QA팀에서는 매일 무슨 일을 하느냐?
(저는 이 부분이 무척 궁금했는데, 역시 기대 이상으로 멋진 부분들이 많았습니다)
Smile Wei는 그가 VC 컴파일러 팀의 QA팀으로 다음과 같은 7가지 정도의 일을 매일 수행한다고 합니다.
1. 버그 분석
말 그대로 테스트 수행 후 발견된 버그에 대해서 분석한다고 합니다. 그리고 예상하시는 것 처럼 MS에서는 Daily Testing 이 프로세스로 정착되어 매일 테스트가 수행되고 그에 대해 결과를 분석한다고 합니다. 물론 이를 위해 거의 대부분 테스트 자동화가 되었겠죠. (예전 저의 포스트에서 소개해드린 것처럼) 이 일이 최고 우선순위라고 합니다.
2. 테스트 케이스 수정과 Regression 테스트 케이스 작성
기존 작성되어 있는 테스트 케이스의 수정 뿐만 아니라 새로운 Regression (회귀) 테스트 케이스 작성을 의미하는데, 특이한 것은 Double Assurance Mechanism 이라는 프로세스 입니다.
개발자가 버그를 수정하고 자신의 테스트 케이스로 수정확인을 하고 QA팀에게 전달하면 QA팀에서는 좀 더 복잡하고 다양한 테스트 케이스를 수행해서 수정이 올바르게 되었는지 한 번 더 확인하는 것입니다.
앞에서 설명했듯이 다양한 환경과 컴파일러 옵션으로 더 복잡한 테스트 케이스를 이용해 수정된 부분이 올바르게 동작하는지 regression 테스트로 확인하는 것입니다.
즉, side effect가 발생했는지 확인하는 프로세스입니다.
누구나 알고 있는 것이지만 일정이나 인력을 핑계로 하지 않는 것을 실제로 잘 행하고 있는 것 같습니다.
실제로, 이와 같은 활동으로 인해 Smile Wei가 가지고 있는 테스트 케이스는 약 20,000개이고 이 것은 컴파일러 팀의 QA팀이 가지고 있는 10개의 test suite (test case의 집합) 중 하나라고 합니다. 하지만 이 것은 VC++ 컴파일러 팀이 가지고 있는 것이고 VC++ 라이브러리 개발팀이나 IDE 팀, 릴리즈 팀, Visual Basic 팀, C# 팀들도 이와 같은 팀들도 각각의 테스트 케이스를 확보하고 있다고 하니 놀랍습니다.
아무튼, 상상을 초월하는 테스트 케이스들이 매일 수행되어진다고 합니다. 물론 테스트 자동화 없이는 불가능 할 것입니다.
3. QFE (Quick Fix Engineering) 확인
QFE는 흔히들 말하는 hotfix (필수 업데이트. e.g. 윈도우 필수 업데이트)에 대한 검증 작업입니다.
QFE 또한 2차에 걸쳐서 수행된다고 합니다.
QFE 프로세스를 살펴보면,
지원 팀 (support team)에서 고객으로부터 버그 리포트를 수집하고 버그를 확인 후 개발팀에 버그 리포팅을 합니다. 개발팀은 버그를 수정 후 QA 팀에게 수정 여부를 알려 QA팀의 테스트가 시작되는데, 1차는 hotfix에서 버그를 발견한 고객에게 수정된 hotfix를 전달하기 전에 테스트를 수행하는 것이고 2차는 버그를 발견한 고객이 버그 수정을 확인 후 최종 릴리즈를 위해 전체 테스트를 수행하는 것이라고 한다.
(버그 수정 후 QA팀이 테스트를 수행하고 버그 발견 고객이 버그 수정이 올바르다고 확인하면 최종 릴리즈를 위해 전체 테스트를 다시 수행하는 프로세스입니다.)
고객과 직접적으로 관련된 일이기 때문에 QFE 확인은 최고의 우선 순위를 가지는 작업이라고 합니다.
4. 크로스 팀 테스트 지원 (cross-team test support)
글을 읽을 수록 MS의 QA팀은 테스트에 강박 관념을 가진 것 같습니다 (좋은 뜻).
VC 컴파일러 팀의 테스트 케이스를 다른 팀에게 제공하는 작업을 의미합니다. 예를 들어 Smile Wei는 최근 Visual Studio 2008 설치 프로세스를 위해 릴리즈 팀에게 자신의 테스트 케이스를 그들이 수행할 수 있게 제공했고 또한 라이브러리 팀을 위해 VS 2008 MSDN 테스트를 수행해줬다고 합니다. 두 작업을 통해서 몇 가지 버그를 발견했다고 합니다.
흔히 개발자가 자신의 관점에서만 테스트를 하기 때문에 제 3자의 다른 각도에서 테스트를 하는 것이 필요하다고 하고 그것을 위해 다른 조직 (QA팀)에서 테스트 케이스를 작성하고 테스트를 합니다. 이 것을 넘어 MS에서는 각 QA팀 간에도 서로 테스트 케이스를 공유해서 좀 더 다양한 뷰에서 테스트를 강도 있게 수행하고 있습니다.
5. 내부 테스트 도구 개발
(이 일은 제가 하는 일과도 유사합니다만..)
위에서 거론 한 것처럼 MS는 모든 제품에 대해서 매일 테스트를 수행하고 각 테스트 수 십만개 또는 수 백만개의 테스트 케이스를 수행합니다. 이 것을 위해서는 당연히 테스트 수행, 결과 수집, 결과 비교와 같은 모든 테스트 과정이 완전 자동화 되어야 할 것입니다. 이 것을 위해 아주 많은 테스트 도구들이 사용된다고 합니다.
MS에서는 각 연구원들이 여러 형태의 내부 테스트 도구를 개발해서 테스트 효율성을 높이는 것을 독려하고 그 중 몇 몇 도구는 모두 부서 또는 MS 전체에서 채택해서 사용하게 하기도 한답니다.
6. 새로운 기능에 대한 테스트 케이스 작성
현재 VS 팀은 VS2008의 차기 버전을 준비하고 있다고 합니다. QA팀은 모든 새로운 제품 및 기능에 대한 테스트 활동에 참여합니다.
또한 테스트 프로세스가 제품 개발 주기의 코드가 완료되기 훨씬 이전의 초기에 시작된다고 합니다. 즉, Waterfall 모델이 아닌 애자일 (Agile) 모델을 채택하고 있습니다. 누구나 알고 있는 “버그를 발견한 시점이 제품 개발 주기 후 반부로 갈 수록 비용은 훨씬 더 많이 증가”한다는 사실을 직접 실행해 옮긴 것입니다.
7. 기타
이 외에도 캠퍼스 리크루팅, 신입 사원을 위한 교육 자료와 비디오 작업, 면접 등을 수행합니다.
정말 많은 일을 하는 것 같습니다.
중요한 것은 Software Testing에서 흔히 말하고 Testing 분야에 조금이라도 관심이 있거나 관련 일을 하는 사람이면 누구나 알고 있는, 그렇지만 여러 가지 핑계로 행하지 않는 것을
MS의 QA팀은 체계적으로 수행한다는 것입니다.
우리는 성공하는 사람들의 위인전을 너무나 많이 읽고 심지어 그 방법도 머리 속에 다 알고 있지만, 여러 가지 현실과 그 것으로 만든 자신 (조직) 만의 핑계로 행하지 않습니다.
성공하는 사람들은 그 명백한 방법을 행동으로 옮긴 사람이겠죠? MS처럼
Oct 22
alonesComputerScience/SE/SQA Automation, SQA, Test Automation, test framework, Test Tool, 테스트, 테스트 자동화, 품질
Test Automation.
이와 관련된 일을 조금이라도 했던 사람이면 제가 무슨 말을 하고 싶은지 아실 겁니다.
테스트 자동화는 단위 시험 (Unit Test) 부터 통합 시험 (Integration Test), 시스템 테스트 (System Test)까지 어떤 시험에서도 필요할 것입니다.
JUnit, CUnit, CUTest, CppUnit, CppUnit2, NUnit 등과 같은 수 많은 open test framework들이 단위 시험과 통합 시험의 자동화를 도와 줍니다. 그리고 PARASOFT의 C++ Test와 같은 멋진 상용도구도 있습니다.
(※ XProgramming.com의 Software 페이지에 보면 수많은 Unit test framework들이 열거 되어 있습니다.)
그리고 TestQuest, TestDirector와 같은 시스템 테스트 자동화 도구도 있습니다.
그리고 위에 열거된 도구를 이용하든 자체 제작을 하든 자신들의 개발 소프트웨어를 위한 테스트 자동화를 위해 멋진 도구를 만들어보려고 (또는 보라고) 시도 했거나 하고 있을 겁니다.
(서두가 길었습니다)
하지만 문제는 주객이 전도되는 경우가 많고 테스트 자동화를 맹신해서 아주 어렵게 마련한 품질향상의 노력 (effort)을 낭비하는 경우를 종종 보아왔습니다.
테스트 자동화의 목적은 무엇일까요?
반복되는 작업을 줄이기 위한 것이지 아주 요상하고 복잡한 시나리오로 발생할 수 있는 버그 (defect)을 잡아주는 것이 아닙니다.
각 개발자들이 작성한 수 백개의 테스트를 밤새 회귀 테스트 (Regression Test)를 목적으로 자동으로 돌려주는 것,
MP3의 볼륨 업/다운을 만번씩 눌러보는 것을 자동으로 처리해주는 것,
이 와 같은 일들을 소프트웨어를 이용해서 (또는 하드웨어를 이용해) 자동으로 해주는 것이지 복잡한 Race condition을 자동으로 만들어 (만들었다 하더라도) 어떤 상황에서 문제가 발생했는지 짜잔하고 리포팅해주는 것이 테스트 자동화는 아닐 것입니다.
즉, 단순한 반복 작업을 자동화하는 것이 목적일 뿐입니다.
물론, 아주 smart한 도구 (가령 정적 분석 (Static Analysis) 을 잘 하거나 동적 분석을 잘 해서) 가 그런 어려운 것들을 해줄 수도 있겠지만, 그러한 멋진 일들은 돈을 안 들이고 오픈 소스 도구나 자체 개발을 통해서 이루어질 성격의 일들이 아닐 것입니다.
힘들게 짜낸 Effort는 어디다 써야 하는가?
여러 분의 조직은 Agile에 기반해 Regression Test를 잘 하고 있는 조직 (또는 과제)입니까?
여러 분의 과제는 규모가 크고, 기간 또한 넉넉합니까? 아니 테스트를 위한 시간이 충분합니까?
위 두 질문에 선뜻 답할 수 없다면 테스트 자동화는 잠시 미루어두는 것도 나쁘지 않은 것 같습니다.
테스트 자동화를 위한 시간 (Research든, Customizing이든, 새로 개발하든)은 Regression Test가 프로세스에 맞게 주기적으로 이루어질 때 빛을 발 할 수 있습니다.
어떤 논문을 보니 테스트 자동화를 위해 들인 시간은 초기 몇 번의 Regression Test 때는 그렇게 하지 못한 것 보다 시간이 더 많이 들어간다고 하더군요.
즉, WaterFall 모델로 부족한 시간과 인력으로 중.단기에 끝내야하는 과제에서 귀중하게 테스트를 위해 시간과 인력을 할애 했다면 테스트 자동화 보다는 매뉴얼 (수동으로) 로 블랙박스 시스템 테스트를 하는 것이 훨씬 더 효율적일 것입니다.
자동화를 하고 나면 테스트할 시간이 없거나 (대게의 경우 이런 성격의 프로젝트는) 모든 것이 변경되어 테스트 자동화를 새롭게 해야하는 난감한 상황을 맞이할 것입니다.
MS VC++ 개발팀의 테스트 자동화 사례를 소개해드렸듯이, 테스트 자동화는 시간과 노력을 줄여 줄 수 있는 유익하고 중요한 일입니다.
하지만 자동화 노력 이전에, 여러 분 프로젝트의 여건과 자동화를 위해서 얻을 수 있는 것이 무엇인지 먼저 생각해보아야 할 것입니다.
그리고 더 중요한 것은 테스트를 잘하겠다는 의지와 멋진 테스트 케이스일 것입니다.
Older Entries
![[iPhone][Tutorial #5] Http Request결과를 JSON으로 쉽게 파싱 해보기](http://alones.kr/wp-content/plugins/wordpress-popular-posts/no_thumb.jpg){kind=small}