이 포스트는 "왜 프로그램은 실패하는가"의 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
이전버튼 1 2 3 4 5 이전버튼