X
STEN 회원이 되시면 테스팅에 관한 많은 정보와 자료를 공유할 수 있도록 저희가 돕겠습니다.
아이디
패스워드
자동로그인 사용
 
아직 회원이 아니십니까?    
아이디/패스워드를 잊으셨습니까?    

     
   
[TI 실무] QA, 사용자, 개발자의 효율적인 협업 도구 ATDD,개발자를 위한 TDD소개
글쓴이 : ti 지기 날짜 : 10-04-08 14:35 조회 : 5155 추천 : 0
ti_new_ATTD와 TDD를 활용한 테스트 주도개발_최승희.pdf (2.5M), Down : 117, 2010-06-11 11:22:46

testers insight New Article

 QA, 사용자, 개발자의 효율적인 협업 도구 

ATDD(Acceptance TDD), 

개발자를 위한 TDD(Test Driven Development) 소개 

 부제: ATDD(Acceptance TDD)와 TDD(Test Driven Development)를 활용한 테스트 주도 개발

                                                                           

                                                                                            글_ 최승희(STA 컨설팅)
                                                                                            감수_김창준(애자일 컨설팅)     

 

<요약문>
사용자 테스트 케이스가 개발을 주도하는 ATDD(Acceptance TDD), 단위 테스트 케이스가 개발을 주도하는
TDD(Test Driven Development)의 기본 개념과 가치를 소개하고 ATDD와 TDD의 관계를 살펴본다.

전통적인 개발 방식에서는 소스 코드를 먼저 작성하고 나중에 이를 테스트하는 테스트케이스를 작성해서
테스트 통과 여부를 확인한다. 하지만 테스트 주도 개발 방식에서는 이와는 반대로 테스트케이스를 시스템 구현 이전에
먼저 작성한다. 테스트케이스를 통해 사용자나 개발자의 의도를 먼저 드러내고, 이후 테스트가 통과되도록 실제 시스템을
구현하는 것이다. 또한 이때 작성되는 테스트 케이스들은 리그레션 테스트 시에도 매우 의미 있게 재활용 할 수 있다.
 
ATDD는 주로 사용자 스토리 기반의 애자일 개발 환경에 적합하지만 그렇다고 기존 방식의 개발 환경에서 적용할 수
없는 것은 아니다. 애자일과 같은 명시적 개발 반복 주기가 없을 뿐, 요구사항을 기반으로 테스트 케이스를 작성하고
실행하는 과정은 동일하게 적용할 수 있다.
 
QA, 사용자, 개발자의 효율적인 협업 도구로서 사용자 요구사항과 구현 시스템을 검증할 수 있는 ATDD 개념을 소개한다.
그리고, ATDD 도구인 FIT & FitNesse를 간단한 샘플을 통해 예시와 함께 소개한다. 다음으로 TDD 개념 및 개발 방법을
소개하고 Eclipse IDE(Java 개발 도구) 환경에서 사용할 수 있는 TDD 도구인 JUnit을 간단한 샘플 사례를 통해 예시한다.
또한 ATDD 테스트 케이스와 TDD 테스트 케이스를 비교하여 차이점을 알아본다.
 
테스트에 적용할 수 있는 테스트 설계 기법과 커버리지를 소개하고 커버리지 측정 도구인 CodeCover를 활용하여 측정한
결과를 간략하게 소개한다. 더불어 ATDD와 TDD의 개발 절차를 정리하고 ATDD와 TDD의 관계를 살펴본다.
끝으로 개발과 테스트가 통합된 지속적 통합 테스트 환경의 구성을 예시한다.
 
ATDD가 전체 시스템 관점에서의 외부 품질(시스템 품질)을 검증한다면, TDD는 개별 단위 모듈 레벨의 내부 품질(소스 품질)을 검증한다. ATDD와 TDD 두 가지 모두를 테스트와 개발 프랙티스로서 채택한다면 시스템 품질에 많은 향상이 이루어질 것이고 이를 통해 시스템에 대한 자신감을 얻을 수 있을 것이다.


* 첨부자료를 다운로드하면 아티클 전문을 보실 수 있습니다.


※ 알려드립니다
김창준 대표를 본 기고의 공동저자로 표기한 것을 감수자로 정정합니다.
본 기고는 저자 최승희 컨설턴트의 원고를 김창준 대표가 감수하였고,
추가 보완작성을 통해 게재되었습니다
.

[이 게시물은 스텐님에 의해 2012-10-19 10:32:18 TI 자료실(T-time)에서 복사 됨]

