태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

Search results for '프로젝트/품질관리'

QA팀이 필요없다고?

2013.08.22 20:06 by 전규현


잠시 후 Google blogger로 이동됩니다.






최근에 평가 자리에서 만난 유망하다는 스타트업의 대표의 이야기이다.


회사의 조직구조를 보니 테스트를 하는 팀이 보이지 않았다. 그래서 "QA팀이 없는냐"고 물어보니 "우리회사의 개발자들은 실력이 뛰어나서 테스트가 필요없는 프로그램을 만든다"라는 답변을 들었다. 그리고 본인(CEO)은 개발자들을 믿는다고 한다. (다른 회사는 믿음이 부족해서 버그가 생기나? ^^)


좀더 자세히 물어보니 내부에는 테스트인력이 없고 테스트를 고객이 해주는 것이었다. 삼성등의 대기업이 주 고객인데 패치도 자주 나갈뿐더러 고객이 테스트담당자가 있어서 패치가 나올때마다 꼼꼼하게 테스트를 해준다는 것이다.


사실 이런 얘기 하나만 들어도 회사가 얼마나 형편없는지 알 수 있다. 당장은 동작하는 소프트웨어를 만들어 낼 수는 있지만 그 이상은 택도 없을 것이다.


겉으로는 유망한 스타트업이고 Global Service를 준비중이며, 대규모 IR을 진행하고 있다고 한다. 그래도 꽤 유망하다는 스타트업이 이런 정도의 수준이라니 실망스럽기 짝이 없다.


회사의 품질관리를 고객에게 맡긴다는 것도 우습고 고객이 비용을 들여서 테스트를 해준다는 것도 우습다. 고객은 확인하는 정도의 Acceptance Test라면 말이 되지만 이렇게 같이 개발하는 형태의 개발은 세계적으로 유래를 찾아보기 어려울 것 같다.


이런 형태가 가능한 것이 스펙도 불확실한 상태에서 개발을 하다보니 고객과 개발사가 같이 으쌰으쌰하면서 개발을 한다. 주먹구구의 대표적인 행태이다. 이러다 보니 제대로 기획된 제품이 만들어지기 보다는 고객 담당자 취향대로 개발이 되곤 한다.


필자의 경험에 의하면 많은 회사들이 이 회사와 크게 다르지 않다. 또한번 갈길이 멀고 넘어야 할 산이 많다는 것을 느낀다.



저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/품질관리

  1. "우리회사의 개발자들은 실력이 뛰어나서 테스트가 필요없는 프로그램을 만든다"
    뭔가 있어보이는 전형적인 개소리네요. ㅎㅎ
    고객이 테스트를 해준다니 조금 이해가 가지만, 고객이 할 테스트와 연구소내에서 할 테스트는 좀 구분이 되어야 겠죠.
    근데 저도 그런 형편없는 회사에 다니는 1인 이네요 ㅜ.ㅜ

  2. 그래서 우리 회사도 QA 뽑고 있습니다.. 좋은 글 감사 하하 :)

거의 다 만들었어요.

2013.02.27 23:49 by 전규현


잠시 후 Google blogger로 이동됩니다.







"거의 다 만들어서 2주후에 개발이 끝나요"


이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다.

개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다.


하지만 이런 대화는 여러 오해를 양산한다.


영업 담당자는 2주후면 고객에게 소프트웨어를 제공할 수 있는 것으로 착각하기도 하고, 경험이 좀 있는 관리자는 아직 충분히 안정적이지 않거나 테스트가 남아 있다는 것도 알기도 한다. 하지만 정확하게 언제 고객이 쓸 수 있는 제품이 나오는지는 알 수가 없다.


그래서 우리는 좀더 전문적으로 제대로된 용어를 사용해서 커뮤니케이션을 할 필요가 있다.


우선 개발 단계별로 정확한 용어를 사용하는 것이 필요하다.


"개발"이라는 말은 너무나 모호하다. 사실 스펙을 쓰는 일부터 유지보수 까지 모두 개발이다.

그래서 분석/설계/구현/테스트 등 단계별로 세분화된 단어를 쓰는 것이 좋다.


