brunch

매거진 SWQuality

You can make anything
by writing

C.S.Lewis

by Kim Sjoon George Oct 14. 2018

좋은 테스트 케이스? 나쁜 테스트 케이스?

TC의 판단 기준은..?

솔직히 나는 테스트를 잘 모른다. 

도메인별로 제품이 지향해야 할 점을 일일이 알지 못하는 이상 어떻게 내가 그 프로덕트에 대해 테스트를 하겠는가? 탐색적 테스트를 하면 된다고? 어쩌면 그것은 복불복의 경우라고 생각된다. 


어떤 조직으로부터 테스트 설계 컨설팅의 의뢰가 들어왔다고 한다. 이렇게 제3자 형태로 이야기 하는 것은 내가 직접 듣지 못하고 전달 받았기 때문이다. 


의뢰 조직에서 나온 이야기는 아주 원시적이었다. 

TC를 작성해 놓은 것을 보면 너무 체계가 없어요..
개선된 TC와 비교해 주세요




사실 이렇게 이야기 하는 조직을 처음 본 것도 아니었다. 예전 어떤 회사의 품질 부서에서 나에게 대뜸 TC들을 일부 보여주며 


어떠세요? 체계가 없고 엉망이죠? 


라고 해서 내가 좀 당황한 적이 있었다. 


먼저 원인을 보면 증세를 알아야 한다.  이와 같이 이야기하는 것은 어떻게 문제가 발생하고 있는지에 대한 말은 하지 않고 대뜸 "약을 먹었는데 이상해요. 이 약좀 보세요"  라고 약만 보여주는 것과 같은 행동이다. 


TC는 약과 같다. 이 약이 잘 지어 졌는지 여부는 적용후 결과에 대한 분석을 통해 판단이 되어야 한다. 문제점을 파악하려면 


프로덕트 중 이 부분에서 오류가 주로 발생을 하고 있는데 현재 TC로는 이 오류들을 잡아내지 못하고 있어요. 


그러면 발생한 오류들을 분석하고 어떻게 테스트 케이스를 보강해야 하는지에 대한 작업이 진행될 수 있을 것이다. 


예전에 일본의 어떤 엔지니어가 "임상병리학" 에 품질 개선 작업을 비유한 적이 있는 것을 보았는데 나는 너무 적절한 비유라고 생각된다.  증세를 먼저 분석하여야 개선이 이뤄질 수 있다. 



매거진의 이전글 Stackedit의 변신..
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari