고정 헤더 영역
상세 컨텐츠
본문
반응형
1. BVT란?
- Build Verification Testing의 약자로, Smoke Test라고도 함.
2. BVT의 목적 및 의도
- BVT는 특정 빌드에 대해서 수행한다.
- BVT는 빌드 마다 각각 수행될 수 있다. (매 빌드마다 수행하는 것이 좋다는 의미는 아님.)
- BVT는 해당 빌드가 더 이상 리소스를 투입해서 테스트를 진행할 가치가 있는 빌드인지 판단하고 개발팀에 피드백을 주기 위한 목적.
QA는 더 이상의 의미없는 테스팅 리소스를 투입하지 않을 수 있고, 개발팀은 테스팅이 더 진행되어서 문제의 원인 파악이 어려울 수 있는 전 단계에서 오류 여부를 확인할 수 있게됨.
3. BVT 준비 단계
- TCL(Test Case List) 테스팅을 위해 마련된 TCL은 먼저 준비되어 있어야 한다.
- TCL은 한 가지 품질 속성 및 기능 군으로 작성하지 말고, 다수의 기능 군 영역, 품질 속성 영역으로 나누어 작성되어 있어야 한다.
- 준비된 TCL이 커버하는 기능 군에서 중요하고 먼저 확인되어야 하는 선행 기능을 몇 개 추린다. (가능한 한 케이스 간의 의존성이 없게 한다.)
- 각 기능 군마다 1-4 정도의 케이스를 추려서 이를 하나의 양식으로 정리하면 BVT 수행을 위한 테스트 케이스가 완성된다.
- BVT 요소 선정의 또 다른 기준은 BVT에 오랜 시간이 걸려서는 안된다는 점이다. 따라서, 프로젝트의 상황을 보아 BVT에 투입할 수 있는 시간(예를 들면, 1시간 또는 2시간)에 따라서, BVT의 수를 가감한다. (예를 들면, BVT는 1시간 이내로 수행 완료 하고 그 결과를 개발팀과 리뷰할 수 있도록 정한다 등의 규칙)
4. BVT가 완료된 이후의 업무 처리 단계
- BVT 내용에 대해서 Peer Review(동료 검토)를 수행해서 피드백을 반영한다. (반드시 수행하는 것이 좋다. 최적의 경우 2회 정도의 리뷰를 거쳐서 더 이상 QA 레벨에서는 수정 사항이 없다고 리뷰어 들과 합의가 되는 수준까지 진행한다.)
- QA 레벨에서 합의된 BVT 내용에 대해서 개발 선임 및 PM과 협의한다.
5. 협의시 주의 사항
- BVT의 내용에 대해서는 하나의 항목이라도 Fail 또는 Block 인 경우 더 이상의 테스트를 진행하지 않는다. 이유는 더 이상의 테스팅 리소스를 투입할 가치가 없는 빌드라고 볼 수 있기 때문이다.
- BVT의 Expected Result 및 케이스에 수정 사항이 없는지 검토를 요청한다.
- BVT에 추가할 요소가 없는지 검토를 요청한다. (대부분은 거의 없을 것임. ^^)
6. 협의가 완료되면
- 이제 확정이 되었으므로 개발팀 전체를 대상으로 공표하고 BVT가 필요하다고 QA에서 판단되거나, 개발팀의 요청이 있는 경우 빌드를 선정해 BVT를 수행하고 그 결과를 분석, 개발팀에 통보한다.
7. BVT를 기준으로 삼는 이슈들(반드시 PM 및 개발 선임과 사전 협의 필요)
- 모모 프로젝트에서 BVT를 이용하는 방법은 다음과 같다.
1) 모든 테스트의 시작에는 BVT가 반드시 있어야 한다.
2) TCL 테스트를 시작하려면 먼저 BVT가 통과된 빌드가 있어야 한다.(BVT를 통과해야만 TCL 테스트가 가능하다.)
3) 버그 추적 시스템에 올라온 이슈의 재 확인(Re-Testing)은 반드시 BVT를 통과한 빌드에 한정한다.(개발팀에서 수정이 반영되었을 것이라고 얘기하는 특정 빌드가 아니다. 반드시 BVT가 통과된 수정 사항이 반영된 이후의 빌드를 선정해 Re-Testing을 수행한다. 이때, BVT가 통과되지 않아 Re-Testing의 지연이 발생할 수 있으나, 이는 QA에서 통제할 수 있는 상황이 아니다. 만일 Re-Testing이 빨리 처리되기를 희망한다면 - 버그 처리 시스템의 이슈가 Closed 되기를 바란다면 - 최선의 방법은 개발팀이 BVT를 통과하는 빌드를 만들어 내는 것이라는 점을 개발팀에 설명하라.)
8. 남은 문제들
1) BVT 내용에 대해서 트집을 잡는 경우를 주의하라. 다시 강조하지만 BVT 요소에 대해서 개발팀 및 PM과 협의를 거쳐야 한다. BVT 정책을 수행한다는 내용과 함께 BVT 내용에 대해서도 Confirm을 받아 둔다.
2) BVT에 대해서 가급적 테스트 하는 사람에 따라서 결과가 달라질 수 있는 요소는 배제하라. 보는 사람에 따라(테스팅 하는 사람에 따라) BVT Pass / Fail이 달라지는 요소는 차후에 더 큰 이슈를 불러 온다.
3) 어느 수준에 이른 빌드는 이미 BVT는 가볍게 통과할 수 있다. 이때는 BVT 요소의 변경 / 추가 / 삭제를 고려해 보라. (물론 개발팀은 힘들게 달성한 BVT통과 수준이기 때문에 거부할 지도 모른다.)
------------------------------------------------------------------------------------------
Further Reading
아래에 BVT에 관해 언급하고 있는 참고 도서를 곁들여 보시면 더욱 좋습니다.
The Art of Project Management (마음을 움직이는 프로젝트관리) by 스콧 버쿤 pp. 419
일일 빌드를 수행할 경우, 체크인한 코드가 다른 부분에 피해를 입히면 프로그래머가 (그리고 전체 팀이) 이 사실을 즉각 알게 됩니다. 따라서 체크인 코드 품질이 높아집니다. 당일 빌드에 포함될 코드는 특정 시각까지 제출하게 하십시오. 그런 다음, 코드 기반을 안정화한 후 테스트를 수행하여 빌드 품질을 확인합니다. (흔히 이와 같은 일일 테스트를 동작 테스트_smoke test라고도 합니다. 전자 부품을 테스트하는 기법으로, 회로에 전기를 흘려서 글자 그대로 연기가 나는 부분이 있는지 확인합니다) 정해진 시간 이후에 체크인하는 코드는 다음 빌드에 포함됩니다.
빌드를 할 때마다 빌드 품질을 평가하는 테스트 집합이 있어야 합니다. 평가 기준은 합격 (모든 테스트 통과), 보류 (일부 테스트만 통과), 불합격 (몇몇 테스트만 통과 또는 모든 테스트 실패)이라는 세 단계 정도면 충분합니다. 테스트 실패 원인으로 파악된 버그는 빌드 정보에 기록하고 우선 순위를 높게 매겨야 합니다.
(중략)
Lessons Learned in Software Testing (소프트웨어 테스팅 법칙 293가지) by Cem Kaner외 2인 pp. 226
법칙 173. 때로는 빌드에 대한 테스트를 거부해야 한다.
때때로 빌드를 거절하고, 빌드에 대한 테스트를 거부해야 한다. 이와 같이 하는 것의 합리적, 기술적인 이유는 다음과 같다.
* 이번 빌드에서는 중요한 기능이 추가되었는데, 이 빌드에 존재하지 않는 기능이 있다는 것을 알아채거나 실행하자마자 오류가 발생하였다면 더 이상 테스트를 진행하는 것은 시간 낭비이다.
(중략)
법칙 174. 빌드를 평가하기 위하여 연기 테스트를 사용하라.
연기 테스트(일명 온전성 확인 또는 테스트 수락)는 빌드의 기본적인 기능성을 점검하기 위한 테스트 스위트이다. 만약 빌드가 이 테스트에 실패한다면 해당 빌드는 불안정하여 테스트할 가치가 없다고 말할 수 있다.
(중략)
Systematic Software Testing by Rick D. Craig and Stefan P. Jaskiel
스모크 테스트(Smoke Test)
스모크 테스트는 시스템이 안정적인가, 모든 주요 기능들이 존재하며 "일반적인" 상황에서 제대로 작동하는가를 입증하기 위한 테스트 케이스들의 집합입니다. 스모크 테스트의 목적은 소프트웨어의 모든 버그를 찾는 것이 아닙니다. 시스템을 테스트하는 팀에게 어디에서부터 테스트를 시작 해야 하는지 알게 해 주는 것입니다. 이 테스트는 개발자들에게 목표을 제공하며, 언제 개발자들이 '안정성을 보유한 단계'를 달성하게 되는 지를 알려줍니다.
중요 요점: Smoke test는 시스템이 안정적인가와 모든 주요 기능들이 존재하며, "일반적인" 상황에서 제대로 작동하는가를 입증하기 위한 테스트 케이스들의 집합입니다.
(중략)
Sustainable Software Development: An Agile Perspective by Kevin Tate
Practice 5. Nightly Builds
당신의 팀이 소프트웨어가 동작한다고 확신하기 위해서는 하루에도 몇 번씩 원소스로부터 완전하게 빌드가 생성되어야 한다. 그 빌드에는 통합의 문제를 일찍 발견해 내기 위해 가능한 한 많은 수의 자동화된 테스트를 담고 있어야 한다. 그리고 빌드의 결과는 설치 가능한 제품 이미지이어야 한다. 밤시간은 이러한 작업을 하기에 적당한 시간인데, 아무도 코딩을 하고 있지 않고, 놀고 있는 컴퓨터가 매우 많기 때문이다. 그럼에도 불구하고 가능한 한 낮에 많은 수의 제품을 빌드하는 것에 매우 많은 장점들이 있다. 만일 빌드나 테스트가 실패한 경우, 아침에 가장 먼저 할 일은 문제를 수정하는 것이다. 빌드가 다시 성공할 때까지는 아무도 자신의 추가 작업을 통합하지 못하게 하라. 그렇지 않으면, 잘못된 변경 사항이 누적되어 제품에 품질을 위태롭게 할 위험성이 있다.
(중략)
소프트웨어 프로젝트 생존전략 (Software Project Survival Guide) by 스티브 맥코넬 pp. 277
일별 빌드와 스모크 테스트 절차에서는 전체 프로그램이 날마다 빌드 된다. 즉 프로그램의 모든 소스 파일이 날마다 컴파일, 링크되어 실행 파일로 생성된다는 것이다. 그후 소프트웨어는 ‘스모크 테스트’를 거치는데, 이는 실행 중에 소프트웨어에서 ‘연기가 나거나’ 깨지지는 않는지 확인하는 비교적 간단한 테스트를 말한다. 스모크 테스트라는 용어는 전기 공학에서 나온 것인데, 글자 그대로 전기 장치를 켰을 때 연기가 나는지 검사하는 것이다.
날마다 일별 빌드와 스모크 테스트를 실시하면서, 빌드되지 않는 데에 책임 있는 개발자를 추적하고 그 원인을 수정하게 하려면 어느 정도 노력이 필요하다. 작은 규모의 프로젝트에서는 품질 담당자가 자신의 다른 업무를 병행하면서 일별 빌드를 수행한다. 좀더 큰 규모의 프로젝트에서는 전담 인원이나 전담 팀이 일별 빌드를 수행할 수도 있다.
스모크 테스트는 소프트웨어 개발에 보조를 맞추기 위해 프로젝트 전반에 걸쳐 업데이트해야 한다. 또한 날마다 실시해야 하기 때문에 대부분이 자동화하여 실행한다. 스모트 테스트는 모든 것을 철저하게 확인해야 하는 테스트는 아니지만, 그날의 빌드가 테스트할 수 있을 만큼의 안정성을 지닌 소프트웨어 기능인지 확인해야 한다. 소프트웨어가 테스트할 수 없을 만큼 불안정하다면, 그 소프트웨어는 스모크 테스트를 하지 말아야 한다.
(중략)
Game Testing All In One by Charles P. Schultz 외 2인
Entry Criteria
어떤 형태의 테스팅을 수행하더라도 사전에 테스트에 적합한지에 대한 어떤 통과 기준에 코드 릴리즈가 적합한지 확인하는 것이 권장된다. 이것은 우주 여행사나 파일럿이 비행 전에 항공 시스템이 운행에 적합한지 점검하는 체크리스트와 유사하다. 테스팅을 위해 제출된 빌드가 기본적인 진입 기준에 미달하는 경우 테스터와 프로그래머 둘 모두의 시간을 낭비하게 될 가능성이 많다. 테스팅의 카운트다운은 테스트 "발사" 통과 조건을 충분히 만족할 때까지 중단되어야 한다.
아래의 진입 기준으로 사용할 수 있는 제안들을 나열해 두었다. 반드시 개발팀의 인원들에게는 이 내용을 비밀로 하지 마라. 그 팀이 이것의 목적을 인식하고 (시간 낭비를 방지하기 위해) 전체 팀이 공감할 수 있는 통과 기준의 집합을 그들과 함께 만들도록 하라.
(중략)
PS1) 아마 이 내용의 핵심을 이해하고 그대로 시행한다면 프로젝트에서 여러 분들은 구원(?) 받을 겁니다.
PS2) 어떤 내용이든 참조를 하시고 도움이 되었다면 원전 표기와 레퍼런스 명기를 꼭! 잊지 마세요.
PS3) 이 글의 반응 강도에 따라서 제가 실전에서 사용하고 있는 엑셀 템플릿을 공개하겠습니다. ^^
- Build Verification Testing의 약자로, Smoke Test라고도 함.
2. BVT의 목적 및 의도
- BVT는 특정 빌드에 대해서 수행한다.
- BVT는 빌드 마다 각각 수행될 수 있다. (매 빌드마다 수행하는 것이 좋다는 의미는 아님.)
- BVT는 해당 빌드가 더 이상 리소스를 투입해서 테스트를 진행할 가치가 있는 빌드인지 판단하고 개발팀에 피드백을 주기 위한 목적.
QA는 더 이상의 의미없는 테스팅 리소스를 투입하지 않을 수 있고, 개발팀은 테스팅이 더 진행되어서 문제의 원인 파악이 어려울 수 있는 전 단계에서 오류 여부를 확인할 수 있게됨.
3. BVT 준비 단계
- TCL(Test Case List) 테스팅을 위해 마련된 TCL은 먼저 준비되어 있어야 한다.
- TCL은 한 가지 품질 속성 및 기능 군으로 작성하지 말고, 다수의 기능 군 영역, 품질 속성 영역으로 나누어 작성되어 있어야 한다.
- 준비된 TCL이 커버하는 기능 군에서 중요하고 먼저 확인되어야 하는 선행 기능을 몇 개 추린다. (가능한 한 케이스 간의 의존성이 없게 한다.)
- 각 기능 군마다 1-4 정도의 케이스를 추려서 이를 하나의 양식으로 정리하면 BVT 수행을 위한 테스트 케이스가 완성된다.
- BVT 요소 선정의 또 다른 기준은 BVT에 오랜 시간이 걸려서는 안된다는 점이다. 따라서, 프로젝트의 상황을 보아 BVT에 투입할 수 있는 시간(예를 들면, 1시간 또는 2시간)에 따라서, BVT의 수를 가감한다. (예를 들면, BVT는 1시간 이내로 수행 완료 하고 그 결과를 개발팀과 리뷰할 수 있도록 정한다 등의 규칙)
4. BVT가 완료된 이후의 업무 처리 단계
- BVT 내용에 대해서 Peer Review(동료 검토)를 수행해서 피드백을 반영한다. (반드시 수행하는 것이 좋다. 최적의 경우 2회 정도의 리뷰를 거쳐서 더 이상 QA 레벨에서는 수정 사항이 없다고 리뷰어 들과 합의가 되는 수준까지 진행한다.)
- QA 레벨에서 합의된 BVT 내용에 대해서 개발 선임 및 PM과 협의한다.
5. 협의시 주의 사항
- BVT의 내용에 대해서는 하나의 항목이라도 Fail 또는 Block 인 경우 더 이상의 테스트를 진행하지 않는다. 이유는 더 이상의 테스팅 리소스를 투입할 가치가 없는 빌드라고 볼 수 있기 때문이다.
- BVT의 Expected Result 및 케이스에 수정 사항이 없는지 검토를 요청한다.
- BVT에 추가할 요소가 없는지 검토를 요청한다. (대부분은 거의 없을 것임. ^^)
6. 협의가 완료되면
- 이제 확정이 되었으므로 개발팀 전체를 대상으로 공표하고 BVT가 필요하다고 QA에서 판단되거나, 개발팀의 요청이 있는 경우 빌드를 선정해 BVT를 수행하고 그 결과를 분석, 개발팀에 통보한다.
7. BVT를 기준으로 삼는 이슈들(반드시 PM 및 개발 선임과 사전 협의 필요)
- 모모 프로젝트에서 BVT를 이용하는 방법은 다음과 같다.
1) 모든 테스트의 시작에는 BVT가 반드시 있어야 한다.
2) TCL 테스트를 시작하려면 먼저 BVT가 통과된 빌드가 있어야 한다.(BVT를 통과해야만 TCL 테스트가 가능하다.)
3) 버그 추적 시스템에 올라온 이슈의 재 확인(Re-Testing)은 반드시 BVT를 통과한 빌드에 한정한다.(개발팀에서 수정이 반영되었을 것이라고 얘기하는 특정 빌드가 아니다. 반드시 BVT가 통과된 수정 사항이 반영된 이후의 빌드를 선정해 Re-Testing을 수행한다. 이때, BVT가 통과되지 않아 Re-Testing의 지연이 발생할 수 있으나, 이는 QA에서 통제할 수 있는 상황이 아니다. 만일 Re-Testing이 빨리 처리되기를 희망한다면 - 버그 처리 시스템의 이슈가 Closed 되기를 바란다면 - 최선의 방법은 개발팀이 BVT를 통과하는 빌드를 만들어 내는 것이라는 점을 개발팀에 설명하라.)
8. 남은 문제들
1) BVT 내용에 대해서 트집을 잡는 경우를 주의하라. 다시 강조하지만 BVT 요소에 대해서 개발팀 및 PM과 협의를 거쳐야 한다. BVT 정책을 수행한다는 내용과 함께 BVT 내용에 대해서도 Confirm을 받아 둔다.
2) BVT에 대해서 가급적 테스트 하는 사람에 따라서 결과가 달라질 수 있는 요소는 배제하라. 보는 사람에 따라(테스팅 하는 사람에 따라) BVT Pass / Fail이 달라지는 요소는 차후에 더 큰 이슈를 불러 온다.
3) 어느 수준에 이른 빌드는 이미 BVT는 가볍게 통과할 수 있다. 이때는 BVT 요소의 변경 / 추가 / 삭제를 고려해 보라. (물론 개발팀은 힘들게 달성한 BVT통과 수준이기 때문에 거부할 지도 모른다.)
------------------------------------------------------------------------------------------
Further Reading
아래에 BVT에 관해 언급하고 있는 참고 도서를 곁들여 보시면 더욱 좋습니다.
The Art of Project Management (마음을 움직이는 프로젝트관리) by 스콧 버쿤 pp. 419
일일 빌드를 수행할 경우, 체크인한 코드가 다른 부분에 피해를 입히면 프로그래머가 (그리고 전체 팀이) 이 사실을 즉각 알게 됩니다. 따라서 체크인 코드 품질이 높아집니다. 당일 빌드에 포함될 코드는 특정 시각까지 제출하게 하십시오. 그런 다음, 코드 기반을 안정화한 후 테스트를 수행하여 빌드 품질을 확인합니다. (흔히 이와 같은 일일 테스트를 동작 테스트_smoke test라고도 합니다. 전자 부품을 테스트하는 기법으로, 회로에 전기를 흘려서 글자 그대로 연기가 나는 부분이 있는지 확인합니다) 정해진 시간 이후에 체크인하는 코드는 다음 빌드에 포함됩니다.
빌드를 할 때마다 빌드 품질을 평가하는 테스트 집합이 있어야 합니다. 평가 기준은 합격 (모든 테스트 통과), 보류 (일부 테스트만 통과), 불합격 (몇몇 테스트만 통과 또는 모든 테스트 실패)이라는 세 단계 정도면 충분합니다. 테스트 실패 원인으로 파악된 버그는 빌드 정보에 기록하고 우선 순위를 높게 매겨야 합니다.
(중략)
Lessons Learned in Software Testing (소프트웨어 테스팅 법칙 293가지) by Cem Kaner외 2인 pp. 226
법칙 173. 때로는 빌드에 대한 테스트를 거부해야 한다.
때때로 빌드를 거절하고, 빌드에 대한 테스트를 거부해야 한다. 이와 같이 하는 것의 합리적, 기술적인 이유는 다음과 같다.
* 이번 빌드에서는 중요한 기능이 추가되었는데, 이 빌드에 존재하지 않는 기능이 있다는 것을 알아채거나 실행하자마자 오류가 발생하였다면 더 이상 테스트를 진행하는 것은 시간 낭비이다.
(중략)
법칙 174. 빌드를 평가하기 위하여 연기 테스트를 사용하라.
연기 테스트(일명 온전성 확인 또는 테스트 수락)는 빌드의 기본적인 기능성을 점검하기 위한 테스트 스위트이다. 만약 빌드가 이 테스트에 실패한다면 해당 빌드는 불안정하여 테스트할 가치가 없다고 말할 수 있다.
(중략)
Systematic Software Testing by Rick D. Craig and Stefan P. Jaskiel
스모크 테스트(Smoke Test)
스모크 테스트는 시스템이 안정적인가, 모든 주요 기능들이 존재하며 "일반적인" 상황에서 제대로 작동하는가를 입증하기 위한 테스트 케이스들의 집합입니다. 스모크 테스트의 목적은 소프트웨어의 모든 버그를 찾는 것이 아닙니다. 시스템을 테스트하는 팀에게 어디에서부터 테스트를 시작 해야 하는지 알게 해 주는 것입니다. 이 테스트는 개발자들에게 목표을 제공하며, 언제 개발자들이 '안정성을 보유한 단계'를 달성하게 되는 지를 알려줍니다.
중요 요점: Smoke test는 시스템이 안정적인가와 모든 주요 기능들이 존재하며, "일반적인" 상황에서 제대로 작동하는가를 입증하기 위한 테스트 케이스들의 집합입니다.
(중략)
Sustainable Software Development: An Agile Perspective by Kevin Tate
Practice 5. Nightly Builds
당신의 팀이 소프트웨어가 동작한다고 확신하기 위해서는 하루에도 몇 번씩 원소스로부터 완전하게 빌드가 생성되어야 한다. 그 빌드에는 통합의 문제를 일찍 발견해 내기 위해 가능한 한 많은 수의 자동화된 테스트를 담고 있어야 한다. 그리고 빌드의 결과는 설치 가능한 제품 이미지이어야 한다. 밤시간은 이러한 작업을 하기에 적당한 시간인데, 아무도 코딩을 하고 있지 않고, 놀고 있는 컴퓨터가 매우 많기 때문이다. 그럼에도 불구하고 가능한 한 낮에 많은 수의 제품을 빌드하는 것에 매우 많은 장점들이 있다. 만일 빌드나 테스트가 실패한 경우, 아침에 가장 먼저 할 일은 문제를 수정하는 것이다. 빌드가 다시 성공할 때까지는 아무도 자신의 추가 작업을 통합하지 못하게 하라. 그렇지 않으면, 잘못된 변경 사항이 누적되어 제품에 품질을 위태롭게 할 위험성이 있다.
(중략)
소프트웨어 프로젝트 생존전략 (Software Project Survival Guide) by 스티브 맥코넬 pp. 277
일별 빌드와 스모크 테스트 절차에서는 전체 프로그램이 날마다 빌드 된다. 즉 프로그램의 모든 소스 파일이 날마다 컴파일, 링크되어 실행 파일로 생성된다는 것이다. 그후 소프트웨어는 ‘스모크 테스트’를 거치는데, 이는 실행 중에 소프트웨어에서 ‘연기가 나거나’ 깨지지는 않는지 확인하는 비교적 간단한 테스트를 말한다. 스모크 테스트라는 용어는 전기 공학에서 나온 것인데, 글자 그대로 전기 장치를 켰을 때 연기가 나는지 검사하는 것이다.
날마다 일별 빌드와 스모크 테스트를 실시하면서, 빌드되지 않는 데에 책임 있는 개발자를 추적하고 그 원인을 수정하게 하려면 어느 정도 노력이 필요하다. 작은 규모의 프로젝트에서는 품질 담당자가 자신의 다른 업무를 병행하면서 일별 빌드를 수행한다. 좀더 큰 규모의 프로젝트에서는 전담 인원이나 전담 팀이 일별 빌드를 수행할 수도 있다.
스모크 테스트는 소프트웨어 개발에 보조를 맞추기 위해 프로젝트 전반에 걸쳐 업데이트해야 한다. 또한 날마다 실시해야 하기 때문에 대부분이 자동화하여 실행한다. 스모트 테스트는 모든 것을 철저하게 확인해야 하는 테스트는 아니지만, 그날의 빌드가 테스트할 수 있을 만큼의 안정성을 지닌 소프트웨어 기능인지 확인해야 한다. 소프트웨어가 테스트할 수 없을 만큼 불안정하다면, 그 소프트웨어는 스모크 테스트를 하지 말아야 한다.
(중략)
Game Testing All In One by Charles P. Schultz 외 2인
Entry Criteria
어떤 형태의 테스팅을 수행하더라도 사전에 테스트에 적합한지에 대한 어떤 통과 기준에 코드 릴리즈가 적합한지 확인하는 것이 권장된다. 이것은 우주 여행사나 파일럿이 비행 전에 항공 시스템이 운행에 적합한지 점검하는 체크리스트와 유사하다. 테스팅을 위해 제출된 빌드가 기본적인 진입 기준에 미달하는 경우 테스터와 프로그래머 둘 모두의 시간을 낭비하게 될 가능성이 많다. 테스팅의 카운트다운은 테스트 "발사" 통과 조건을 충분히 만족할 때까지 중단되어야 한다.
아래의 진입 기준으로 사용할 수 있는 제안들을 나열해 두었다. 반드시 개발팀의 인원들에게는 이 내용을 비밀로 하지 마라. 그 팀이 이것의 목적을 인식하고 (시간 낭비를 방지하기 위해) 전체 팀이 공감할 수 있는 통과 기준의 집합을 그들과 함께 만들도록 하라.
(중략)
PS1) 아마 이 내용의 핵심을 이해하고 그대로 시행한다면 프로젝트에서 여러 분들은 구원(?) 받을 겁니다.
PS2) 어떤 내용이든 참조를 하시고 도움이 되었다면 원전 표기와 레퍼런스 명기를 꼭! 잊지 마세요.
PS3) 이 글의 반응 강도에 따라서 제가 실전에서 사용하고 있는 엑셀 템플릿을 공개하겠습니다. ^^
반응형
댓글 영역