[질문] Unit/Component Test와 테스터
글쓴이 : 최피디 날짜 : 08-08-28 12:22 조회 : 882
v-model을 살펴보면, Unit testing의 경우 개발자들에 의해서 진행되는 것 같은 인상을 주게 됩니다. 유닛테스트가 개발과정에서 클래스나 메소드상의 오류들을 발견하기 위한 목적이니 당연히 개발자가 주도하는 것이 맞겠지만 테스터가 유닛테스팅까지 커버하는 경우는 없는지 궁금합니다. 즉, 동적인 화이트박스테스팅도 테스팅의 영역인데, 왜 개발자들에게 의존적으로 가야하는 지 궁금합니다.
박정훈2
08-08-28 16:02
길가다가 연예인을 만나면 분명히 처음 만나는 것인데 익숙한 기분이 듭니다. 마치 잘 알고 있는 사람 같죠. 김혜수 같은 연예인들은 이런 것을 알고 길가다가 눈이 마주치면 인사를 한다고 하네요, 밝고 힘차게. 하지만 우린 지나치면서 생각하죠. "아~ 처음 보는데 되게 잘 아는 사람 같군!"
QA를 의인화 하자면, 어쩌면 저런 문제들은 모두 'QA라는 녀석의 업보' 일지도 모르겠습니다. 잘 모르는 사람이 테스트 좀 해 봤다고, QA 책 좀 읽었다고, 수 많은 mis-cummunication을 만들어 냅니다. 프로그램 업무는 프로그램 전문가에게 맡기면서, 왜 테스트 업무는 테스트 전문가에게 맡기지 못하는지....
결론만 말하자면, 고민하시는 경우의 대부분은 communication 중 Unit에 대한 정의를 잘 못 내리고 있거나 테스트의 범위에 대해 mis-communicate되는 부분이 존재하기 때문입니다.
(더 헷갈리시겠군요.
저 멀리서 제가 아는 형님이 '또, 또 저렇게 이상하게 얘기 한다~' 라면서 빈정대는 소리가 들리네요.)
길가다가 연예인을 만나면 분명히 처음 만나는 것인데 익숙한 기분이 듭니다. 마치 잘 알고 있는 사람 같죠. 김혜수 같은 연예인들은 이런 것을 알고 길가다가 눈이 마주치면 인사를 한다고 하네요, 밝고 힘차게. 하지만 우린 지나치면서 생각하죠. "아~ 처음 보는데 되게 잘 아는 사람 같군!" QA를 의인화 하자면, 어쩌면 저런 문제들은 모두 'QA라는 녀석의 업보' 일지도 모르겠습니다. 잘 모르는 사람이 테스트 좀 해 봤다고, QA 책 좀 읽었다고, 수 많은 mis-cummunication을 만들어 냅니다. 프로그램 업무는 프로그램 전문가에게 맡기면서, 왜 테스트 업무는 테스트 전문가에게 맡기지 못하는지.... 결론만 말하자면, 고민하시는 경우의 대부분은 communication 중 Unit에 대한 정의를 잘 못 내리고 있거나 테스트의 범위에 대해 mis-communicate되는 부분이 존재하기 때문입니다. (더 헷갈리시겠군요. 저 멀리서 제가 아는 형님이 '또, 또 저렇게 이상하게 얘기 한다~' 라면서 빈정대는 소리가 들리네요.)
Kreno
08-08-29 11:57
답변과는 약간 거리가 있는 얘기일지 모르고, 제 사견입니다. (그냥 참고만..)
아무래도 클래스의 메소드 상의 오류를 발견하기 위해서 개발자의 도움은 필요하지만 개발자에 끌려다닐 필요는 없습니다. QA팀을 독립적으로 두는 이유와 연관되어 있는데, 아무래도 자신이 짠 코드를 자신이 테스트를 하다보면 헛점이 있기 마련입니다. 메소드의 파라미터와 리턴값에 대한 정보를 보고 Test Engineer가 그에 맞는 테스트 케이스를 설계해서 직접 테스트를 하던지, 아니면 개발자에게 넘겨서 Unit Test를 하는게 좋을 것 같습니다. Test Engineer 분이 프로그래밍에 대한 경험이 있다면 더욱더 쉽고 악랄하게 버그를 잡으실 수 있을겁니다.
저두 위의 분처럼 예를 들어봅니다. Test라는 클래스는 int GetFileCharNum(char* strFileName); 라는, txt 파일을 읽고 문서의 문자의 수를 리턴하는 메소드를 가지고 있다고 봅시다. 리턴값은 파일 내의 Char 개수이고, 파라미터는 파일 이름입니다. 이 메소드를 UnitTest한다고 한다면 많은 개발자는 잘 되는 파일 몇 개 읽어보고 잘 된다고 생각하고 PASS 할것입니다만, Test Engineer 는 그냥 넘어가지 않겠죠? : )
테스트 케이스를 이런식으로 작성해주면...
1. 빈껍데기 파일
2. OS에서 지원하는 파일 이름 길이만큼의(윈도우즈는 아마 255자?) 긴 파일 이름을 가진 파일
3. 엄청나게 큰 파일
4. Unicode(UTF-8) 문자셋 파일
5. Unicode(UTF-16) 문자셋 파일
6. Unicode(UTF-32) 문자셋 파일
7. Unicode(UTF-4) 문자셋 파일
8. ASCII 문자셋 파일
9. Full Path 입력(c:\가나다라마바사\가나다\aaa.txt)
10. 엄청나게 긴 FullPath 입력
11. 깨진 파일
12. 잘못된 Path 입력
13. 없는 파일 이름 입력
14. 다른 형태의 파일 정보 입력(abc.doc)
... 뭐 이 밖에 요구사항에 따라 더 늘어나겠지만 일단 생각나는건 이정도...
이 TestCase하고 기대값을 던져주세요. 욕은 하겠지만 이 중에 걸리는게 꼭 있을겁니다. -.-;;
답변과는 약간 거리가 있는 얘기일지 모르고, 제 사견입니다. (그냥 참고만..) 아무래도 클래스의 메소드 상의 오류를 발견하기 위해서 개발자의 도움은 필요하지만 개발자에 끌려다닐 필요는 없습니다. QA팀을 독립적으로 두는 이유와 연관되어 있는데, 아무래도 자신이 짠 코드를 자신이 테스트를 하다보면 헛점이 있기 마련입니다. 메소드의 파라미터와 리턴값에 대한 정보를 보고 Test Engineer가 그에 맞는 테스트 케이스를 설계해서 직접 테스트를 하던지, 아니면 개발자에게 넘겨서 Unit Test를 하는게 좋을 것 같습니다. Test Engineer 분이 프로그래밍에 대한 경험이 있다면 더욱더 쉽고 악랄하게 버그를 잡으실 수 있을겁니다. 저두 위의 분처럼 예를 들어봅니다. Test라는 클래스는 int GetFileCharNum(char* strFileName); 라는, txt 파일을 읽고 문서의 문자의 수를 리턴하는 메소드를 가지고 있다고 봅시다. 리턴값은 파일 내의 Char 개수이고, 파라미터는 파일 이름입니다. 이 메소드를 UnitTest한다고 한다면 많은 개발자는 잘 되는 파일 몇 개 읽어보고 잘 된다고 생각하고 PASS 할것입니다만, Test Engineer 는 그냥 넘어가지 않겠죠? : ) 테스트 케이스를 이런식으로 작성해주면... 1. 빈껍데기 파일 2. OS에서 지원하는 파일 이름 길이만큼의(윈도우즈는 아마 255자?) 긴 파일 이름을 가진 파일 3. 엄청나게 큰 파일 4. Unicode(UTF-8) 문자셋 파일 5. Unicode(UTF-16) 문자셋 파일 6. Unicode(UTF-32) 문자셋 파일 7. Unicode(UTF-4) 문자셋 파일 8. ASCII 문자셋 파일 9. Full Path 입력(c:\가나다라마바사\가나다\aaa.txt) 10. 엄청나게 긴 FullPath 입력 11. 깨진 파일 12. 잘못된 Path 입력 13. 없는 파일 이름 입력 14. 다른 형태의 파일 정보 입력(abc.doc) ... 뭐 이 밖에 요구사항에 따라 더 늘어나겠지만 일단 생각나는건 이정도... 이 TestCase하고 기대값을 던져주세요. 욕은 하겠지만 이 중에 걸리는게 꼭 있을겁니다. -.-;;
박정훈2
08-08-29 13:23
많이 배우고 갑니다.
path 관련해서 공백을 넣어 보는 테스트도 추가하면 좋을 것 같습니다.
"C:\이런 패스\space with path\path.path"
어플리케이션이 웹이 아닌 클라이언트 기반이라면 파일 헤더도 체크해 봤으면 싶습니다.
많이 배우고 갑니다. path 관련해서 공백을 넣어 보는 테스트도 추가하면 좋을 것 같습니다. "C:\이런 패스\space with path\path.path" 어플리케이션이 웹이 아닌 클라이언트 기반이라면 파일 헤더도 체크해 봤으면 싶습니다.
최일순
08-09-03 11:11
테스터가 유닛 테스팅까지 관여하기 어려운 이유....
제 주변의 QA 엔지니어나 테스트 엔지니어 중에서 개발자 수준으로 코드를 많이 만져보고, 만들어보고, 쉽게 읽을 수 있는 정도의 분들은 아주 소수에 불과합니다. 이것은 조직 관점에서 생산성의 문제죠. 테스터가 유닛 테스트 해도 됩니다. 스스로 주어진 시간 내에 결과를 낼 수 있다면 말이죠.
현실적으로 이 코드가 왜 이렇게 구성되어 있고, 어떤 부분을 처리하도록 의도되어 있는지는 동료 개발자들도 파악하는데 시간이 꽤 걸립니다. 하물며 실제 개발에 참여하지 않는 테스터가 그이상의 생산성을 낼 것으로 기대하기 어렵지요.
두번째는 유닛 테스트 자체가 테스트만 있는 것이 아니라, 테스트 <-> 코드 수정을 반복할 가능성이 높은데, 테스터들이 개입하게 되면 커뮤니케이션이 꽤 복잡해진다는 것입니다.
글로벌한 소프트웨어 회사들을 보면 대체로 System 테스팅 이후를 담당하는 QA팀(혹은 테스팅팀... 이름이 어쨌던)과 유닛 테스트 등 로우레벨 테스트를 담당하는 테스트 엔지니어가 따로 있더군요. 테스트 엔지니어는 개발자들과 같이 묶입니다.(코드를 제대로 이해하고 협업하려면 다른 선택이 어렵지요)
현실적으로 가능성이 있는 방법은 유닛 테스트는 개발자들이 하되, 유닛 테스트 종료 기준을 정하는 것이 될 것 같습니다. 코드 커버리지 같은 게 아주 유용하게 사용될 수 있겠지요. 커버리지 자체가 명확하게 증거가 남는 공식적인 테스팅 기법이기 때문에 결과에 대해서 이견은 없을 겁니다. 테스터들이 이 과정에 참여한다면 어떤 개발문서에도 없는 내부 구조나 동작에 대한 많은 정보를 얻을 수도 있을 겁니다.
테스터가 유닛 테스팅까지 관여하기 어려운 이유.... 제 주변의 QA 엔지니어나 테스트 엔지니어 중에서 개발자 수준으로 코드를 많이 만져보고, 만들어보고, 쉽게 읽을 수 있는 정도의 분들은 아주 소수에 불과합니다. 이것은 조직 관점에서 생산성의 문제죠. 테스터가 유닛 테스트 해도 됩니다. 스스로 주어진 시간 내에 결과를 낼 수 있다면 말이죠. 현실적으로 이 코드가 왜 이렇게 구성되어 있고, 어떤 부분을 처리하도록 의도되어 있는지는 동료 개발자들도 파악하는데 시간이 꽤 걸립니다. 하물며 실제 개발에 참여하지 않는 테스터가 그이상의 생산성을 낼 것으로 기대하기 어렵지요. 두번째는 유닛 테스트 자체가 테스트만 있는 것이 아니라, 테스트 <-> 코드 수정을 반복할 가능성이 높은데, 테스터들이 개입하게 되면 커뮤니케이션이 꽤 복잡해진다는 것입니다. 글로벌한 소프트웨어 회사들을 보면 대체로 System 테스팅 이후를 담당하는 QA팀(혹은 테스팅팀... 이름이 어쨌던)과 유닛 테스트 등 로우레벨 테스트를 담당하는 테스트 엔지니어가 따로 있더군요. 테스트 엔지니어는 개발자들과 같이 묶입니다.(코드를 제대로 이해하고 협업하려면 다른 선택이 어렵지요) 현실적으로 가능성이 있는 방법은 유닛 테스트는 개발자들이 하되, 유닛 테스트 종료 기준을 정하는 것이 될 것 같습니다. 코드 커버리지 같은 게 아주 유용하게 사용될 수 있겠지요. 커버리지 자체가 명확하게 증거가 남는 공식적인 테스팅 기법이기 때문에 결과에 대해서 이견은 없을 겁니다. 테스터들이 이 과정에 참여한다면 어떤 개발문서에도 없는 내부 구조나 동작에 대한 많은 정보를 얻을 수도 있을 겁니다.
김종서
08-09-03 17:21
유닛테스트는 범위가 살짝 좁은 경우의 API 테스트 같은거져..
API 테스트는 범위가 좀 넓은 경우의 유닛테스트 같은거져...
결국, 그게 그거져.. 개발자가 자신의 코드의 안정을 위해 몇몇의 테스트케이스만을 적용해서 이 정도면 내 코드가 원하는 일을 한다고 할수 있지~ 라는 목적으로 수행하는 것이 유닛테스트..
QA팀에서 가능한 모든 수단을 동원하여 코드의 Hole을 찾아내는 목적으로 수행하는 것이 API 테스트...
즉, QA팀에서도 한답니다.. 보통 개발자가 하는 정도보다 훨씬 더 많이 체계적으로 하져..
유닛테스트는 범위가 살짝 좁은 경우의 API 테스트 같은거져.. API 테스트는 범위가 좀 넓은 경우의 유닛테스트 같은거져... 결국, 그게 그거져.. 개발자가 자신의 코드의 안정을 위해 몇몇의 테스트케이스만을 적용해서 이 정도면 내 코드가 원하는 일을 한다고 할수 있지~ 라는 목적으로 수행하는 것이 유닛테스트.. QA팀에서 가능한 모든 수단을 동원하여 코드의 Hole을 찾아내는 목적으로 수행하는 것이 API 테스트... 즉, QA팀에서도 한답니다.. 보통 개발자가 하는 정도보다 훨씬 더 많이 체계적으로 하져..
sten
08-09-04 01:54
단위테스팅은 테스터가 할 수 있습니다.
하는 조직도 상당수 알려져 있고요...
일반적으로 아래의 2가지 방식으로 단위테스팅에 테스트 전문가가 참여하고 있습니다.
1. 개발경험이 풍부한 테스트 엔지니어가 단위 테스팅을 전담하여 진행함.
2. 테스트 엔지니어가 개발자와 협력하여 단위 테스팅을 진행함. 테스트 엔지니어는 화이트박스 테스트 설계 기법 등 테스팅 전문 지식을 제공하고 개발자가 이를 반영해 테스트 케이스를 생성한 후 수행함. 해당 테스트 케이스를 테스트 엔지니어가 검토해 줄 수 있음.
테스트 엔지니어가 개발 테스팅 가이드를 만들어 주는 경우도 있고,
기타 여러가지 형태로 테스트 엔지니어가 단위테스팅에 참여합니다.
일종의 최근의 추세이니, 테스트 엔지니어가 여러형태로 관심을 갖고 역량을 키우셔야 할 것입니다.
댓글 없음:
댓글 쓰기