따라서 "개발이 끝나요"보다는 "구현이 끝나요"가 좋다.


그 다음에는 개발팀에서 만들어내는 버전이 어느 정도 수준인지 표현할 필요가 있다. 내부 테스트를 진행할 수 있는 수준인지 필드테스트를 할 수 있는 수준인지 알려줘야 한다.


일반적으로 이런 수준을 표시하는 용어는 많이들 들어봤겠지만, 알파/베타/RC 등이 있다.


알파버전이란 모든 기능의 구현이 완료되었고 버그는 많지만 Show stopper가 없는 수준을 말한다. 주변에서 "개발이 다 됐어요"라고 말할 때도 자세히 살펴보면 알파 수준도 안되는 경우 많다. 기능이 99% 완료 되었으면 알파가 아닌 것이다. 예를 들어 설치 프로그램은 아직 개발을 안했다던지 간단한 기능의 일부가 미 구현상태면 알파가 아닌 것이다. 


따라서, 미국이나 인도나 어디에서도 알파버전이라고 하면 이 수준으로 이해를 하면 된다. 


그리고 알파버전 테스트에서 발견된 버그를 대폭 수정해서 버그를 많이 줄인 버전을 베타버전이라고 한다. 베타버전은 내부테스트를 하기도 하고 고객을 대상으로 외부 테스트를 하기도 한다. 베타버전은 버그는 있지만 꽤 쓸만한 버전이다.


RC버전은 Release Candidate의 약자로 테스트를 해보고 출시를 결정할 후보 버전이다. 따라서 대부분의 경우 아주 안정적이다. 출시가 결정되면 바로 고객이 사용하는 버전이다. 물론 버그가 없는 것은 아니지만 충분히 안정적이다.


따라서 알파/베타/RC등의 용어를 적절하게 사용해서 개발팀에서 만들어낸 버전이 정확하게 어느 정도 수준인지 전달을 해야 한다.


"2주후에 개발이 끝나요"보다는 "2주후에 알파버전 구현이 끝나요"가 좋다.


좀더 자세히 말하면 "2주후 금요일 오후3시 정각에 알파버전 소스코드 프리즈가 있습니다."라고 하면 좀더 정확한 의미가 전달된다.

개발자들은 3시까지 모든 소스코드를 Commit해야 하고,

빌드팀은 3시가되면 소스코드를 내려받아서 빌드를 하고

테스트팀은 3시쯤 되면 알파테스트를 시작할 준비를 하고 기다리고 있을 것이다.


관리자나 경영자는 당연히 테스트 일정을 알고 있고 언제 출시 예정인지 알고 있다.

이슈관리시스템을 보고 있으면 거의 실시간으로 발견되는 버그와 고쳐지는 버그의 현황을 볼 수 있다. 


하지만 아직도 대부분의 개발 현장에서는 이런식으로 커뮤니케이션이 이루어지지 않고 있는 것이 현실이다. 


알파/베타 등의 용어를 들어봤거나 사용하고 있어도 그 의미를 정확하게 사용하지 않고 있는 경우가 많고 개발자와 영어/관리자/경영자가 그 의미를 똑같이 공유하고 있는 않다. 서로 다르게 생각하고 있으면 커뮤니케이션에 문제가 자주 생긴다.


세계적으로 표준으로 사용하는 용어들이니 표준에 맞게 사용하고 모든 직원이 똑같이 공유를 해야 한다.


그래야 좀더 합리적인 일정으로 개발이 진행된다. 



저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/품질관리

  1. Blog Icon
    염구나

    저부터라도 오늘부터 이런 세부적이고 명확한 커뮤니케이션을 해야겠군요. 좋은 글 감사합니다.

  2. 글의 취지는 공감하나, 글에서 쓰신 알파, 베타, RC의 정의도 올바르지 않아 보입니다.

    알파버전은 모든 기능의 구현이 완료된 것이 아니라, feature freeze를 하기 위한 테스트 버전입니다. 즉, 알파 버전 가지고 테스트를 한 후에야 feature freeze가 된다는 겁니다. 상황에 따라 crash가 있을 수도 있고, data loss도 있습니다.
    베타버전은 알파버전을 통한 테스트 후 feature freeze가 되고, feature complete을 한 후 수행하는 테스트입니다. 베타 테스트의 목적은 주로 feature들에 대한 usability 테스트입니다. 그래서 사용자의 피드백에 따라 반영하는 과정을 베타1, 베타2, .. 등 여러 번 거치기도 합니다.
    RC 버전은 Unknown Major Bug가 없는 상태(그에 따라 Known Bug는 있을 수 있음)이며, RC 버전을 통한 테스트를 거쳐 Code Complete을 하는 것을 목표로 합니다. RC1, RC2 등 여러개가 나오는 경우가 있는데, 베타와는 다르게 말 그대로 별도의 후보 Set을 말합니다. 숫자가 높다고 더 좋은 것도 아닌거죠. 이 경우 Known Major Bug를 workaround하기 위한 경우들이 대부분입니다. 회피할 버그의 종류나 workaround 방법이 달라지니 후보 set이 여러개 나오는 거죠.

    위키피디아에 있는 정의라도 잘 읽어보셨으면 합니다.
    http://en.wikipedia.org/wiki/Software_release_life_cycle

  3. 안녕하세요. 안재우님

    의견 감사합니다. 이런 정의를 모르고 썼겠습니까? ^^ 쉽게 풀어서 설명한 것이지요.
    제 책에서는 자세히 설명이 되어 있으니 참고를 하세요.
    릴리즈사이클에 대한 정의도 일반적으로 이렇게 정의를 하지만 회사마다 약간씩 다르기도 하고 실제 프로젝트에서는 이보다 훨씬 복잡한 상황들이 벌어지죠. 알파버전 이후에 기능을 추가하는 경우고 심심치 않게 발생합니다. 원칙에는 어긋나보이지만 그런 경우 회사마다 대처하는 방법이 다르죠. 백과사전에는 모든 답이 있지만 실제 경험을 해보지 않은 사람들은 백과사전을 보고 따라 할 수 있는 것은 아니죠. 그런 맥락으로 대부분의 독자의 눈높이에 맞추고 있다고 생각하시면 되겠습니다.

    대부분의 회사가 이런 단계별 테스트를 하지도 않고 있기 때문에 왜 복잡하게 설명하지 않고 일관된 커뮤니케이션 한 주제에 대해서만 간단하게 설명하고 있는지 이해를 하실 수 있을 겁니다.

  4. 알파버전에는 crash가 있을 수는 있지만 Show stopper가 있어서는 안되는데 그 정의는 빠져있군요. :)

  5. 글쎄요, 쉽게 풀어서 설명하는 것과 각 단계를 구분하는 핵심이 설명되지 않은 것은 좀 다르다고 봅니다. 대부분의 사람들이 알파, 베타, RC 간의 차이가 그냥 버그가 더 적고 안정화되는 것이라고만 알고 있습니다. 그러다 보니, 개발팀에서 제멋대로 갖다 붙이는 경우가 많습니다. 하지만 알파/베타/RC라는 명칭은 원래 개발팀에서 임의로 붙일 수 있는 것이 아니지요.

    항상 베타가 알파보다 버그가 적지도 않습니다. 물론 알파 테스트를 거쳤기에 적을 수도 있지요. 하지만 Feature 변동이 있기에 베타가 오히려 버그가 더 많을 수도 있습니다. 그리고 Known Bug가 아닌 항목들이 베타에서 등장하기도 하지요.

    그리고, 답글을 주신 내용을 보면 이상한 항목이 있는데요,
    '알파 버전 이후에 기능을 추가하는 경우는 심심치 않게 발생합니다. 원칙에는 어긋나 보이지만'이라고 하셨는데, 원칙에 어긋나지 않습니다. 알파 버전의 '개발'이 아닌 '테스트' 이후에야 Feature Freeze가 일어날 수 있으니까요. 테스트도 안해보고 사용자의 피드백도 들은 적이 없는데, 알파 버전이 모든 기능 구현이 완료된 버전이 될 수 없지 않을까요?

    백과사전, 이론, 원칙대로 현실에 모두 반영할 수 없는 것은 맞는데, 이론과 원칙을 잘못 알고 있으면서 현실만을 얘기하는 것도 위험하지요.
    예를 들어, 어떤 프로젝트의 개발팀장이 이 글을 읽고 알파 버전에선 기능 구현이 이미 끝나서 버그 고치는거 빼고 일체 기능 추가나 변경은 못한다라고 주장하면 어떻게 될까요? 사실 알파 단계에서 이렇게 한다는 건 고객의 피드백을 별 그다지 들을 생각이 없는 경우입니다. 프로젝트는 일정 내에 끝낼 수 있을지 몰라도, 고객에게 좋은 평가를 듣거나 시장에서 크게 성공할 가능성이 거의 없다고 봐야죠.

  6. 안녕하세요. 안재우님

    제가 원래 이런 토론을 아주 좋아하지만 이상하게 말꼬리를 잡고 늘어지는 형태로 얘기를 하시는 것 같아서 조심하게 되는군요. "원칙에 어긋나 보이지만"이란 말도 과도하게 해석해서 부풀리는 것 같습니다. 또, 첫번째 댓글에 약간 빈정대는 투가 있기는 하지만 그대로 이해하겠습니다.

    기본적으로 안재우님의 주장은 다 공감합니다. 친절하게 쓰셨으면 더욱 공감했을 겁니다. ^^ 제 독자들도 이런 말꼬리에 회사에서 억지 주장을 하지 않을 거라고 믿고 있습니다. 많은 독자들은 제가 쓴 "소프트웨어 개발의 모든 것"을 읽었거나 오랫동안 블로그를 구독하고 있어서 말꼬리 하나하나 보다는 전체적인 맥락에 공감을 합니다.

    소프트웨어 개발의 큰 원리는 같으나 회사마다 다른 것들도 많아서 하나의 주장만 맞다고 하면 문제가 되는 경우가 있습니다.

    알파버전에 관한 것도 큰 맥락은 같으나 용어와 정책들도 서로 다릅니다. 헌법은 아니죠. Feature freeze라고 하는 곳도 있고, 알파버전에 Spec을 close하는 회사도 있습니다. 고객의 피드백을 알파 이후에 하는 회사도 있고 개발단계에서 Mock up을 가지고 미리 하는 회사도 있습니다. 사실 현실에서는 이보다 100배 더 복잡합니다. 이런 것에 대한 원리를 설명한 글은 안재우님의 참고로 들으신 Wikipedia글이 더 잘 대표를 한 것 같습니다. 그렇다고 제가 항상 Wikipedia를 배낄 필요는 없다고 생각합니다. 20년부터 알파, 베타를 비롯해서 소프트웨어 공학을 사용했고, 미국 실리콘밸래의 회사와도 같은 방식으로 일을 했고 이론과 경험은 충분하다고 생각합니다.

    건설적인 주장과 토론은 환영합니다. 가끔 이런 반응에 대한 우려로 글을 쓸 때도 좀더 신중하게 정리를 해서 쓰고 싶기는 하지만 저도 시간이 그렇게 많은 편이 아니라서 후다닥 글을 쓰는 형태를 바꾸기는 어렵겠네요. ^^

    아무튼 적극적인 반응 감사합니다.

  7. 베타단계에서 사용자의 피드백을 받아서 베타1, 베타2 등을 만들어 내는 것은 안재우님의 경험을 말씀하신 것이 아닌가 생각합니다.
    그럼 베타단계에서 사용자의 의견에 따라서 스펙이 바뀐다는 얘기인데 어쩔 수 없이 그렇게 해야 하는 소프트웨어도 있기는 하지만 스펙을 베타단계에서 바꾸는 것은 많은 비용을 지불해야 하기 때문에 애초에 스펙단계부터 변경을 최소화하기 위해서 잘 작성하는 것이 일반적이라고 볼 수 있습니다.

    소프트웨어 개발 방법론(or 라이프사이클)에는 여러가지가 있기 때문에 베타테스트에서 사용자의 피드백을 반영해서 계속 바꾼다는 것이 틀렸다고 말하고 싶지는 않습니다.

    우리나라의 많은 회사들이 그런 식으로 소프트웨어를 개발하고 있고 그럼으로 인해서 많은 비용을 지불하고 있습니다. 우리나라에서는 흔히 고객은 실제 동작하는 소프트웨어를 보여주기 전에는 피드백을 줄 수 없다고 합니다. 많은 비효율이 여기서 출발합니다.

    제가 많은 대기업, 중견기업를 포함해서 중소소프트웨어 회사에서 요구공학을 가르치고 스펙 작성을 도와줬는데 제대로 스펙을 작성할 수 있는 엔지니어는 2~3%도 안되는 것이 현실이죠. 그래서 이같은 현상이 어쩔 수 없이 벌어집니다. 스펙을 제대로 작성하면 이후 발생하는 변경이 최소화되죠. 방법론에 따라서 스펙 작성방법이 다르기 때문에 꼭 어떻게 작성해야 한다고 주장하지는 않습니다. 하지만 스펙 작성 역량도 없이 이런 저런 방법론만 주장하는 사람들도 많기는 합니다.

    아무는 저는 소프트웨어를 보여주기 전에 스펙단계에서 고객의 요구사항을 충분히 반영할 수 있도록 교육을 하고 있습니다.

    RC 버전은 Unknown Major Bug가 없는 상태라는 것은 발견하지 못한 Major bug가 없다는 얘기인데 이것은 불가능한 것 같습니다. Unknown한 것은 있는지 없는지는 알 방법이 없습니다. 또한 RC는 후보군이기 때문에 Major Bug가 있을 수 있는데 회사에 따라서는 Major bug가 있으면 Release가 허용이 안되는 회사도 있습니다. 또한 한국에서는 많은 회사들이 Critical,Major,Minor,Trivial,Showstopper 등 버그의 숫자만 보고 결정하는 프로세스를 만들려고 하는데 버그의 숫자만 가지고는 판단하기 어렵기 때문에 Go-live회의를 통해서 Release여부를 결정합니다. 실패시 RC2를 만들어 내기도 합니다.

    저는 소프트웨어 공학은 실전이라고 생각합니다. 이론을 잘아는 소프트웨어 공학 교수님들이 소프트웨어는 제대로 개발을 못하는 이유입니다. 따라서 저는 다른사람들의 실전적인 방법에 대해서 비난을 하지는 않습니다. 단지 컨설턴트로서 좀더 좋은 방향으로 개선을 해줍니다. 그렇다고 제가 소프트웨어 공학 이론을 모르는 것은 아니죠. 처음부터 이론을 먼저 공부한 것은 아니고 20년 실전을 해오다 보니 이론을 접할 기회가 많아서 익히게 된 것이죠. 그렇게 쌓이면 원리를 깨우쳐서 이론에서 주장하는 문구 하나하나에 집착하지 않은 상태가 됩니다. 저는 몇몇 분야에서는 원리를 깨우친 상태라고 할 수 있습니다. 그래도 여러 회사의 상황들은 제게 많은 도움이 됩니다.

    앞으로 건설적인 토론이 계속 되면 좋겠습니다.

  8. 안녕하세요. 처음 댓글에서 밝혔듯이 저는 기본적인 글의 취지 자체에는 공감하고 있습니다. 다만 Consensus를 형성하기 위한 전제가 되는 '용어의 정확한 의미를 이해하고 사용'이라는 측면에서의 문제를 지적한 것입니다. 예로 드신 용어가 보편적인 정의와 일치하는 것이라면 제가 애초에 댓글을 달 이유도 없었겠지요.
    계속 말씀하시는 것은 용어에 대한 정의가 '상황에 따라 다르다', '회사에 따라 다르다'라는 건 결국 '개인에 따라서도 달라질 수도 있다'라는 건데, 원 글의 취지와 모순되어 보인다는 생각이 듭니다. 하지만 엄밀히 말하면 정의가 다른게 아니라, 해석과 적용이 다른 것일뿐이 겠지요.

    토론의 정의는 '각각 다른 의견을 말하면서 논하는 것'인데, 의견이 같아 공감하는 부분은 이미 얘기했고, 다른 의견에 대해 논하는 것을 원치 않으신듯 하니 저 역시 더 이상 토론을 진행할 것이 없을 것 같습니다. 그에 따라 '원래 정의가 뭐라고 되어 있든, 최소한 조직 내에서는 동일한 것으로만 맞추면 된다' 정도가 원래 글의 취지였다고 이해하도록 하겠습니다. 그럼 이만..

