X
STEN 회원이 되시면 테스팅에 관한 많은 정보와 자료를 공유할 수 있도록 저희가 돕겠습니다.
아이디
패스워드
자동로그인 사용
 
아직 회원이 아니십니까?    
아이디/패스워드를 잊으셨습니까?    

   
[완전 업데이트!] PM이 알아야할 SW 테스팅
글쓴이 : Won님 날짜 : 10-08-14 19:36 조회 : 136441
[ti_new]PM이 알아야할 소프트웨어 테스팅.pdf (2.1M), Down : 170, 2010-08-30 11:09:32
업계 여러분의 피드백을 거쳐 첨부 파일처럼 내용을 어렵게 완성하여 PM 커뮤니티에 전달합니다.
첨부 파일 재밋게 읽으시고 주변 PM 분들에게 전파해 주시길...^^
(아래 내용은 더 이상 읽지 말아 주세요...초안이라 창피합니다.^^;)
-----------------------------------------------------------------------------------------------------------------------------------
PM 커뮤니티를 통해 아래의 글 내용을 전파하여 테스팅에 대한 인식을 개선하려 합니다.
글 읽으면서 결함을 포함한 어떤 커멘트 든 주시면 반영하여 보다 완성도 높은 글을 PM 들에게 전하겠습니다.
감사~
-----------------------------------------------------------------------------------------------------------------------------------
아래 글은 다년간 PM이 알아야할 SW 테스팅에 대해 고민하고 컨설팅과 교육을 통해 여러 PM을 접하면서 확인한 내용을 정리한 내용입니다.
(*여기에서 논의되는 내용을 주변 PM분들에게 전파해 PM분들이 테스팅에 대한 인식을 개선하도록 하면 어떨까요? 요즘 "PM을 위한 테스트 매니지먼트" 교육을 진행하면서 약간의 테스팅 교육이 PM의 인식을 어느 정도 개선할 수 있는지 알고 무척 놀랐습니다. 테스팅 및 QA전문가 분들이 조금만 노력하면 어렵지 않다고 확신합니다.^^)

========PM이 알아야할 SW 테스팅===================================== 

PM이 알아야할 테스팅 (PM 이 활용해야할 테스팅 컨셉 및 실무) 관련 내용에는 어떤 것이 있을까?

ㅇ  김PM은 프로젝트를 시작하면서 요구사항(요건)을 현업(사용자)가 너무 간략하고 애매모호하게 전달해 주어 이를 더 상세히 명확하게 달라고 요청하고 현업은 바쁘니 알아서 해달라고 하면서 요건을 명확하게 하는 것이 당신의 일이 아니냐고 반문한다. 현업과 옥신각신하는 사이 설계는 시작되고 뭔가 문서가 나오는데 명확한 것은 찿기 어렵고 문서 구색 맞추는 것만 분주하다.

ㅇ  어느날 눈떠보니 개발자가 코딩을 시작했고 일정은 밀리기 시작해 단위 테스팅은 많은 부분 생략하고 얼마나 수행되었고 어느정도 커버리지를 갖는지 확인할 틈도 없이 통합 테스팅 일정이 다가온다. (*이 때 사실 김PM은 커버리지에 대해 많이 접했고 테스트 수행 정도를 파악하는데 쓰고는 있는데 정확한 의미를 알고 있지 못해 찜찜해 하고 있다.) 통합 테스팅 계획을 검토하기는 했는데 테스팅할 것이 너무 많아 어디에 집중해 테스팅해야할지 명확치 않고, 얼마나 어떻게 테스팅할지 고민하기 보다는 일정 내에 열심히 테스팅하고 발견되는 결함 디버깅하느라 분주하다. 테스팅과 디버깅이 혼재되어 있는데다 결함의 원인이 뭔지, 어느 부분에서 발견된 것인지 식별하는데 정신이 팔려 있고 치밀하게 새로운 결함을 찾는 것은 우선순위에 밀림을 김PM이 알고는 있다. 물론, 테스트 케이스와 테스트 시나리오가 얼마나 짜임새있고 완성도 높게 만들어져 있는지 파악할 방법이 없고 만든 사람이 잘했으려니 믿고 맡긴다.

