원본 : http://googletesting.blogspot.kr/2016/06/the-inquiry-method-for-test-planning.html
|
아래는 The Inquiry Method for Test Planning - by Anthony Vallone
테스트 계획을 작성하는 것은 복잡한 업무입니다. 테스트 계획은 비용 효과 분석 (cost-benefit analysis) 및 위험 분석 (risk analysis) 의 기본 원칙에 따라 최적화되고 이상적인 테스트 계획이 달성됩니다.
위 기반원칙에 기반한 균형 맞춰 고려해야할 소프트웨어 개발 요소 :
- 구현 비용 : 시간 및 구현 기능의 복잡도, 특정 시나리오에 대한 자동화 된 테스트가 각기 다를 것이고 이런 부분들이 단기 개발 비용에 영향을 미치게 됩니다.
- 유지 보수 비용 : 일부 검사 또는 테스트 계획은 각기 난이도가 다를 수 있으며, 장기 개발 비용에 영향을 미친다. 수동 테스트가 선택되면, 이것 또한 장기 비용에 영향을 미치게 됩니다.
- 금전적 비용 : 일부 시험 방법이 비용을 필요로 할 수 있습니다. (강신혁 주: sms, 일부 실제 결제 테스트등)
- 이득 : 테스트가 이슈를 선제적으로 방지하고 다양한 각도의 생산성을 보조 할 수있는지 또한, 개발 라이프 사이클에서 문제를 미리 잡아서 더 큰 이득을 생성할수도 있다는것도 고려해야합니다.
- 위험 : 장애 시나리오의 확률은 발생할 가능성이 매우 드문 케이스가 있을수 있으며, 그 결과는 아주 사소한 것부터 대재앙에 이르기까지 다양하게 발생할수 있습니다.
테스트 계획에서 위 요소들의 효과적인 균형을 잡는 것은 프로젝트의 중요성, 구현 세부 정보, 이용 가능한 자원 및 팀의 의견에 크게 의존하게 됩니다.
많은 프로젝트는 고효율성? (high-benefit), 저비용의 유닛테스트(low-cost unit tests)로 뛰어난 커버리지를 달성 할 수 있지만, 더 큰 테스트과 복잡한 예외 케이스에 대한 선택을 채용해야 할 수도 있습니다.
무결점을 요구하는 중요 프로젝트(Mission critical projects )는 가능한 한 위험을 최소화해야한다, 그래서 그런 프로젝트들은 더 높은 비용을 적용하고 모든 수준에서 엄격한 테스트에 많은 투자를 하게된다.
이 가이드는 프로젝트에 대한 올바른 균형을 찾는 것을 지원하고자 합니다.
또한, 여기서 테스트 계획 템플릿을 제공하지는 않습니다. 왜냐하면 템플릿은 간혹 너무 일반적이거나 너무 구체적이어서 빠르게 구형이 될수있기 때문입니다.
대신, 테스트 계획을 작성할 때 가장 좋은 콘텐츠를 선택하는데 초점을 맞추도록 하려 합니다.
대신, 테스트 계획을 작성할 때 가장 좋은 콘텐츠를 선택하는데 초점을 맞추도록 하려 합니다.
테스트 계획 대 전략 (Test plan vs. strategy)
진행하기 전에 테스트 계획을 정의하는 두 가지 일반적인 방법을 명확히 할 필요가 있습니다 :
- 단일 테스트 계획 : 일부 프로젝트는 프로젝트의 모든 구현 계획 테스트를 설명하는 하나의 "테스트 계획"으로 돠어 있다.
- 단일 테스트 전략과 다수의 테스트 계획 (Single test strategy and many plans) : 일부 프로젝트는 소수(혹은 하나)의 "테스트 전략" 문서와 많은 작은 "테스트 계획"문서가있다.
테스트계획은 특정 기능 또는 프로젝트 업데이트를 커버하면서 테스트 전략은 일반적으로 전체 테스트 접근 방법과 목표를 다룬다.
이러한 것들은 프로젝트 설계 문서와 통합되거나 포함 될 수있다.
일반적으로, 안정적인 프로젝트는 단일 테스트 계획이 나은 선택일수 있고,
자주 (혹은 빠르게) 변경되는 프로젝트의 경우 단일 테스트 전략과 다수의 테스트 계획 방식으로 작은 전략 변경과 다수의 테스트계획을 추가해나가는 방향이 좋습니다.
자주 (혹은 빠르게) 변경되는 프로젝트의 경우 단일 테스트 전략과 다수의 테스트 계획 방식으로 작은 전략 변경과 다수의 테스트계획을 추가해나가는 방향이 좋습니다.
이 가이드의 목적은 간략히 "테스트 계획"으로 모두 테스트 문서 유형을 참조합니다.
컨텐츠 선택 (Content selection)
테스트 계획에 대한 내용을 만드는 좋은 방법은 답변을 필요로하는 모든 질문을 나열하여 시작하는 것입니다.
중요한 질문의 포괄적인 선택 목록은 프로젝트에 적용되지 않을 수도 있습니다. 해당 사항을 모두 선택하고 이러한 질문에 대답함으로써, 테스트 계획에 대한 내용을 생성할것입니다.
당신은 당신의 팀이 선호하는 형식, 그리고 위에서 언급 한 요소들의 균형을 맞춰서 선택된 내용으로 당신의 계획을 구성해야합니다.
당신은 당신의 팀이 선호하는 형식, 그리고 위에서 언급 한 요소들의 균형을 맞춰서 선택된 내용으로 당신의 계획을 구성해야합니다.
전제 조건 (Prerequisites)
- 테스트 계획이 현재 필요한지?
프로젝트 설계 문서 또는 제품에 대한 명확한 요구사항(a clear vision for the product)이 없는 경우, 테스트 계획을 작성하는것은 시기상조일 수 있다. - 프로젝트 설계에서 고려 된 테스트 용이성은?
프로젝트 구현에 너무 멀리 도착하기 전에, 모든 시나리오는 자동화를 통해 검증으로 설계되어야 바람직하다.
프로젝트 설계 문서 및 테스트 계획은 테스트 용이성에 대해 반드시 언급되어야 한다. - 최신 계획을 유지하고 있는가? 그렇다면 너무 많은 세부 사항을 추가하는 것에 대해 주의해야하고 그렇지 않으면 계획을 유지하기 어려울 수있다,
- 다른 팀이 품질 유지에 있어 중복적인 일을 하고 있진 않은가? 그렇다면, 어떻게 중복적인 일을 제거할 것인지?
위험 (Risk)
- 그 프로젝트에 어떤 중요한 프로젝트 위험이 있다면, 당신이 그 요소들을 완화하는 방법이 있습니까? 고려사항 :
- 사람이나 동물로부터의 상해
- 보안 및 사용자 데이터 무결성
- 사용자의 개인 정보 보호
- 기업 시스템의 보안
- 하드웨어 또는 재산 피해
- 법률 및 규정 준수 문제
- 기밀 정보 나 민감한 데이터의 노출
- 데이터 손실 또는 손상
- 수익 손실
- 복구 할 수없는 시나리오
- 서비스준수협약 (SLAs)
- 성능 요구 사항
- 사용자가 다르게 받아들수 있는 가능성 (Misinforming Users)
- 타 프로젝트에 미칠 영향
- 다른 프로젝트로 받을 영향
- 회사의 공공 이미지에 미치는 영향
- 생산성 손실
- 어떤 프로젝트의 기술적 취약점입니까? 고려사항 :
- 기능(Features) 혹은 구성 요소(components) 가 알려진 해킹시도나 깨지기 쉬운지, 혹은 큰 리팩토링이 필요해보이는지.
- 서비스 종속성 또는 자주 문제가 발생할 플랫폼인지
- 사용자에 의해 시스템에 해를 입을 가능성이 있는지
- 과거 이슈에서 본 동향들
적용 범위 (Coverage)
- 이 시스템은 어떤 형태인지?
간단한 라이브러인지? 혹은 멀티 플랫폼 클라이언트의 복잡한 조합으로 인한 부하가능성이 있는지? 실패 가능성을 강조하는 방식으로 시스템의 설계 및 아키텍처에 대해 설명합니다. - 무슨 기능인가?
모든 기능의 요약 목록을 고려하고 기능의 특정 범주를 테스트 할 방법을 설명합니다. - 무엇이 테스트되지 않는지?
어떤 테스트집합 (Tests suite)는 모든 가능성을 포함하지 않습니다. 어떤 케이스를 테스트하지 않는지 이론적 근거를 제공하는 것이 가장 좋습니다.
예 : 낮은 우선 순위, 낮은 우선 순위 복잡한 경우, 다른 팀에 의해 포함될 커리리지 영역입, 저위험 지역, 테스트 등 준비가되지 않은 기능 - 어떤 테스트가 단위테스트 (소), 통합테스트 (중), 시스템테스트(대) 에 의해 커버리지가 들어오는지?
언제나 가능하다면 단위테스트(소)에서 할수있는 만큼 테스트를 많이 수행하는것이 좋으나 특정 케이스의 경우 대단위 테스트에서 밖에 진행못할수도 있습니다.
각 테스트의 크기에 의해 테스트하는 방법을 카테고리별로 설명하고 이론적 근거를 제공한다. - 어떤 케이스를 자동으로 하고 수동으로 테스트할지?
많은 프로젝트는 모든 테스트를 자동화 할 수 있습니다. 그러나 수동 테스트를 선택하는 좋은 이유가있을 수 있습니다. 수동으로 테스트 할 경우 유형을 설명하고 이론적 근거를 제공한다. - 어떻게 각각의 테스트 카테고리를 커버할것인지? 고려사항 :
- 정적 (및/혹은) 동적 분석 도구를 사용하는지?
정적 분석 도구 와 동적 분석 도구를 모두 코드리뷰 및 테스트상에 잡기 어려운 문제를 발견할수 있으므로 이것들의 사용을 고려하는게 좋다. - 시스템 구성 요소 및 종속성이 어떻게 목업, 가상환경 혹은 일반적 데이터를 사용할것인지?
위 방식 모두 각각의 범위에서 고유 한 영향을 미치므로 개별 방식으로 해야 할 좋은 이유가 있습니다. - 이 테스트에 대해 어떤 빌드를 실행할지?
HEAD (일명 팁)에서 빌드에 대해 실행 테스트, 단계적 빌드 및 / 또는 릴리스 후보가 있는지? - 특정 테스트는 팀의 외부에서 수행되는지? 예 :
- 시험 사용
- 외부 크라우드 소싱 테스트
- 공개용 알파 / 베타 버전
- 외부 신뢰할 수있는 테스터
- 데이터 마이그레이션 테스트 방법은?
마이그레이션 이전과 이후를 비교하는 특별한 테스트를해야 할 수도 있습니다. - 이전 버전과의 호환성을 확인해야하는지?
이전에 분산 된 클라이언트를 소유하거나 시스템의 프로토콜, 구성, 기능 및 행동에 따라 다른 시스템이있을 수 있습니다. - 서버 / 클라이언트 / 장치 소프트웨어 또는 소프트웨어를 사용하는 것이 의존성 / 플랫폼 / API에 대한 업그레이드시나리오를 테스트해야하는지?
- 선행적인 테스트 커버리지 목표를 가지고 있는지? (Do you have line coverage goals?)
테스트 도구 및 인프라 (Tooling and Infrastructure)
- 새로운 테스트 프레임워크가 필요한지?
필요하다면, 테스트계획에서 이것을설명하거나 설계 링크를 추가해야 한다. - 새로운 테스트 실험실 설치가 필요한지?
필요하다면, 테스트계획에서 이것을설명하거나 설계 링크를 추가해야 한다. - 프로젝트가 다른 프로젝트에 서비스를 제공하는 경우, 그 사용자에게 테스트 도구를 제공하는지?
모의 객체, 가상환경(fakes)를 제공 고려, 우리 시스템에 대한 통합테스트를 진행할수있도록 서버 구성을 해주어야 한다. - 종단간(end-to-end)테스트를 위해, 어떻게 테스트에서, 시스템 인프라를 테스트하며, 다른 종속성을 관리 할 수있고 어떻게 배포 할 것인가?
어떻게 지속성이 설정 및 파괴될지? 어떻게 다른 하나의 데이터 센터에서 마이그레이션이 필요할것인지? - 디버그 시스템 또는 실패테스트를 구현할 수있는 도구가 필요한지?
기존의 도구를 사용할 수 거나 새로운 것을 개발해야 할 수 있습니다.
절차 (Process)
- 시험 일정 요구 사항은 있는지? 테스트 장소와 일정에 대한 약속이 있는지? 그 전에 제공해야 할 중요한 테스트가 별도로 있는지?
- 빌드 및 테스트를 지속적으로 실행하는 방법이 있는지?
대부분의 소규모 테스트에 의해 지속적인 통합 이 실행되지만 큰 테스트 (강신혁 주 :통합테스트등)는 다른 접근 방법이 필요할 수 있습니다.
또는, 필요에 따라 대형 테스트를 선택할 수 있습니다. - 어떻게 구축하고 테스트 결과를 보고하고 모니터링 할것인지?
- 지속적인 통합을 모니터링하는 팀 업무순환이 되어있는지?
- 대형테스트는 전문 지식을 가진 사람에 의한 모니터링이 필요할 수 있습니다.
- 테스트 결과와 다른 프로젝트 건강 지표에 대한 대시 보드가 필요하십니까?
- 누가 이메일 알림을 받을지?
- 유인 모니터링 테스트 (the person monitoring tests) 는 팀에 구두 통신을 사용하는지?
- 배포 (릴리즈)할 때 사용되는 테스트방식은?
- 이들이 배포 후보군에 대해 명시 적으로 실행되는지?
- 시스템 구성 요소 및 종속성/독립적으로 방출하는 경우, 테스트는 배포 유형별로 각각 실행되는지?
- "릴리스 블럭커" (강신혁 주 : 크리티컬버그) 버그가 실제로 배포시 중단 할 것인가? 릴리즈 중단할 크리티컬 버그에 대햔 협약이 생성되었는지?
- 카나리아 릴리즈 (일명 롤아웃) (강신혁 주 : 정식 릴리즈전 개발자 배포) 를 수행 할 때, 어떻게 모니터링하고 테스트를 진행할수있는지?
- 어떻게 외부 사용자가 버그를 리포트할지?
피드백 링크를 클릭하거나 수집하는 다른 유사한 도구와 클러스터 보고서를 고려한다. - 어떻게 버그 선별 작업을 할지?
버그 라벨 또는 카테고리를 생각해 보자. 또한 신청 및 또는 버그 리포트 템플릿을 생성하는 책임이있는 팀이 알고 있는지 확인하십시오. - 잡힐 수 있었던 버그를 닫기 전에 새로운 테스트를 제출하기위한 정책이 있습니까?
- 제출되지 않은 변경에 사용되는 시험은 무엇입니까?
어떤 실험 빌드에 대한 전체 테스트을 운영하는 방법을 제공하는 것을 고려 할 수 있습니다. - 팀 멤버들이 테스트를 디버깅하거나 생성할수있는 방법이 있는지?
없다면 이를 제공하는것이 좋습니다.
유용성 (Utility)
- 테스트 계획을 읽는 사람은 누구인지?
어떤 테스트계획은 단 몇사람만 읽을것이고, 다른 경우는 매우 많은 사람이 읽어 볼수 있다. 최소한, 당신은 모든 이해 관계자 (프로젝트 관리자, 기술 리더, 기능 소유자)에게 리뷰를 받고 고려해야합니다.
당신의 대답은 아직 대답을하지 않는 경우에도 - 계획을 작성할 때, 당신은 그들이 가지고있는 생각의 모든 문제, 예상 독자를 이해 계획을 이해하는 데 충분한 배경을 제공하고, 답변을해야합니다.
또한 테스트 계획에 대한 독자를 추가하는 것을 고려하면 어떤 독자는 더 많은 정보를 얻을 수 있습니다. - 독자는 실제 테스트 케이스를 검토 할 수 있는지?
수동테스트의 경우는 별도의 문서, 테스트 케이스 관리 도구에서, 또는 시험 계획에 포함되어 있어야 합니다.
자동화 된 테스트 케이스를 포함하는 디렉토리에 대한 링크를 제공하는 것이 좋습니다. - 당신은 요구 사항, 기능 및 테스트를 추적 할 필요가 있는지?
- 당신이 어떤 일반적인 제품의 상태나 품질 목표를 가지고 성공을 측정하는 방법이 있는지? 고려사항 :
- 출시 마감 ( Release cadence )
- 출시후 실사용자들에 의해 발견 된 버그의 수
- 배포 테스트 (강신혁 주 : 시뮬테스트) 에 의해 발견된 버그의 수
- 시간이 지남에 따라 발견된 버그의 수
- 코드 커버리지
- 수동 테스트에 들어간 비용
- 신규 테스트를 생성하는 난이도
