책 요약 – 테스팅 체크리스트에 관하여 by Everett and McLeod

출처: 책 Software Testing: Testing Across the Entire Software Development Life Cycle, by G. D. Everett and R. McLeod, Jr., 2007년

3장 Overview of Structured Testing, 59~61페이지

 

 

 

항공업계 사례로 보는 체크리스트의 가치

1930년대 중반 항공기는 금속 외피와 상당 거리(500마일)를 높고(10,000피트) 빠르게(100mph) 비행할 수 있는 강력 엔진을 갖춘 복잡한 기계였다. 유럽 전역에 전쟁 구름이 형성되기 시작했고, 유럽 분쟁에 개입할 가능성에 대비하여 미 육군 항공대(the U.S. Army Air Corps)는 현존하는 모든 항공기보다 더 높이(20,000피트), 더 빠르게(250mph), 더 멀리(1000마일) 비행할 수 있는 "다중 엔진 폭격기"를 제작할 것을 미국 항공기 제조업체에 요청했다. 새로운 항공기는 이 모든 요구를 충족하면서 2톤 하중(폭탄)을 탑재해야 했다. 항공기 제조업체인 마틴 사, 더글라스 사, 보잉 사가 이에 응답하여 계획서와 비행 프로토타입을 내 놓았다. 첫 번째 비행 테스트에서 보잉의 Model 299 프로토타입이 마틴의 146이나 더글라스의 DB-1보다 성능이 좋았다. 게다가 Model 299는 모든 정부 사양을 초과하는 것으로 나타났다. 경쟁사가 참여하는 마지막 한 번의 의무 비행을 치르고 나면 보잉 사가 새로운 폭격기 18대의 정부 계약을 따내는 수순인 것만 같았다.

 

1935년 10월 30일, 보잉 모델 299 프로토타입이 최종 승인 비행을 위해 이륙했고... 곧 땅으로 추락하여 탑승자 전원이 사망하고 프로토타입은 완전히 파괴되었다. 정부 입찰 규칙에 따라 새로운 폭격기 계약은 프로토타입이 최종 승인 비행을 무사히 마친 2위 마틴 사에게 돌아갔다.

 

보잉 모델 299 프로토타입에 무슨 일이 있었던 걸까? 보잉이 이 질문에 대한 답을 얼마나 빨리 원했을 지 상상하는 것은 어렵지 않다. 경제적인 관점에서 볼 때 보잉 사가 이미 심각한 재정난에 처해 있었기 때문에 정부 계약을 잃으면 파산하게 될 수 있었다. 엔지니어링 관점에서는 보이지 않는 설계 결함으로 인해 보잉의 새로운 항공기 설계가 정부와 상업 시장 모두에서 버림받게 될 수도 있었다.

 

보잉은 매우 집중적인 조사 끝에 모델 299 프로토타입 추락의 원인을 발견했다. 좋은 소식은 추락이 잘못된 설계나 잘못된 구축으로 인해 발생한 것이 아니라는 것이었다. 조사 결과 부적절한 조종사 행위도 없었다. 프로토타입의 테스트 파일럿은 업계 최고 수준이었다.

 

이 추락은 이륙 전에 엘리베이터(테일 제어) 잠금 장치가 제거되지 않아서 발생했다. 이러한 제어 잠금 장치는 항공기가 공항에 주차할 때 경첩 달린 표면이 바람에 의해 움직여 손상되는 것을 방지하기 위해서 일반적으로 모든 제어 표면(에일러론, 방향타, 엘리베이터)에 배치된다. 이 추락 사고가 발생했을 당시 이러한 제어 잠금 장치를 제거하는 책임이 누구에게 있는지에 대해 지상 승무원과 조종사 사이에 표준적인 이해가 없었다. 따라서 두 그룹 모두 다른 그룹이 제어 잠금 장치를 제거했다고 가정하면 제어 잠금 장치는 그대로 유지되어 이륙 중에 제어 장치가 정지되고 치명적인 결과가 발생한다.

 

이 문제에 대한 해결책은 매우 단순했다. 이제는 어디서나 볼 수 있는 조종사의 비행 전 체크리스트(pilot’s preflight checklist)이다. 비행 전 체크리스트는 숙련된 조종사가 체크리스트의 각 조치가 이륙 전에 완료되었는지 확인한 경우에 안전 리스크를 최소화하면서 이륙을 성공적으로 반복할 수 있도록 보장한다.

 

 

