Test Cases and Coverage
테스트 케이스 == 테스트 ?
프로젝트를 시작 할 때 우리는 아직 테스트 방법을 알지 못합니다. 해당 제품을 학습을 해야 비로써 관련 테스트 전략을 개발 할 수 있습니다. 미팅에 참석하거나, 사람들과 대화하거나, 프로젝트 계획을 검토, 설계 또는 스케치를 검토하는 등 제품에 대해 배울 수 있는 여러 가지 방법이 있을 수 있습니다. 실물 모형 또는 프로토타입으로 작업 할 수 있도 있고, 제품의 일부를 사용 할 수 도 있습니다.
제품 또는 기능에 대해 배울 때 제품 요인에 따른 적용 범위 개요를 작성 합니다.(제품 요인은 테스트 또는 테스트 결과에 영향을 미칠 수 있는 요인 입니다.) 개요 에는 계층 목록, 표, 주석이 달린 다이어그램 등 여러가지 형식이 포함될 수 있습니다.(요즘은 마인드 맵이 좋습니다.)
확인해야 한다고 생각되는 특정 요인 또는 조건 모두 기록해 두는 것이 좋을 수 있지만, 프로젝트 시작하는 단계이기 때문에 아직 아무도 모든 요소를 인식 할 수 없습니다.
당신이 개요를 작성 하는 동안, 테스트를 더 빠르고 쉽게 할 수 있기 위한 것들을 주장하세요. 제품은 개발자가 스크립트 가능한 인터페이스(API)를 통해 더 빠르고 쉽게 테스트 할 수 있습니다. 로그 파일을 통한 가시성 향상, 기본 문제와 오류에 대해 이미 테스트한 코드 입니다. 프로그래머가 자체 테스트를 더 많이 수행하면 테스터는 낮은 레벨의 이슈를 조사하고 보고 할 필요가 없으므로 좀 더 심층적인 테스트에 많은 시간을 할애 할 수 있습니다.
커버리지 개요는 테스트 영역을 커버하귀한 전략에 미칠 기술 및 비즈니스 위험 식별 목로가 함께 제공됩니다. 개발이 진행됨에 따라 제품의 가치를 위협하는 잠재적인 문제에 대해 할게 됩니다. 문제가 숨어있을 수 있는 위치에 대한 아이디어를 탐색하는 것은 테스트 역할을 맡은 사람의 특별한 책임 입니다.
테스트는 탐색, 발견, 조사 및 학습 입니다. 가장 일반적인 방법을 제외하고는 계산 될 수 없으며 작업은 가용 가능한 시간에 맞게 확장되거나 축소되는 경향이 있습니다. 당신의 초기 계획이 예상대로 흘러가지 않을 것이라는 것을 인정해야 합니다.
테스트의 반복 단계를 거치면서 당신의 계획 및 테스트케이스는 발전 할 것입니다. 인지 된 내용과 아직 다루어지지 않은 않은 것에 대한 일일 보고서를 제공하는데 전념하세요. 일일 보고서는 관리자가 기울여야 하는 문제, 즉 제품의 가치나 프로젝트의 성공을 위협할 수 있는 문제에 대해 경고 할 것 입니다. 프로젝트 관리자는 테스트 케이스 수가 아니라 이러한 사항에 대해 알아야 합니다.
일일 보고서의 핵심 요소로는 제품의 테스트 용이성 또는 테스트하기 어려운 부분과 그 부재에 대한 메모를 제공해야 합니다. 테스트 가능성이 감소하면 테스트가 더 오래 걸리거나 적용 범위가 감소 됩니다. 커버리지 감소는 버그가 아직 발견되지 않고 더 오래 생존 할 수 있음을 의미 합니다.
커버리지 개요는 확실히 테스트 케이스들 보다 유지 관리가 쉽습니다. 일부 사람들은 “프로젝트 관리자는 테스트 케이스를 원합니다” 라고 말할 것 입니다. 아이들은 진짜 음식 대신 사탕을 원하고 중독자들은 불법 마약을 원합니다. 우리는 몸에 유해한 일을 할 의무는 없습니다. 테스트 케이스에 대한 고정관념은 실제 테스트보다 문서 및 절차에 더 중점을 두게 합니다. 대부분의 관리자는 테스트 케이스에 익숙하고 대안을 모르기 때문에 테스트 케이스를 원합니다. 테스터는 관리자가 테스트 케이스에 대해 계속 묻기 때문에 테스트 케이스를 제공합니다. 관리자에게 실제 테스트 작업, 당면한 작업의 개선, 적용 범위, 문제 및 위험에 대한 확실한 정보를 제공합니다.