고쳤으니 테스트 해주세요.

2013.02.18 10:13 by 전규현


잠시 후 Google blogger로 이동됩니다.







여기 두가지 테스트 방법이 있다. 우리 회사는 어떤 방법을 사용하고 있나 생각해보자.


첫째, 테스트 도중에 버그를 고쳐서 좀더 안정된 버전을 테스트팀에 계속 전달하는 방식이다.

테스트 한사이클을 도는데 2주일이 걸린다고 생각해보자. 테스트 기간내내 테스트 팀은 버그를 지속적으로 발견하여 보고를 할 것이다. 개발팀은 동시에 버그를 수정한다. 그리고 다음날 개발팀은 테스트팀이 보고한 버그를 많이 수정한 새버전을 테스트팀에 전달한다. 


테스트 팀은 새버전을 가지고 어제 테스트한 시점의 다음 단계부터 또 테스트를 진행한다. 이렇게 테스트 기간 내내 여러번 새버전을 받는다.


두번째 방법은 다음과 같다. 테스트가 2주가 걸리면 2주 동안 테스트 팀은 새버전을 절대로 받지 않고 한 버전을 가지고 테스트를 완전히 종료한다. 개발팀은 버그를 계속 고치지만 새 버전을 테스트 팀에 전달하지 않는다.