소프트웨어 테스터의 체크리스트 멘탈리티

전문 소프트웨어 테스터들은 비행 전 체크리스트처럼 자신들의 업무상 주의사항(professional caveats)을 포함하는 체크리스트가 성공적인 테스트 프로젝트를 보장하는 탁월한 방법임을 발견했다.

 

업무상 주의사항이란 무엇일까? 비행을 하는 조종사이든 소프트웨어를 테스트하는 테스터이든 체크리스트를 선택하기 전에 업무상 전제조건(the professional prerequisites)을 고려해야 한다. 체크리스트의 목표는 모든 체크리스트 질문에 대해 "예, 그걸 확인했습니다"라고 말할 수 있는 것이다. 예를 들어 항공기 비행 전 체크리스트에는 "비행 제어가 자유롭고 정확한가?"라는 질문이 들어있다. 이는 15~20개의 질문 목록 중 하나의 짧은 질문에 불과하다. 조종사 면허증을 소지한 사람이라면, 자신의 비행 경험(지상 학교 2주, 40시간의 비행 지도, 조종사 면허증, 조종사로서 100~5000시간의 비행)을 통해 무엇이 꿈틀거려야 하고 날개 표면 움직임은 어떠해야 하는지를 알고 있으며, 따라서 스스로에게 "네, 그것을 확인했습니다"라고 말할 수 있다.

 

모든 전문 소프트웨어 테스팅 체크리스트에는 "테스트 성공이 정의되었는가?" 라는 질문이 들어 있다. 여러 테스트 프로젝트를 성공적으로 완료한 경험이 있는 사람이라면, 테스트 프로젝트 계획 전에 언제 우리 테스트를 종료하는지 구분할 줄 아는 것이 중요함을 경험하였으며, 따라서 "예, 그것을 확인했습니다"라고 말할 수 있다.

 

조종사의 비행 전 체크리스트는 항공기 제조업체에서 제공한다. 소프트웨어 테스팅 체크리스트는 어디서 오는 것일까? 항공기와 달리 일반적으로 소프트웨어는 공장에서 테스팅 체크리스트와 함께 제공되지 않는다. 소프트웨어 테스팅 체크리스트는 역사적으로 세 가지 다른 소스에서 나왔다.

 

• 다년간의 내부 조직 경험을 통해 시행착오(고통과 괴로움)를 거쳐 개발된 기업 맞춤형 체크리스트.
• 컨설팅 회사에서 상업적으로 제공하는 표준 체크리스트. 일반적으로 "방법론(methodology)", "방법(method)", "프로세스(process)" 또는 "프레임워크(framework)"라고 하며, 수년간 많은 고객과의 경험을 통해 개발됨
• 컨설팅 회사가 수년간 많은 고객과의 경험을 통해 개발한 맞춤형 프로세스를 통해 상용으로 제공하는 맞춤형 체크리스트(customized checklist).

 

저자는 이 세 가지 소스에서 나온 12개 이상의 테스팅 체크리스트를 업무상으로 접했다.

 

다양한 테스트 체크리스트를 면밀히 검토하면 두 가지 사항을 빠르게 관찰할 수 있다. 첫째, 체크리스트를 피상적으로 비교하면 각 체크리스트가 모두 매우 고유하다는 결론을 내릴 수 있다. 그러나 추가 연구는 이러한 고유성(uniqueness)이 주로 여러 조직이 선택하는 용어 및 개발 단계의 차이에서 발생하는 것임을 알려준다. 테스트 용어는 보통 조직의 개발 용어와 밀접하게 연관되어 있는데, 이러한 바인딩이 반드시 테스트를 더 효과적이거나 고유하게 만드는 것은 아니다. 이 바인딩은 관련 개발 팀이 테스트를 더 쉽게 이해하도록 만들 수는 있다.

 

둘째, 각 테스트 체크리스트의 핵심에는 동일한 질문이 있다. 사실상 대부분의 전문 테스터는 성공적인 테스트를 위해 공통의 체크리스트를 사용하고 있다. 미심쩍은 독자에게는 모든 소프트웨어 테스팅이 하나의 강력하고 일반적인 테스팅 체크리스트를 사용하여 수행될 수 있다는 주장의 증거가 필요할 것이다. 이 장의 나머지 부분에서는 SPRAE라고 하는 하나의 강력하고 일반적인 테스트 체크리스트의 예를 소개하고자 한다.