프로젝트 특성에 따른 QA 전략방향

안녕하세요, 이번 포스팅은 프로젝트 특성에 따른 QA (Quality Assurance) 방향에 대한 내용입니다.  조직특성, 프로젝트 성격/ 기간, 자원에 따른 각각의 고려 요소에 대해 말씀 드리려고 합니다.

인터넷에서 이런 글을 본적이 있습니다.  — 체중 감량을 위해 노력하는 사람이 피자 가게에 피자 한 판을 이렇게 주문했다. 현재 체중 조절 중이므로 피자 한 판을 8 조각으로 자르지 말고 6조각으로 잘라달라고 했다. 6조각이나 8조각이나 피자 한 판의 량은 동일할 것이지만 체중을 조절하는 사람의 마음이 절실하게 느껴져서 웃을 수가 없었다. 분명한 것은 양이 작은 사람은 6조각 보다는 8조각으로 나누었을 때 양적으로 더 많이 먹을 확률이 높다. 8조각은 한 조각의 양이 작으므로 2조각 즉, 피자의 1/4을 먹을 확률이 높지만 6조각은 1/6만 먹을 확률이 높기 때문이다. —  테스트 조직에서 이 원리를 적용해보면 테스트함에 있어서 다루어질 내용에 대한 상세도에 따라 제품의 오류를 더 많이 찾을 수 있다는 것입니다. 이때 반드시 선행되어야 할 점은 어느 상황에서 어떠한 원칙을 적용할 것인가를 정하는 것인데요, 이 원칙을 어떤 기준에 따라 정의할 것인가를 논의하기 위해서는 프로젝트 수행 시 나타나는 주요 문제점이 무엇인지 점검해보는 것이 필요합니다.

일반적으로 이야기되는 문제점은 다음과 같습니다.

  • 잘못된 의사소통(miscommunication) 또는 의사소통의 부재(no communication)
  • 부실한 문서: 내용이 대략적으로만 기술된 문서, 현재 내용이 반영되지 않은 오래된 문서, 내용이 잘못 기술된 문서 등
  • 제품 요구 사항이 끊임없이 변경되는 것
  • 시간에 대한 압력: 실현 가능성이 부족하지만 무작정 몰아붙이는 개발 기간, 예외 상황을 처리할 버퍼 시간 없이 잡힌 개발 기간, 야근과 주말을 개발 기간에 포함시키는 것
  • 프로그램 오류

위의 문제는 모든 일상에서 나타날 수 있는 문제이지만 그 영향력은 조직 특성에 따라, 프로젝트 성격에 따라, 프로젝트 기간에 따라 그리고 자원의 한정된 상황에 따라 다양하고 강력하게 표출될 수 있습니다.

1. 조직특성
조직의 성숙도와 조직간 의사소통 내용에 대해 살펴보면 문제가 어디에서 나타나는지 짐작할 수 있을 것입니다. 조직 성숙도의 기준은 업무 단위로 구성원이 확보되어 있고 그 역할 및 책임에 대해 명확히 문서로 명시되어 있느냐는 것입니다.

기본적인 원칙은 상품 기획에서 제품 기획이 명확하게 선행되어야 하고, 이에 따라 개발 전제 공정을 관리하는 프로젝트 매니저가 프로젝트 리드를 할 수 있는 권한이 주어져야 합니다.  프로젝트 매니저는 각 팀의 의견 조정뿐만 아니라 프로젝트의 중요 사항에 대해 결정권을 행사할 수 있어야 하고, 제품의 UI 디자인은 개발팀이 아닌 가능하면 전문 디자이너에게 맡겨서 제품의 수준을 높여야 합니다. 동일한 성능의 제품일지라도 그 포장에 따라 얼마나 많은 차이를 가져오게 되는지 굳이 설명하지 않아도 이해할 수 있을 것입니다.

기술 문서 또한 문서 작성 전문가에 의해 쓰여지도록 하는 것이 좋습니다. 테스트 분야에 대해서는 크게 기능 테스트, 성능 테스트 그리고 기술 문서 검토로 나눌 수 있는데, 기능 테스트와 기술 문서 검토 작업은 동일한 인력이 수행할 수 있는 부분입니다. 그러나 성능 테스트의 경우 테스트 그룹 내 전문 인력을 양성하여 성능 시험 분야의 경험을 계속 축적하여 그 수준을 향상시키도록 하는 것이 좋습니다. 추후 팀원 전체를 성능 시험 할 수 있는 전문가로 키워도 되겠지만 일단 한 사람의 전문가를 제대로 만드는 것을 더 높은 우선 순위로 두어야 합니다. 영업이나 마케팅 팀에서는 기능 추가 요청 및 개발 기간에 대한 관심이 많은데,  언제 제품을 출시할 수 있느냐에 따라 영업 계획을 짜거나 고객과 협상하기 위한 기반을 마련할 수 있는 추가 기능이나 알려진 오류에 대한 협상안을 마련하기 위해서입니다. 이 경우 프로젝트 매니저의 역할이 중요한데, 고객의 요청이면 모두 받아들이기 보다는 경중을 가려서 해줄 수 있는 부분과 그렇지 못한 부분에 대해 판단을 하고, 프로젝트와 관련이 없는 부서의 개입을 최대한 차단할 수 있어야 합니다. 테스트 분야에 대해서는 많은 회사에서 테스트 그룹을 SQA나 SEPG 작업과 혼동하거나 규모가 작아 테스트 그룹에서 SQA와 SEPG 역할을 모두 수행해 주기를 바라는 경우가 많기 때문에 최소한 수용할 수 있는 작업을 정리하면 아래와 같습니다.

  • 테스터 본연의 역할
    • 기능 테스트
    • 성능 테스트
    • 사용자에게 전달될 문서 내용 검토
    • 테스트 환경을 구축하는 것 (회사에 따라 MIS 또는 개발팀의 역할로 규정할 수 있음)
  • SEPG 역할 중 일부
    • 테스트 프로세스를 수립하는 것
    • 버그 추적 프로세스를 수립하는 것
    • 테스트 프로세스를 향상시키기 위한 프로세스 및 테스트 방법론 개선
  • SQA 역할 중 일부
    • 테스트 케이스를 작성하는 것
    • 최종 버전의 제품을 평가하는 것
    • 버그 추적 시스템을 구축하는 것
  • 형상 관리(Configuration Management) 역할 중 일부
    • 최종 버전의 제품 산출물을 보관하는 것

테스트 그룹에게 주어진 프로젝트 기간이 여유가 있다면 위의 작업은 수용할 수 있겠지만 만일 여유가 없을 때에는 위의 [SEPG 역할 중] “테스트 프로세스를 향상시키기 위한 프로세스 및 테스트 방법론 개선” 부분은 수행하기가 어렵게 됩니다. 따라서 테스트 그룹에 의한 제품의 품질 수준을 높이고자 한다면 반드시 SEPG 또는 SQA 팀을 테스트 그룹과 별도로 분리하여 테스트 프로세스뿐만 아니라 개발팀의 프로세스를 관리하여 이미 수행한 제품 및 출시된 사이트 제품의 운영에 대한 피드백(feedback)을 받아 그 결과를 분석하여 가공한 후 차후 작업 개선을 위한 자료로 배포하는 등 제품의 품질을 지속적으로 향상 시킬 수 있는 제도를 정착시켜야 합니다. 지금까지 설명한 조직도의 중요한 점은 업무별 분류와 각 분야의 역할 정의라는 것입니다. 각자의 역할과 책임 범위를 명확하게 하면 의사 소통에서 나타나는 상호 책임 회피 및 결정권에 대한 핑퐁 현상은 줄어들 것입니다. 조직도가 정리되면 다음은 조직간 의사 소통 창구에 대해 고민해야 합니다. 조직 간에 모든 의사 소통을 전자메일로 처리하는 것은 기록을 남긴다는 의미에서 바람직한 사항이겠지만, 특정 목적에 필요한 작업에 대해서는 해당 작업을 보완할 수 있는 시스템으로 관리할 필요가 있습니다. 이 부분을 결정하기 위해서는 다음과 같은 질문을 던져보면 어떨까요?

  • 팀 간에 일어날 수 있는 작업 목록을 나열하고
  • 각 작업에서 핑퐁될 수 있는 횟수가 얼만큼 되는지 예상한 다음
  • 그것이 결정된 사항에 대해서 차후 재 사용이 될 수 있는 것인가?
  • 그것이 프로젝트 수행되는 동안 영향을 주는 사항인가?
  • 그것이 동일 제품에 대해 다음 버전에도 참조 자료가 될 수 있는 것인가?
  • 그것이 다른 사람에 의해 참조되어야 하는 사항인가?
  • 시스템 화가 가능한 것인가? 또는 지원하는 시스템을 쉽게 구축할 수 있는가?
  • 이 시스템을 유지하기 위해 필요한 인력과 예산이 수용할 만 한가?
  • 일관성 있는 의사 전달에 도움이 되는 표준 템플릿을 작성할 수 있는 사항인가?