어느 방법이 더 효율적으로 보이는가? 많은 회사들이 첫번째 방법을 사용하고 있다. 믿기 어렵겠지만 사실이다. 첫번째 방법은 큰 문제가 있다. 테스트 기간 도중에 테스트 팀이 새로운 버전을 받으면 이전에 테스트 한 내용이 무효가 된다. 여기서는 그걸 무시하고 계속 테스트를 했기 때문에 테스트가 끝나도 끝난 것이 아니다.


그럼에도 첫번째 방법을 사용하는 이유는 있다. 도저히 테스트 할 수 없을 만큼 불안정한 제품을 테스트 해달라고 전달한 경우이다. 그래서 테스트 팀과 적당히 테스트를 하면서 차츰 안정화를 시켜가는 것이다. 이런 품질의 제품은 테스트를 할 필요가 없다. 이 경우는 테스트 팀을 개발팀의 딱까리로 생각하는 것이다. 


원래 테스트를 진행할 수 없을 정도의 제품을 테스트팀이 받으면 테스트를 중단하고 개발팀으로 다시 돌려보내야 한다.


이렇게 비효율적인 테스트가 우리 주변에서 흔히 벌어지는 이유의 원인 따지고 들어가면 앞단계인 분석과 설계가 엉망이거나 없기 때문인 경우가 많다. 


