우리는 개발자가 테스트해요.
2009/01/28 16:04 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
RSS Feed
주변의 소프트웨어 회사들을 보면 개발자가 테스트를 하는 회사를 정말로 많이 접하게 됩니다.
물론 개발자도 구현을 하면서 Unit테스트는 일상적으로 하지만, 제품의 기능이 정상적으로 동작하는지 확인하는 시스템 테스트도 개발자가 테스트하는 것을 보는 것은 그리 어려운 일이 아닙니다. 오히려 전문 테스트 인력이나 테스트팀이 있는 회사를 보는 것이 더 어렵습니다. 있다고 하더라도, 테스트팀이 전문적으로 테스트를 수행한다기 보다 개발자의 손을 좀 덜어주는 경우가 흔합니다.
이렇게 개발자가 테스트를 하는 이유는 다양하지만 다음과 같은 것들이 있습니다.
- 우리는 인력이 너무 적어서 테스터를 별도로 둘 수 없어요.
- 프로젝트 기간이 너무 짧아서 별도의 테스트 단계를 둬서 테스트를 할 수 없어요.
- 개발자만이 기능을 속속들이 알아서 테스트를 할 수 있고, 이것을 테스터에게 알려줄 시간이 없어요. 그렇게 하면 중복 낭비예요.
- 사람들이 테스터를 하기 싫어해서 전부 개발하고 같이 테스트 해요. 테스터는 뽑기도 어렵고, 기존의 개발자중에서 자원자가 없어요.
- 테스터를 왜 별도로 둬야 하죠원래 개발자가 해도 되는 거 아닌가요?
개발자가 테스트를 하게 될 경우 아래와 같은 큰 문제가 있습니다.
- 개발자는 제품의 내부 동작 방식을 속속들이 알기 때문에 자신도 모르게 정상적으로 동작하는 방식으로면 테스트를 하려고 합니다.
- 개발자는 일반 사용자와 비슷한 패턴으로 제품을 사용하지 못합니다.
- 개발자는 테스트의 전문성이 없기 때문에 테스트를 잘 하지도 못합니다.
- 체계화된 테스트를 못하기 때문에 테스터를 더 투입하여 테스트 기간을 줄이는 등의 전략은 꿈도 못 꿉니다.
- 테스트는 항상 대충 이루어지면 나중에 사용자가 버그를 많이 발견합니다.
- 회귀(Regression)테스트는 무시되면 적당히 수정한 것만 테스트 하여 고쳤던 버그가 다시 살아나기도 합니다.
- 개발자는 테스터보다 연봉을 더 줘야 하는데, 잘하지도 못하는 테스트를 시키느라고 비싼 돈을 낭비합니다.
- 테스트 자동화 등의 테스트에 대한 전문적인 연구 및 개선이 이루어지지 않습니다.
한마디로 비싼 돈 주고 개발자는 개발자대로 고생하고 제품의 품질은 떨어지는 겁니다.
설령 1명짜리 회사라고 하더라도, 테스트는 제대로 해야 합니다. 그리고 개발자가 3,4명만 되어도 별도의 테스트를 두는 것이 효율적입니다. 예외적으로 특수한 프로젝트라면 모를까 일반적으로 별도의 테스트를 두는 것이 더 빠르고 적은 비용으로 높은 품질의 소프트웨어를 만드는 한 방법입니다.
물론 무조건 별도의 테스트팀을 두기만 하면 위 문제들이 해결되는 것은 아닙니다. 잘 해야죠. 추가적인 얘기는 다음에 하기로 하죠.
이미지출처 : Microsoft Office Online
'프로젝트 > 품질관리' 카테고리의 다른 글
| 우리는 개발자가 테스트해요. (8) | 2009/01/28 |
|---|
Trackback Address: http://allofsoftware.net/trackback/60
-
2009/01/29 02:19DW 칼럼 "개발 일정을 줄이는 방법-테스팅"을 더 잘 이해하기 위한 조언 Tracked from Younghoe.Info
-
2009/01/29 08:12소프트웨어 테스트(Software Test), 테스팅기법 Tracked from 필넷의 IT 이야기
-
2009/01/29 14:19테스트팀을 두는 이유. Tracked from 상실의시대
-
2010/01/06 10:49낡은 코드(legacy code)를 어떻게 테스트 하시나요? Tracked from 청하는 개발자
맞는 말씀이십니다.
하지만 다음 이야기가 어떤 내용일지는 모르겠으나 QA 파트의 능력 또한 상당히 중요합니다.
테스트 프로세스도 마찬가지구요. 뭐 이런 내용이 나올듯 한데^^! 기대하겠습니다~!!
돌이아빠님 안녕하세요.
QA파트는 개발 파트 중에서 가장 먼저 전문화된 중요한 영역이죠. 워낙 넓은 범위라서 조금씩 써나갈려고 합니다.
보통 현업운영자 중에서 선발해서 테스트 그룹을 만들기도 합니다. 하지만 위의 글처럼 개발자들이 테스트 그룹을 제대로 활용하지(?) 못하는 경우가 허다하죠.
그리고 테스트 그룹에서 발견된 문제점들을 수정하고 제대로 된 회귀테스트를 수행하지 않는 경우가 대부분인 듯 합니다. 테스트 그룹 또한 형식적인 테스트를 하는 경우가 다반사이구요.
제가 경험해본 바로는 그 이유가 테스트 조직의 구성시기에 문제가 있었던 듯 싶더군요. 테스트 조직이 프로젝트의 단위테스트 완료 직후 급조해서 구성되다보니 테스트 조직이나 개발자 조직 모두 준비없이 구색만 갖추기 위한 프로세스가 되어버리더군요.
필넷님 안녕하세요.
좋은 의견 감사합니다.
완전 공감이 되는 내용입니다.. ^^;;;;;
저도 앞으로 나올 다음이야기가 궁금해지는군요~
kkommy님 안녕하세요.
테스트에 대해서는 워낙 내용이 많아서 차근차근 풀어나가 볼 예정입니다.
안녕하세요. 개발자들이 테스트하면서 놓치는게 회귀테스트 같더군요. 작업프로세스에서 어느 한부분의 버그를 수정하면 다른 곳에 또다른 버그가 발생하더라고요. 개발자는 자기 고친 부분만 테스트하기 때문에 다른 곳에 버그가 발생하는지 몰라서 패치 후 혹은 릴리즈 후에 문제가 발생하는 경우가 있기도 합니다. 하여간에 전문 테스터를 둬서 어떻게 테스트를 잘할지 연구하는 것이 중요할 것 같습니다.
박대우님 안녕하세요.
회귀테스트는 테스트의 기본 원칙이죠. 모든 경우에 전 테스트 케이스를 다 테스트 할 수는 없지만 원칙을 알고 상황에 따라서 응용을 하는 것과 원칙을 무시하는 것과는 큰 차이가 있습니다.