위의 질문을 통해 쉽게 구축할 수 있는 시스템은 버그 추적 시스템이라 할 수 있는데요, 또한  좀 더 여유가 된다면 형상 관리 시스템과 변경 관리 시스템인데, 이것은 회사 사정에 따라 상용의 고가 제품을 쓸 수도 있겠지만 간단하게 주요 마일스톤(milestone) 단위로 관리할 수 있는 간단한 파일 서버나 웹 페이지 형식으로 구축해도 무방하다고 봅니다.

2. 프로젝트 성격
테스트 방법은 여러 가지로 분리할 수 있으나, 본 글에서는 패키지 제품과 SI 제품으로 나누어 기술하려고 합니다. 패키지 제품을 테스트함에 있어서 고민하게 되는 문제는 사용자가 어떤 환경에서 제품을 사용하며 일반 사용자의 기호 성향은 어떤 것 인지에 대한 것이고, SI 제품은 프로젝트 예산 및 개발 기간의 압력뿐만 아니라 서비스 오픈(launch) 직전까지 제품 요구 사항이 고객으로부터 끊임 없이 변경된다는 것입니다. 좀 더 자세히 각각의 프로젝트의 특징을 정리해보면 [표 1]과 같습니다.

표 1.  패키지 제품과 SI 제품 비교

제품 설계에서부터 QA 프로세스를 적용함으로써 얻을 수 있는 장점을 크게 세 가지로 정리하면 다음과 같습니다.이러한 제품의 특징에도 불구하고 QA 그룹에서 인력 및 시간적인 여유가 있다면 공통적으로 제품의 품질을 향상시키기 위해 채택되어야 할 부분은, 설계 단계부터 QA 인력을 프로젝트에 투입하는 것입니다.

  첫째, 비용과 시간을 절감할 수 있습니다. 제품 개발 초기에 어떤 문제를 발견하여 수정하는데 드는 노력 및 비용은 적지만, 그 잠재된 문제가 제품 개발 후반에 발견될수록 그 노력 및 비용과 그에 따른 또 다른 오류 생산 가능성(Side effect)은 급격히 커지게 됩니다. 이 부분은 개발이나 테스트 작업을 아웃소싱할 경우 또는 여러 팀이 커다란 프로젝트를 수행할 경우 더 심각합니다. 개발을 외주로 사용한 경우, 잘못된 디자인 혹은 문서에 정확히 언급되지 않은 디자인으로 개발이 완료되었을 때, 테스트 그룹에서 발견된 기능적인 오류나 일관성 문제가 지적되어 수정될 부분이 많아지게 됩니다. 만일 초기에 제품 개발 요구 사항에서 누락된 필요한 기능 및 디자인 부분이 미흡한 부분을 발견하여 해당 내용을 보완했다면, 이미 완료된 제품을 수정하기 위한 시간 및 비용이 절감되고 UI 테스트 시간이 절약되어 테스트의 범위 및 깊이가 향상될 수 있습니다. 만일 이러한 제품이 외주 테스트 업체에 의해 수행될 경우, 보고된 오류가 많거나 수정 사항이 많은 기능이 발견된 경우 계약된 기간을 연장해야 함으로서 추가 비용 발생이 많아질 수 있습니다. 보이는 구현기능만 테스트할 경우 잠재적인 문제의 발견은 더욱 어렵게 되는데, 이러한 문제는 프로젝트가 종료된 후에 비용과 노력이 급증할 수 밖에 만듭니다.

  • 출시 이후 수정 작업 시 추가되는 어려움
    • 서비스 open 이후 실 시스템에 접근하는 작업 시간의 한계
    • 로그 분석에 의존(자유로운 조작 어려움)
    • 예측 불가, 재현 난해
    • 비용부담: 교통비, 숙박비, 기타 지원비
    • Side effect 가능성 높음
  • Side effect를 가중시키는 요소
    • 시스템 복잡도가 증가할수록
    • 주요 모듈(Core module)이 변경될수록: DB table design, Network protocol design
    • 필요한 상세 정보가 기록되지 않은 문서