제품의 품질을 유지하기 위해서는 분석/설계도 중요하고 전문적인 테스트를 해야 한다. 대충 개발하고 테스트팀이 개발팀을 도와주는 형태로는 평생 주먹구구식 개발에서 못벗어나고 비용과 시간도 많이 들뿐만 아니라 개발팀은 잦은 야근에서 벗어나기도 어렵다.


앞으로 테스트에 관한 얘기를 좀더 쉽게 풀어서 써보도록 하겠다.


image by cseward

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/품질관리

  1. 아직 댓글이 없네요.
    일등...

    테스트에 대한 글들을 많이 기다리고 있겠습니다.

  2. 안녕하세요, 자주 블로그글을 유용히 읽고 있는 독자중에 하나입니다.
    개발자가 만든 코드의 테스트를 결국 누가 하는가인것 같습니다만,
    [우리는 개발자가 테스트해요..] 라는 글과 상충되는 느낌을 받았습니다.
    개발자가 유닛테스트를 자동화해서 거치더라도 결국엔 누군가는 사람이 테스트를 해봐야 할텐데요,
    그것이 테스트부서나 팀내 테스트인원이 아니면 누가 해야할련지요?
    (결국 팀내 테스트인원이라면 팀내 테스트인원은 개발자의 딱까리(본문의 표현;;)가 될것같습니다.. ㅠ)

  3. 안녕하세요. 저도 기억이 잘 안나서 옛날 글을 읽어봤는데 어느 부분이 상충되는지 발견을 못했습니다. 좀더 자세히 찝어주시면 제가 아는한 자세히 설명드리겠습니다.
    과거의 글은 테스트팀이 없어서 발생하는 문제를 지적했고, 이 글은 테스트 프로세스 중 문제가 되는 경우를 설명했습니다.
    질문하신 내용의 요지는 테스트인원을 어디에 두느냐인 것 같습니다.
    여러 경우를 많이 봤지만 테스트인원이 개발팀내에서 개발팀장의 지휘를 받는 경우를 종종 봤습니다. 항상 그런 것은 아니지만 개발자의 딱까리가 되는 경우가 많더군요.
    그래서 테스트팀은 별도의 팀이나 부서로 두는 경우가 많습니다. 물론 순수 SW인가? HW에 탑재하는 Firmware인가에 따라서 약간씩은 효율적인 테스트 조직이 다르기 때문에 상황에 따라서 잘 판단해야하지만 테스트팀은 전문성을 발휘할 수 있도록 조직적인 배치를 하는 것이 좋습니다.

  4. 관계자들이 깊이있게 곱씹을만한 글이네요.
    저도 예전에 테스트 업무만 맡은 적이 있어서요.
    그때도 QA부서가 제품의 출시 권한이 있어야 한다는 화두가 있었지만 실제적인 권한은 미미했지요.
    저도 개발자이지만 아직 기본적인 문제에서도 버그가 발생하는 것에 부끄러움을 느끼지 못하는 개발자들이 있었죠. 자기 프로그램은 자기 얼굴과도 같다고 생각합니다.