껀쑤맨 10-04-09 12:34
ATDD와 TDD를 활용한 개발이란 게 내용을 보니 SW Process에 의한 개발 조직에서 이미 기존에 하는 것들이고 별 특별한 내용은 아닌거 같습니다. 요구사양 정의 이후에 개발 쪽에서는 상위설계-상세설계-구현으로 이어질 때, Q/A Test 조직에서는 Test 항목정의-Test Case 도출-(Code 구현완료를 전제로)Test 수행...과 같은 단계를 병렬적으로 수행하도록 되어있습니다. 이는 제가 경험한 회사(대기업입니다.)에서 이미 10여년 전에 표준으로 구축하고 그대로 시행해 온 개발 방법론의 방식입니다.

윗 글에서 "전통적인 개발 방식에서는 소스 코드를 먼저 작성하고 나중에 이를 테스트하는 테스트케이스를 작성해서 테스트 통과 여부를 확인한다."라고 언급했는데 언급한 전통적인 개발 방식이 무엇을 지칭하는지는 잘 모르겠지만, 제가 아는 전통적인 SW Process는 Test Case를 먼저 작성하고 나서 Source Code를 작성하는 것입니다.

다만 여기서 혼동하지 말아야 할 것은... SW 개발과 Q/A를 병렬적인 Process로 진행하기 어려운 조직이 있는 이유는, 그것이 전통적이어서가 아니라 인력 부족때문입니다. 인력이 부족하면 병렬적으로 빠르게 진행해야 할 일을 직렬로 진행할 수밖에 없으며 이런 경우는 원칙의 시각에서 중요한 일이 아닌 조직 Performance 측면의 우선순위적 시각에서 일을 수행하게 되는 것이 조직의 살기 위한 본능입니다. 인력이 부족하나 제품은 출시해야겠고... 등등의 상황이 이유가 되어서 SW를 구현부터 해놓고 나서 남는 시간에 Test를 하느라 Case를 작성하고 해왔던 것입니다.

정리하자면 이론은 이론대로, 현실은 현실대로 비교하고 분석해야지 이론과 현실을 오락가락하며 논리를 펴면 엉뚱한 결론이 나올 수가 있습니다. 뭔가하면 새로운 방법론의 필요성이란 것을 주장하려면 Process적 요구방향과 개발 실무의 현실을 구분해서 그 차이점을 중심으로 논리를 가져가야 한다는 것이 제 생각입니다. 인력이 부족한 현실에서 빚어진 문제가 곧 전통적인 Process를 의미하는 것은 아닐테니까요.

별거 아닌 배경적인 내용을 가지고 뭐 피곤하게 따지는가...라고 할지 모르지만 이것은 중요합니다. 제안하는 신기술(?)의 필요성을 주장하는 사람이 그 필요한 논리를 얼마나 정확하게 이해하고 있는가가 바로 이런 배경 논리에 있기 때문입니다.
껀쑤맨 10-04-09 12:47
따라서 ATDD와 TDD에서 주장하려는 중요한 기본 Concept는...
조직적인 SW Process 표준에 의한 개발 수행이 원칙인 조직에서는 이미 있는 내용이며 새로운 철학이 아닙니다. 이미 있는 내용을 가지고 ATDD, TDD와 같은 그럴싸한 이름을 부여하는 것을 어떤 시각으로 봐야 할지요? 글세요...
제가 보기엔 마케팅적인 접근 그 이상으로 보이지는 않습니다.
호시탐탐 10-04-09 15:11
실무 상 프로세스 정립은 필요하고, 이론의 타당성을 생각한다면 기존에 알고 내용이라도 본 기고와 같이 체계적인 정리는 필요하다고 봅니다. 이미 알고 있어도 시도조차 안하고 있는게 얼마나 많은지 말입니다..이제 테스팅 분야도 혼자만 알거나 머리속으로만 정리된 것들을 공유하면서 업그레이드 할 필요가 있는거죠. 사실- 개발이나 다른 분야를 보더라도 이미 알고 있는 이론이나 실무가지고 써먹는게(응용 or 업그레이드) 얼마나 많은지 안다면 말이죠
네오1 10-04-20 09:51
감사합니다.
껀쑤맨 10-04-27 03:36
호시탐탐님의 글이 제 글에 대한 답인지는 잘 모르겠으나... 만일 그렇다라고 한다면, 제 주장의 관점을 잘못 이해하신 것이 아닌가 합니다. 제 글에 대한 답이 아니라면 상관은 없지만... 저의 주장은 Process의 근간이 되는 방법론적인 고찰에서 볼때 첨부 글의 내용의 부적합한 부분을 지적한 것입니다. 즉, 전통적인 Engineering 개념의 시각으로 본 제 생각이 그렇다는 것입니다. 알고 있는데 실천하지 않는 다는 것은 Engineering적 관점이 아닌 Practical 관점에서 보야야 할 또 다른 이야기라 제 주장과는 다소 거리가 있는 이야기입니다. 뭐, 제 주장에 대한 답이 아니라면 이 글 모두 무시해도 되구요...