따라서 비용뿐만 아니라 제품의 품질 향상을 높이고자 한다면, 반드시 제품 설계부터 능력있는 중-고급 이상의 QA 또는 테스트 인력을 투입해야 합니다.

둘째, 사내 제품 개발의 표준을 수립하고 이를 개발에 적용될 수 있도록 사전에 요청할 수 있습니다. 개발의 표준이라는 용어에는 많은 것을 함축하고 있는데, 함수의 명명법(Naming rule), 작성되어야 할 문서, 출력 메시지 및 디자인 방식, 개발 프로세스, 테스트 빌드(Build Acceptance Test 단계)의 통과 기준 등이 포함될 수 있습니다.

셋째, 소스 코드의 신뢰성을 향상시킬 수 있습니다. 왜냐하면, 사전에 정의되지 않는 부분을 임의로 개발되었을 경우, 개발이 어느 정도 완성된 단계에서는 그 수정할 부분이 여러 부분에 퍼져 있어 그 량이 방대한 경우가 많아, 수정 과정에서 소스가 엉키거나 임시 방편적으로 소스를 수정해야 하는 경우가 발생합니다. 이 과정에서 또 다른 오류를 양성하거나, 제품 성능을 저하시키는 포장하기식 로직을 채택할 수 있습니다. 이 부분은 형상 관리로 관리한다고 하더라도 피해갈 수 없는 부분이므로, 사전에 제품 개발 지침서를 만들어 배포하여 미연에 방지할 수 있는 소스 수정 작업을 최소화해야 한다. 20%의 잘못된 소스가 시스템 성능에 80% 영향을 미친다는 점을 명심해야 합니다.

3. 프로젝트기간
본 장에서는 프로젝트를 수행 기간이나 내용에 대해 분류해 보고 테스트 관점에서 다루어야 할 주요작업에 대해 정리합니다. 이 모든 것은 개인적인 경험에 따른 분류 및 관점임을 다시 한 번 밝혀두는데요, 여기서 정리된 내용은 굳이 프로젝트 기간별로 분류된 것과 관계없이 전 부분에서 필요한 내용일 수 있지만 좀 더 비중 있게 다루어 지도록 분류한 것입니다.

표 2.  프로젝트 수행 기간별 분류