우리는 개발자가 테스트해요.

2009.01.28 16:04 by 전규현


잠시 후 Google blogger로 이동됩니다.




주변의 소프트웨어 회사들을 보면 개발자가 테스트를 하는 회사를 정말로 많이 접하게 됩니다.
물론 개발자도 구현을 하면서 Unit테스트는 일상적으로 하지만, 제품의 기능이 정상적으로 동작하는지 확인하는 시스템 테스트도 개발자가 테스트하는 것을 보는 것은 그리 어려운 일이 아닙니다. 오히려 전문 테스트 인력이나 테스트팀이 있는 회사를 보는 것이 더 어렵습니다. 있다고 하더라도, 테스트팀이 전문적으로 테스트를 수행한다기 보다 개발자의 손을 좀 덜어주는 경우가 흔합니다.

이렇게 개발자가 테스트를 하는 이유는 다양하지만 다음과 같은 것들이 있습니다.
  • 우리는 인력이 너무 적어서 테스터를 별도로 둘 수 없어요.
  • 프로젝트 기간이 너무 짧아서 별도의 테스트 단계를 둬서 테스트를 할 수 없어요.
  • 개발자만이 기능을 속속들이 알아서 테스트를 할 수 있고, 이것을 테스터에게 알려줄 시간이 없어요. 그렇게 하면 중복 낭비예요.
  • 사람들이 테스터를 하기 싫어해서 전부 개발하고 같이 테스트 해요. 테스터는 뽑기도 어렵고, 기존의 개발자중에서 자원자가 없어요.
  • 테스터를 왜 별도로 둬야 하죠원래 개발자가 해도 되는 거 아닌가요?

개발자가 테스트를 하게 될 경우 아래와 같은 큰 문제가 있습니다.
  • 개발자는 제품의 내부 동작 방식을 속속들이 알기 때문에 자신도 모르게 정상적으로 동작하는 방식으로면 테스트를 하려고 합니다.
  • 개발자는 일반 사용자와 비슷한 패턴으로 제품을 사용하지 못합니다.
  • 개발자는 테스트의 전문성이 없기 때문에 테스트를 잘 하지도 못합니다.
  • 체계화된 테스트를 못하기 때문에 테스터를 더 투입하여 테스트 기간을 줄이는 등의 전략은 꿈도 못 꿉니다.
  • 테스트는 항상 대충 이루어지면 나중에 사용자가 버그를 많이 발견합니다.
  • 회귀(Regression)테스트는 무시되면 적당히 수정한 것만 테스트 하여 고쳤던 버그가 다시 살아나기도 합니다.
  • 개발자는 테스터보다 연봉을 더 줘야 하는데, 잘하지도 못하는 테스트를 시키느라고 비싼 돈을 낭비합니다.
  • 테스트 자동화 등의 테스트에 대한 전문적인 연구 및 개선이 이루어지지 않습니다.