ㅇ  테스팅팀이나 고객(기술)지원팀에서 일정에 맞춰 제품을 인도해 달라는 압박에 통합 테스팅을 어느정도 진행하고 품질에 대한 확신은 전혀없이 찜찜한 마음으로 개발한 것을 시스템 (또는 인수) 테스팅 단계로 넘기는 것을 승인한다. 시스템 테스팅 계획을 검토하기는 했는데 웬지 통합 테스팅의 많은 부분을 중복하는 느낌이고 테스팅 안되는 부분이 있는 것 같기도하다. 사용성 테스팅, 보안성 테스팅, 유지보수성 테스팅 등 비기능 테스팅에 대한 얘기는 들었어서 이를 테스팅팀에 요청한다. 테스팅 팀은 기능 테스팅과 성능 테스팅에만도 시간이 부족한데 무슨 다른 비기능 테스팅을 요구하느냐며 반발하고 당장 지금하는 테스팅에  추가 인력 투입을 요청한다.

ㅇ  출시가 다가오는데 결함은 계속 발견되고 수정하면 사이드 이펙트가 발생하고 현업은 원래 요구했던 것과는 다르다고 불만이다. 요구사항 정의된 문서를 보여줘도 그 내용을 잘못 해석해서 개발했다는 주장이다. 그마저 현업이 쓰다가 이런저런 결함이 발견되어 현업은 인상을 찡그리고 이정도 밖에 못하냐고 핀잔한다. 이런 이유로 애매한 요건을 줘서 이렇게 개발할 수 밖에 없었다는 이야기도 큰소리로 못한다. 김PM은 생각해 본다, 프로젝트 전체에 걸쳐 그렇게 많은 시간을 테스팅에 썼는데 왜 이렇게 문제가 많지...라고. 

일부 리뷰 및 인스펙션 활동과 개발자 중심으로 진행하는 단위/통합 테스팅, 별도의 테스팅 또는 QA조직에서 주도하는 시스템 테스팅과 비기능 테스팅(성능 테스팅, 사용성 테스팅, 유지보수성 테스팅 등), 현업이나 진행하는 인수 테스팅 등 개발 전반에 걸친 다양한 테스팅이 하나의 프로젝트에서 진행된다. 이 같은 개발 프로젝트 전체에 걸쳐있는 테스팅을 모두 고려하면 일반적으로 개발 비용의 50%이상이 테스팅 비용이라 볼 수 있다.(업계 테스팅을 어느정도 아는 PM 대상 조사 결과)  테스팅에 상대적으로 많은 비용이 투입되므로 이런 비용을 스마트하고 현명하게 쓰는 것이 개발 제품의 품질을 확보하는데 결정적인 역할을 한다.

전체 개발 프로젝트에서 테스팅의 일부는 전문 테스팅팀이나 QA팀에서 맡게되고, 상당히 많은 부분은 다른 개발 관련자와 현업(사용자)가 담당한다. 그리고, 이 전체를 PM이 볼 수 있어야하고 필요 시 테스팅을 조율하고 최적화해야 한다. 그렇다면 PM이 테스팅을 전체적으로 보고 각각 다른 조직에서 그들의 관점에서 진행되는 테스팅 활동을 적절히 조율하기 위해 어떤 테스팅 관련 내용을 알고 있어야 할까?

모든 것을 다 알면 좋겠지만 한시적인 프로젝트를 성공적으로 수행하기 위해 관리적인 측면에서의 테스팅 관련 사항 정도는 알아야 한다. 어려운 점은 관리를 피상적으로 하지 않으려면 테스팅 관련 핵심 사항은 상당히 깊이있게 알아야 한다는 것이다. 그리고 더 큰 어려움은 소프트웨어 테스팅이 현재 PM이 생각하는 것처럼 아무나할 수 있는 단순한 일이 아니라는 것이다. 테스팅 지식체계는 (Foundation Level에서 부터 Advancd, Expert Level까지) 잘체계화되어 있고 매우 방대하며 전체에 대해 전문가가 되는 것은 몇십년을 해당 분야에서 일해온 사람도 어렵다.

큰 그림에서 볼 때는 PM이 "테스팅 프로세스와 방법론", "리스크기반 테스팅 전략"을 깊이 있게 이해하는 것이 필요합니다.(전체 프로젝트를 다스리고 지원해야하기 때문) 간단해 보이나 이를 깊이 있게 이해하기 위해서는 테스팅 전반에 대한 이해가 선행되어야하고, 테스팅 전략, 테스트 설계 및 테스트 케이스의 품질에 대한 이해 등의 일부 핵심 테스팅 컨셉은 깊이있게 알아야 한다. 테스팅을 제대로 관리할 정도의 지식과 경험의 확보는 피상적인 수준은 쉬울 수 있지만, 어느정도 알고 관리하려면 습득해야하는 내용이 적지 않다.  
 

PM이 알아야할 SW 테스팅 (PM 이 활용해야할 테스팅 컨셉 및 실무) 내용을 여러 전문적 식견을 가진 분들의 의견을 반영하여 아래에 정리해 보았다.

1. 테스트의 중요성 인식 및 필요 시 이를 고객 및 임원을 대상으로 납득시킬 수 있는 스킬 (테스트 결과를 활용하여 임원이나 고객의 설득이나 개발 전체의 신뢰도 확보)

2. 테스트가 가능하도록 사전 준비(테스트 계획) - 일정과 인력을 테스트에 배분하고 시험 환경 구축 계획 수립

3. 요구사항 기반의 테스팅

  • 원하는 품질의 제품을 만들 수 있도록 정확한 요구 분석이 필요
  • 요구사항 명세 수준을 높여야 테스팅 수준이 높아짐
  • 요구사항을 대상으로 미리 테스트를 계획하고 설계해 봄으로써 요구사항의 품질을 높임

4. 테스팅 활동을 명확하게 리스트업 (테스팅 활동에 대한 WBS 작성)

  • 핵심적인 테스팅 관련 활동을 나열한 후, 테스트 매니저가 있으면 많은 내용을 테스트 매니저에게 맡기고, 없으면 개발 리드나 QA 등에 맡기거나 PM 본인이 해당 프로젝트가 반드시 필요로하는 테스팅 활동을 제대로 수행해야함 

5. 테스트할 정확한 시점 인지(전체 개발 일정과 연계) - 개발 초기에 테스팅을 시작하는 것의 중요성을 알고 고객이나 경영층을 설득하여 필요한 리소스를 개발 초기에 확보할 수 있음

6. 테스트에 대한 기본적인 지식 습득 (기본적인 테스팅 교육을 받고 프로젝트 관리에 지속적으로 활용한 경험 확보)

  • V-모델 이해, 용어의 이해, 테스트 설계기법, 테스트 커버리지, 테스트 프로세스, 리그레이션 테스팅, 리스크 기반 테스팅, 결함 관리 등
  • 프로젝트 계획 시 일정 품질을 확보하기 위해 테스팅에 소요되는 비용, 일정의 산정(또는 협의를 위해 커뮤니케이션할 수 있는 수준)
  • 일정상 테스트 기간을 조정해야 할 때 직접 조정 또는 커뮤니케이션을 통해 조정할 수 있는 수준.
  • 테스트가 제대로 되었는지 어떻게 되었는지 리포트를 받고 이해하며 다음 단계로 진행할지 의사결정하는데 필요한 내용
    • 테스팅에 어떠한 수치와 리포트가 필요한지와 그 리포팅 해석 방법과 조치 방법을 알아야 함.
       