주요작업 및 고려할 점에서 중대형 프로젝트의 경우, 새로운 제품이거나 많은 부분이 변경되거나 새로운 기술이 도입되는 제품으로 많은 인력이 투입되는 특징을 갖는데요, 따라서 새로운 기술이나 제품에 대한 관련자 교육이 중요한 요소입니다. 그리고 자동화 테스트를 통해 어느 정도 제품의 형상이 나온 초기에 수행하여 지속적으로 반복되는 작업을 대체할 수 있어야 합니다. 그러나 이것으로 찾을 수 있는 오류는 적고 단지 반복적인 작업을 최소화한다는 의미가 큽니다. 테스터 투입 시기는 테스트가 수행되는 시간을 고려하여 잡은 최소한의 기준점입니다. 대형 프로젝트 경우 관련 팀간의 프로세스 설정과 사전 준비 작업이 많기 때문에 설계 초기부터 투입되는 것이 좋고, 중소형의 경우 최소한 유닛 테스트 단계부터 투입 함으로서 이미 작성된 개발자의 유닛 테스트 케이스를 바탕으로 테스트 케이스 작성을 시작해야 합니다. 그리고 오류 패치와 같은 개발 기간이 매우 짧고 기존의 테스트 케이스를 대부분 변경하지 않고 그대로 사용할 수 있는 경우에는, 테스터가 투입되는 시기는 제품 테스트 환경을 만드는데 소요되는 시간에 따라 그 기간이 달라집니다.프로젝트 기간은 개발 초기에 세운 계획에 대한 것이고 실제 수행이 완료된 시점에 대한 것은 배제되었습니다. 왜냐하면 개발 계획이 3개월 이였지만 실제 종료된 기간이 1년이 넘은 것도 있는데 이는 기술상의 어려움이 충분히 감안되지 못한 초기 계획의 오류이거나 관리 프로세스에 의한 문제인 경우가 많기 때문입니다. 또한 중대형 프로젝트는 투입 인력 수에 따라 더 상세히 분류될 수 있지만, 이 부분도 배제되었습니다.

여기서 설명된 분류 방법보다 테스트 리더에게 강조하고 싶은 것은 조직의 성숙도에 따라 기본적인 테스트 방법과 프로세스 원칙은 세워두되 어떤 상황에서도 반드시 모두 지킬 것이 아니라 상황에 따라 다양한 방법을 적용할 수 있어야 한다는 점인데요, 테스트 환경의 제약이나 테스트 데이터의 부족으로 인해 모든 경우를 테스트할 수 없기 때문에 테스트를 통해 모든 버그를 찾을 수는 없습니다. 따라서 비용이나 제품 출시 등과 같은 가치를 기준으로 상대적으로 중요도가 낮은 테스트 기법은 과감히 넘어가는 용기도 필요합니다.
그리고 제품 테스트가 완료된 후에는 공식적인 제품 완료 보고회 시간을 마련하여 마케팅, 영업 및 개발 등의 그룹과 함께 제품에 대한 품질 수준, 잘된 점 및 향후 보완할 점을 공유하는 것도 필요합니다. 이 발표회 전에 작성된 자료 내용에 대해서 개발 그룹과 최종 결함 논의 회의(Defect meeting)을 통해 협의하는 과정이 필요합니다.

4. 자원

  프로젝트 관리에 있어서 빼놓을 수 없는 자원은 인적, 물적, 프로세스, 예산이라고 봅니다. 본 글에서는 이 중에서 가장 중요한 인적 지원 측면에서만 살펴보도록 하겠습니다. 제품 품질은 테스터의 능력과 직결된다고 보며, 따라서 인적 자원은 꾸준히 중요하게 관리되어야 합니다.

세미나를 할 때 많이 받은 질문 중에 하나는 개발자 대비 테스트 인력을 얼마만큼 가져가야 하냐는 것입니다. 여러분들께서는 테스터와 개발자의 적절한 비율이 어느 정도 되어야 한다고 보시는지요? 개발자보다 많은 조직이 있는가 하면 개발자가 얼만큼 많음에 관계없이 2~4명으로 구성되는 조직도 있을 만큼 그 비율은 다양합니다. 이유는 제품의 복잡도나 시장성에 따라 다르기 때문입니다. 어떤 분야는 전혀 모르는 테스터가 수적으로 많이 투여되어야 하는 반면, 어떤 분야는 기술적으로 매우 깊이 있는 전문 테스터에 의해 수행되어야 할 분야도 있습니다. 따라서 인력 자원에 대한 계획을 할 때는 제품의 특성에 따라 테스터의 기술 수준을 고려하고, 그리고 그 수를 계산하는 것이 도움이 됩니다. 이러한 계획을 작성한 후 자체적으로 해결이 어려운 경우, 외주 인력 또는 임시직 고용을 결정해야 합니다.

