'defect state'에 해당되는 글 1건

  1. 2009.01.02 Issue Tracker (Bug Tracker)적용의 어려움 (1)
본 내용은 "왜 프로그램은 실패하는가? (Why programs are failed?)"란 책을 읽으며 작성한 글입니다. 

일반적으로 정말 단순한 프로그램을 개발하는 것이 아니라면, Issue tracker 혹은 bug tracker라 불리는 시스템을 사용하게 됩니다. 

대표적인 툴로서, 먼저  bugzilla 와 Mantis가 있습니다. 둘 다 Open source기반이고, Web 기반입니다. 
그러나 제가 리눅스에 매우 약한 이유로 이 둘은 써본적이 없습니다 -_-;;

그리고 상용프로그램은 대표적으로 Perforce와 IBM의 Clear Quest가 있습니다. 
Perforce는 써본지 워낙 오래 되었고, 당시에는 이런 툴의 목적도 몰랐고 잘 쓸줄도 몰랐고 -_-;; 사실 지금은 Clear Quest밖에 쓸 줄 모릅니다. 

그렇지만 이런 Issue tracker류의 프로그램은 사용방법이 대동소이 한 것 같습니다. 

Defect정보를 등록하면 (Defect Submit), Project manager에 의해 개발자 혹은 누군가에게 할당되고 (Assign), 개발자는 그 문제를 분석 및 수정한 후에 수정되었음을 표시하고 (Resolved), 해당 defect의 수정이 확인되면 (Closed)시키는 process를 갖게 됩니다. 물론 reject, reopened등의 state가 있지만, one-shot 에 수정가능하다는 전제하에^^ (이와 다르게 하는 경우도 있나요? 있으시면 리플좀 ^^;)

물론 이 책에서 처럼 Unconfirmed, verified 등의 state가 있을 수는 있으나 이는 생략이 가능해 보이고, 

이 책에서 표시된 "WONTFIX" (Will Not Fix)는 사실 아직 겪어보진 못했습니다.
요구사항에 명시되어 있는 대로 동작하지 않는 다는 것을 알면서도 고치지 않겠다라는 건... 글쎄요. 아마 현재의 상황에 어쩔 수 없는 선택이겠지요? 그렇다면, 이는 시간 (혹은 현재의 어떤 특별한 상황)의 문제일 뿐, 나중엔 고쳐져야 하지 않을까 싶습니다. (그렇다면 POSTPONE 처리) 아니면, "고칠 이유가 없다"라는 이유로 고치지 않겠다고 하면, 이 defect을 올린 test engineer가 가지고 있는 requirement spec이 현재 개발이 가는 방향과 일치하지 않는다는 것입니다. 그렇다면 요구사항 변경  process를 수행해야 겠죠. (요구사항의 문제 혹은 SQA Error로 Close 할 수 있음). 

그리고 이 책엔 SCCB (Software Change Control Board)가 나옵니다. defect을 누구에서 assign할 것인지, severity, priority를 정하기 위한 모임이라는데... 개발자, 테스터, 형상관리자가 참가한다고 나옵니다.
근데 이 정도면 개발팀 전체 다 나오라는 것 같군요... -_-;;

사실 defect의 severity는 개발팀과의 관계에도 매우 민감한 문제입니다. 일반적으로 critical 혹은 Major수준의 defect이 발견되면, 해당 S/W는 출시를 하지 않아야 합니다. 그런에 이 구분 명확하지 않아 애매모호 하면, 개발팀과 의견 충돌이 발생할 수 있습니다. 

실제 이런 경우가 있었습니다. 

모 개발 조직에서 defect의 severity를 책정할 때, Requirement Spec violation은 Major defect처리 한다. 라고 정하고 시작하였습니다. 그러다 테스트 도중 거의 일반적인 user scenario에서는 쓰이지 않는 기능중에서 spec과 약간 다르게 동작하는 현상 (Spec과 다른 error code반환) 을 발견했습니다. 이를 issue tracker에 major defect으로 등록하자 

개발팀 : 이 defect은 major급이 아니다. 어짜피 error는 발생시켰지 않느냐,, 그 error code가 아니더라도, 일반적으로는 error가 발생하면 retry하기 때문에, 동작은 같다.
SQA팀 : 해당 error code는 Industry spec에 명시되어 있으며, 우리의 requirement spec에 우리의 product는 Industry spec을 따른다고 명시되어 있다. 그리고 모든 사용자가 그 "일반적"이라는 시나리오 대로 사용할 것을 보장할 수 있는가?  
개발팀 : 그러나 이 문제로 다시 시스템 테스트 process를 밟으면 납기 일정을 맞추지 못할 수 있다. 그 risk가 더 크다. 동작이 크게 틀리지 않은데 굳이 major로 처리해야 하는가? 
SQA팀 : 물론 일정의 문제는 이해하지만, 그렇다고 spec violation을 아니라고 할 수는 없다. Major처리 하겠다.

머 대략 이런 경우입니다. 많이 공감하시는지 모르겠습니다. 전 하도 많이 겪어봐서 -_-;; 대부분 납기 일정에 쫓길 때 이런 상황이 많이 발생하더군요. 이럴땐 기획이나 마케팅의 자문을 구해 일정의 critical한 수준을 보고서 판단하여 해결하는 경우가 많았습니다만... 참 어렵더군요. 하지만 이런 일을 겪으면서 defect의 severity를 정하는 지표가 도출되어 점점 나이지긴 했습니다.

추가 : Issue tracker가 필요한데 서버도 없고, 서버 운영할 사람도 없으면 google의 Project hosting을 참고하세요~ 무료입니다!!

'Software Testing > Knowledge Base' 카테고리의 다른 글

Combinational Analysis #3  (4) 2009.03.05
Combinational Analysis #2  (3) 2009.03.01
Combinational Analysis #1  (0) 2009.02.05
결함 정보는 Test case로 관리해라!!  (1) 2009.01.02
Issue Tracker (Bug Tracker)적용의 어려움  (1) 2009.01.02
Posted by yunseong
이전버튼 1 이전버튼