'Why programs are failed'에 해당되는 글 2건

  1. 2009.01.02 결함 정보는 Test case로 관리해라!! (1)
  2. 2009.01.02 Issue Tracker (Bug Tracker)적용의 어려움 (1)
이 포스트는 "왜 프로그램은 실패하는가"의 2장을 읽고 썼습니다.

발생한 defect 정보와 그 해결책을 연관짓기 위해서는 defect report를 적기 보다는, test case를 작성할 것을 추천하고 있습니다. 물론 저도 그것에 동의합니다. . 

물론 자세하게 적힌 defect report는 초기에 그 정보를 팀원과 공유하기엔 매우 유용합니다. 

그러나 예를 들면 2주 정도 지난 다음에 그 길게 작성된 따분한 report를 읽는 것은 어떨까요?

만약에 복잡한 state machine의 미묘한 문제같은 같은 것이라면 그 내용을 한참 지난 후에 기억하는 것은 쉽지 않습니다. 

더 나아가 만약에 1달 정도 지난 뒤에 regression testing을 해야 한다면, 그 test case를 작성하는 것 조차 거의 불가능 합니다. 

그래서!!

이 책의 저자는 defect이 해결되면, 바로 test case를 작성할 것을 추천하고 있습니다. 
(사실 이 부분은 제 개인적인 해석이 들어갔습니다. 책에서는 test case를 작성하고 report를 퇴물로 만들어라 라고 되어 있는데, 제 생각에는 최대한 빨리 test case를 작성하라는 것도 포함되어 있지 않을까 싶습니다.)

간혹 어떤 보고서보다도 test case가 더 명확하기도 합니다. test case는 단어보다는 논리로 구성되기 때문입니다.  


This post is written after reading chapter 2 in "Why programs are failed??"


Be linked with happened defect information and its solution, writer recommends make test case, instead of writing defect report, and i agree. 

Of course, at beginning step, defect report which is written in detail is helpful for sharing with team member what happened. 

But after 2 weeks passed from it resolved, how about that i have to read that boring report to verify it??

If that defect is happened in complex condition (For example, a kind of state machine problem) , I cannot remember all of its situation. 

Furthermore, how about i have to do regression test after a month?? Even writing test case  is almost impossible. 

So!!

in this book writer recommends to write its test case immediately when defect is resolved. (Don't be LAZY!!!)

Sometimes, test case code can be more clear than any other report, because test case is the code, and the code is logic not words, i think.

'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
본 내용은 "왜 프로그램은 실패하는가? (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 이전버튼