한마디로 비싼 돈 주고 개발자는 개발자대로 고생하고 제품의 품질은 떨어지는 겁니다.

설령 1명짜리 회사라고 하더라도, 테스트는 제대로 해야 합니다. 그리고 개발자가 3,4명만 되어도 별도의 테스트를 두는 것이 효율적입니다. 예외적으로 특수한 프로젝트라면 모를까 일반적으로 별도의 테스트를 두는 것이 더 빠르고 적은 비용으로 높은 품질의 소프트웨어를 만드는 한 방법입니다.

물론 무조건 별도의 테스트팀을 두기만 하면 위 문제들이 해결되는 것은 아닙니다. 잘 해야죠. 추가적인 얘기는 다음에 하기로 하죠.

이미지출처 : Microsoft Office Online

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/품질관리

  1. 맞는 말씀이십니다.
    하지만 다음 이야기가 어떤 내용일지는 모르겠으나 QA 파트의 능력 또한 상당히 중요합니다.
    테스트 프로세스도 마찬가지구요. 뭐 이런 내용이 나올듯 한데^^! 기대하겠습니다~!!

  2. 돌이아빠님 안녕하세요.
    QA파트는 개발 파트 중에서 가장 먼저 전문화된 중요한 영역이죠. 워낙 넓은 범위라서 조금씩 써나갈려고 합니다.

  3. 보통 현업운영자 중에서 선발해서 테스트 그룹을 만들기도 합니다. 하지만 위의 글처럼 개발자들이 테스트 그룹을 제대로 활용하지(?) 못하는 경우가 허다하죠.

    그리고 테스트 그룹에서 발견된 문제점들을 수정하고 제대로 된 회귀테스트를 수행하지 않는 경우가 대부분인 듯 합니다. 테스트 그룹 또한 형식적인 테스트를 하는 경우가 다반사이구요.

    제가 경험해본 바로는 그 이유가 테스트 조직의 구성시기에 문제가 있었던 듯 싶더군요. 테스트 조직이 프로젝트의 단위테스트 완료 직후 급조해서 구성되다보니 테스트 조직이나 개발자 조직 모두 준비없이 구색만 갖추기 위한 프로세스가 되어버리더군요.

  4. 필넷님 안녕하세요.
    좋은 의견 감사합니다.

  5. 완전 공감이 되는 내용입니다.. ^^;;;;;
    저도 앞으로 나올 다음이야기가 궁금해지는군요~

  6. kkommy님 안녕하세요.
    테스트에 대해서는 워낙 내용이 많아서 차근차근 풀어나가 볼 예정입니다.

  7. Blog Icon
    박대우

    안녕하세요. 개발자들이 테스트하면서 놓치는게 회귀테스트 같더군요. 작업프로세스에서 어느 한부분의 버그를 수정하면 다른 곳에 또다른 버그가 발생하더라고요. 개발자는 자기 고친 부분만 테스트하기 때문에 다른 곳에 버그가 발생하는지 몰라서 패치 후 혹은 릴리즈 후에 문제가 발생하는 경우가 있기도 합니다. 하여간에 전문 테스터를 둬서 어떻게 테스트를 잘할지 연구하는 것이 중요할 것 같습니다.

  8. 박대우님 안녕하세요.
    회귀테스트는 테스트의 기본 원칙이죠. 모든 경우에 전 테스트 케이스를 다 테스트 할 수는 없지만 원칙을 알고 상황에 따라서 응용을 하는 것과 원칙을 무시하는 것과는 큰 차이가 있습니다.

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..