제품 테스트에 투입될 테스터 인력을 배분함에 있어서 고려해야 부분을 몇 가지만 정리해보면 다음과 같습니다.

  • 기능의 중요도와 난이도에 따라 테스트 인력을 배분한다.
  • 아무리 사소한 프로젝트라도 반드시 2명 이상의 테스터로 구성해야 한다.
  • 테스트의 기본 원칙을 세우고 항상 테스터의 기술 향상을 위한 교육을 시킨다. 만일 교육해도 변화되지 않거나 기술이 향상되지 않는 테스터에게 하급 수준의 작업을 맡기고 교육을 멈추고 새로운 인력을 채용하는 것이 낫다. 그렇지 않을 경우, 그 사람이 작업하는 것은 매번 다시 한 번 누군가 확인해야 한다.
  • 테스트 환경 디자인은 고급 테스트가 담당한다. 시스템 디자인은 제품 요구 사항 문서를 기반으로 주어진 자료를 분석하여 재구성해야 하는 능력이 요구되기 때문이다.
  • 부하 시험은 중급 이상의 테스터에서 할당한다. 초급 테스터는 본인의 시험 방향에 있어서 무엇이 잘되고 또는 잘못되고 있는지 판단할 수 있는 시야가 제한되어 있기 때문에 초급 테스터에게 맡기는 것은 심각히 재고해야 한다.
  • 새로 합류한 테스터에게는 반드시 다음과 같은 과정을 거치도록 작업을 할당한다.
    • 반드시 직접 수행하여 눈으로 확인하여야 한다. 당연히 되겠지라는 추측으로 한 줄이라도 그냥 넘기지 않도록 거듭 당부해야 한다.
    • 회귀 테스트를 통해 어떤 오류가 보고되었고 어떻게 오류를 보고하는지에 대한 감각을 익히도록 한다.

지금까지 프로젝트에서 나타날 수 있는 문제점들의 영향력을 조직 특성에 따라, 프로젝트 성격에 따라, 프로젝트 기간에 따라 그리고 자원의 한정된 상황에 따라 분류하여 직/간접적으로 정리했습니다.

조직도 부분에서는 의사 소통(Communication)의 기본이 되는 팀의 작업 단위 분리와 각 작업 그룹의 역할 정의에 대해 언급했습니다. 그 이유는 역할에 대한 정의가 되어야 조직간 의사 소통 문제 및 누구와 무엇을 이야기할 것인지를 결정할 수 있기 때문입니다. 이 부분이 정리되면 의사 소통 방식, 지원 시스템 또는 표준 양식(template) 등을 담당 부서에서 구축하거나 규정된 문서를 만들어 배포하도록 요구할 수 있습니다.

프로젝트 성격 부분에서는 정확한 문서 작성의 중요성을 강조하였고, 가능한 한 초기 개발 계획 단계에서부터 전문 중급 이상의 테스터를 투입해야 하는 필요성에 대해 기술했습니다. 왜냐하면 테스트를 통해서 품질을 보장하는 것은 한계가 있기 때문입니다. 테스트는 현재 만들어진 제품을 대상으로 작업을 수행하기 때문에 이미 만들어진 제품의 본 바탕을 변형시키는 것은 매우 어렵기 때문입니다.

프로젝트 기간 부분에서는 테스터 투입 시기가 합리적이어야 함에 대해 기술했습니다. 개발뿐만 아니라 테스트 기간도 실현 가능하도록 계획되어야 합니다. 한국의 개발 환경에서 가장 어려운 부분은 바로 개발 기간이 충분하지 않다는 것인데, 개발 기간을 산정할 때 위험 관리(Risk management) 요소를 고려하여 개발 기간 중에 발생될 수 있는 돌발 상황에 대비한 작업 버퍼(buffer)시간을 마련해야 합니다.

그리고 마지막 자원 부분에서는 적절한 테스트를 위해 반드시 필요한 인력에 대해 언급했습니다. 여러 가지 외적 요인이 있지만 적절한 테스트를 위해서는 가장 중요한 것은 바로 인적 요소임은 아무리 강조해도 지나치지 않음을 강조하며, 이 글을 마치겠습니다.

박은영 QA팀

SK플래닛에서 QA 업무를 담당하고 있습니다.

공유하기