7. 리스크분석을 통해 테스트 대상의 중점관리 항목(기능, 화면, 시나리오 등) 추출 (제품의 리스크 분석 결과를 테스팅에 활용하는 것은 물론 개발 전반에 활용하는 것에 대한 이해 - 리스크 관리의 핵심적인 한부분)

  • 테스트 매니저의 유무에 따른 테스팅 전략 수립이 필요하다고 생각할 수 있으나, 결과적으로 테스트 매니저가 있던 없던 핵심적인 테스팅 프로세스는 갖추고 테스팅 활동은 해야하므로 이를 아는 것이 기본이다

8. 테스트 전략과 정책을 숙지하고 이를 직접 수립할 수 있음 (그래서, 테스트 매니저나 개발 리드가 작성한 리스크 기반 테스팅 전략을 개발 전체적인 관점에서 정확하게 이해할 수 있고 가이드할 수 있음)

이외에도 철저한 테스트 실행 관리,

PM이 알아야할 SW 테스팅 관련 사항을 내용적 핵심성과 즉시 적용가능성이라는 두가지 요소로 우선순위를 파악해 보면 아래와 같다.

<"핵심적인 내용 VS 즉시 적용 가능한 내용"을 고려한 우선순위 파악> --> 그림 곧 수정하여 대체할 예정!!!

 

기본적으로 PM이 핵심적으로 즉시 알아야할 테스팅 관련 내용은 테스팅 활동을 WBS로 표현하고 이를 근간으로 테스트 계획을 수립하는 방법과 그 과정에서 리스크 분석을 하고 이에 기반한 테스팅 전략 수립이다. 해당 전략의 핵심 중 한가지는 테스트 설계이므로 테스트 설계와 테스트 케이스 도출에 대해 이를 충분히 검토할 수 있는 수준으로 이해하고 경험해야 한다.

프로젝트 관리에서 핵심은 비용 절감, 일정 단축, 품질 향상이다. 테스트에 대한 이해를 높이고, 기본 원리와 기법을 숙지하고 이상적으로 활용하면 프로젝트 관리의 핵심을 충족할 수 있다. PM의 테스팅에 대한 이해와 경험이 충분하다면 테스팅을 이상적으로 활용하지 못하더라도 동일한 비용과 일정 하에서 보다 높은 품질을 확보할 수 있다.

모두가 인지하는 바와 같이 점차 시스템은 복잡해지고 고객은 높은 품질을 요구한다. 품질을 확보하는 가장 기본적인 수단이 테스팅인 점도 모두가 알고 있고, 게다가 개발 프로젝트 전체 비용의 50%이상이 프로젝트 내의 다양한 테스팅으로 쓰여진다. 이는 PM이 테스팅을 이해함으로서 프로젝트의 성공 확률을 배가시킬 수 있음을 의미한다. PM이 개발 전체를 고려하며 테스팅을 현명하고 스마트하게 주도하는 것은 프로젝트 성공의 핵심이다.

-------------------참고 : 다양한 시각에서의 프로젝트 관리와 테스팅 관련 흥미로운 주제--------------------------------

  • PM이 테스팅을 프로젝트를 관리하는 수단으로 사용
    • PM이 리스크기반 테스팅 전략을 전체 프로젝트를 관리하는 전략으로 사용
  • 선무당이 사람잡을 수 있음. - PM이 테스팅에 대해 기본적이고 전체적으로 알아야하는데, 어설프게 알면 프로젝트 멤버들을 오히려 괴롭힐 수 있음
  • QA가 PM으로 성장하는 것이 가장 바람직한 PM이 될 수 있음
  • PM이 테스팅을 활용하고 체계적으로 경험하면, 능력있는 QA와 테스트 매니저 및 컨설턴트가 될 수 있는 것은 물론 능력있는 CIO가 되는데 필수적인 스킬을 갖출 수 있음 (CIO가 테스팅을 주도하는 사례)
  • 변경되지 않는 요구사항은 중요한 요구사항으로 테스트시에 집중해야 함
  • 개발 설계 문서 작성의 범위를 리스크로 조정 (Risk-based Modelling) 


출처 : 테스트 매니저 모임
http://www.sten.or.kr/club/club_main.php?cb_id=cb_TM