책 발췌 – 정적 테스팅에 관하여 by Everett and McLeod

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

6장 Static Testing, 93~98페이지

 

 

정적 테스팅의 목표

소프트웨어 개발 프로젝트는 코드뿐만 아니라 문서도 생성한다. 문서는 소프트웨어 자체를 형성하는 것부터 최종 사용자의 성공적인 소프트웨어 사용을 지원하는 것까지 다양한 목적으로 사용된다. 이 문서를 테스팅하는 프로세스를 정적 테스팅(static testing)이라고 한다. 이 문맥에서 "정적(static)"이라는 용어는 "가동 중이 아님(not while running)" 또는 "실행 중이 아님(not while executing)"을 의미하며, 소프트웨어 실행을 통해 테스트를 하는 것과 대조적으로 사용된다.

 

정적 테스팅은 비용이 가장 적게 드는 테스팅 형태이며, 개발 중인 소프트웨어의 결함을 줄이는 데 가장 큰 잠재력을 가지고 있다. 정적 테스팅의 주요 목표는 소프트웨어 개발의 기반인 문서의 결함을 줄여 소프트웨어의 결함을 줄이는 것이다. 부수적인 목표는 소프트웨어의 올바른 사용(오퍼레이션)이다. 이 말이 당연한 것처럼 들릴 수 있지만, 최종 사용자가 일상 비즈니스를 수행하는데 있어 소프트웨어를 올바르게 작동하는 방법을 알 수 없기 때문에 수백만 달러를 투자한 소프트웨어 시스템이 버려지는 일이 적지 않다. 인간 본성상, 형편없는 문서화와 교육을 받은 사람들은 "이 소프트웨어를 어떻게 작동하는지 알아내겠다"라고 말하지 않는다. 오히려 그들은 "이 소프트웨어는 나에게 필요한 작업을 수행하지 않으므로 이전 시스템으로 돌아가고 싶다"라고 말한다.

 

 

정적 테스팅을 위한 후보 문서

정적 테스팅의 대상이 되는 소프트웨어 개발 문서의 대표적인 목록이 아래와 같다.

 

소프트웨어 개발 관리자의 문서

(a) 소프트웨어 요구사항(Software requirements)

(b) 소프트웨어 프로젝트 계획서(Software project plans)

 

소프트웨어 개발자의 문서

(a) 유스케이스(Use cases)

(b) 소프트웨어 설계서(Software designs)

(c) 소프트웨어 사양서(Software specifications)

(d) 데이터 흐름도(Data flow diagrams)

(e) 데이터베이스 및 파일 설계서(Database and file designs)

(f) 온라인 운영 환경 사양서(Online operating environment specifications)

(g) 배치 운영 환경 사양서(Batch operating environment specifications)

(h) 인터페이스(Interfaces)

(i) 커넥티비티(네트워크) 사양서(Connectivity (network) specifications)

(j) 보안 사양서(Security specifications)

(k) 화면/윈도우/페이지 사양서(Screen/window/page specifications)

(l) 보고서 사양서(Report specifications)

(m) 코드(Code)

 

테스터의 문서

(a) 테스트 계획서(Test plans)

(b) 테스트 케이스(Test cases)

(c) 테스트 환경 사양서(Test environment specifications)

(d) 테스트 데이터 소스 및 준비(Test data sources and preparation)

(e) 테스트 툴 설치 및 운영(Test tool installation and operation)

 

시스템관리자(Administrator)의 문서

(a) 설치 가이드(Installation guides)

(b) 운영/관리 지침(Operation/administration guides)

 

최종 사용자의 문서

(a) 사용자 가이드(Users guides)

(b) 도움말 화면(Help screens)

(c) 교육 매뉴얼(Training manuals)

 

 

정적 테스팅 기법

정적 테스팅은 소프트웨어 개발 팀 구성원 간 높은 수준의 인터액션을 필요로 하기 때문에 이 테스트 활동을 “객관적(objective)”이고 “개인 감정이 개입되지 않도록(impersonal)” 유지하는 것이 가장 어려운 점이다. 문서에 대한 공격을 그 소유자/작성자에 대한 인신 공격으로 받아들일 정도로 문서 오너쉽(ownership)을 가지는 인간의 경향이 이를 더 어렵게 한다. 사실 문서 오너쉽은 좋은 것이다. 이는 작성자가 최선을 다해 작업을 수행하고 양질의 결과에 대한 자부심을 갖게 만든다. 정적 테스팅은 이미 좋은 품질일 수 있는 문서에 대한 수정 및 개선 사항을 식별하는 데 도움을 줌으로써 소유자/작성자가 가능한 최상의(가장 정확한) 문서를 생성할 수 있도록 돕고자 한다. 오너쉽 대한 자부심은 프로그램 코드에서 정점에 도달한다. 대규모 소프트웨어 애플리케이션이 100% 무결함일 수는 없기 때문에 모든 프로그램 코드에는 개선의 여지가 있다. 정적 테스팅은 이러한 개선 사항을 확인하는 가장 비용 효율적인 방법 중 하나이다.

 

정적 테스팅에 2단계 접근 방식을 사용하자. 첫 번째 단계에서는 철자 확인, 문법 확인, 구두점 확인, 서식 확인 등 문서의 외관을 정리한다. 첫 번째 단계 수행의 이점은 문서가 외관상 깨끗해지면 독자가 콘텐츠에 집중할 수 있다는 것이다. 첫 번째 단계를 건너뛰어 문서 외관이 깨끗하지 않은 경우 독자가 의미를 찾기 위한 문서 읽기를 중단하고 교정에 치중하게 될 것이며, 이는 콘텐츠 검토에 해가 된다. 두 번째 단계에서는 문서 콘텐츠의 전문가 검토에 집중하는 데 적합하다고 생각되는 기술을 사용한다. 다음은 콘텐츠 검토를 위한 대표적인 정적 테스팅 기법이다.

• 데스크 체킹(desk checking)
• 인스펙션(inspections)
• 워크쓰루(walk-throughs)

 

데스크 체킹은 가장 형식적이지 않고 가장 시간 소모가 적은 기법이다. 정적 테스팅 기법 중에서 데스크 체킹은 작성자가 자신의 문서를 직접 테스트하도록 권장하는 유일한 방법이며 나머지 기법들은 보다 철저하고 객관적인 검토를 위해 독립적인 눈에 의존한다. 데스크 체킹은 먼저 맞춤법 검사기, 문법 검사기, 구문 검사기 또는 문서의 외관을 정리하는 데 사용할 수 있는 모든 도구를 실행하는 작업을 한다. 그런 다음 작성자가 불일치, 불완전성, 누락된 정보를 찾기 위해 문서를 천천히 검토한다. 콘텐츠에서 발견된 문제는 프로젝트 관리자 및 프로젝트 관련 전문가의 조언을 받아 작성자가 직접 수정해야 한다. 모든 수정이 완료되면 앞의 외관 테스트를 다시 실행하여 콘텐츠 수정으로 인해 발생한 모든 철자, 문법 및 구두점 오류를 찾아 수정한다.

 

인스펙션은 데스크 체킹보다 좀 더 형식적이고 시간이 더 많이 소요된다. 또한 이 기법은 데스크 체킹보다 더 많은 문서 결함을 찾아낸다. 이 기법의 의도는 독립적인 눈(대개 팀의 시니어 멤버)으로 문서를 읽고 콘텐츠 문제를 발견하도록 하는 것이다. 데스크 체킹에서처럼 인스펙션 대상 문서는 독립적인 독자가 콘텐츠에 집중할 수 있도록 작성자가 가능한 한 외관을 깨끗하게 만들어야 한다. 그러고 나면 독립적인 독자는 문서를 다른 곳으로 가져가서 검토한다. 문서를 그 작성자로부터 분리하는 것은 문서 자체를 있는 그대로 볼 수 있도록 한다. 검토자가 작성자 앞에서 문서를 검사하면 작성자가 검토자에게 참견하는 경향이 있으며 이는 독립적인 검토의 목적에 어긋난다. 독립적인 검토자는 콘텐츠에서 의심되는 문제를 문서화하고, 후속 회의에서 작성자에게 제시한다. 그러면 작성자는 의심되는 문제에 대한 시정 조치를 제안해야 한다. 이어서 프로젝트 관리자 또는 프로젝트의 고위 관계자가 검토자의 의심스러운 문제 목록을 검토하고 작성자가 제안한 시정 조치를 검토하여 합의된 시정 조치를 협상한다.

 

워크쓰루는 가장 공식적이고 시간이 많이 소요되는 문서 테스팅 기법이지만 콘텐츠 문제를 식별하는 데 가장 효과적이다. 워크쓰루는 진행자(facilitator), 문서 작성자, 시니어 기술 직원 및 비즈니스 직원이 청중으로 참여하는 예정된 회의이다. 문서 작성자는 문서의 외관상 오류를 제거하고 회의에 앞서 모든 참가자에게 문서를 보낸다. 참가자들은 문서를 읽고 새로운 시스템/애플리케이션에 대한 자신의 지식을 바탕으로 문서 콘텐츠에 대한 질문을 작성한다. 예정된 시간에 작성자는 워크쓰루 회의에서 자신의 문서를 발표한다. 진행자는 청중의 질문과 작성자의 답변이 원활이 교환되도록 한다. 진행자는 또한 질문이 객관적이고 위협적이지 않은 방식으로 제기되도록 한다. 워크쓰루 진행자는 프로젝트 관리자가 나중에 해결할 수 있도록 모든 의심되는 콘텐츠 문제와 작성자 응답을 문서화한다.

 

 

정적 테스팅에서 발견된 결함 추적

위에 설명한 정적 테스팅 기법 모두는 의심되거나 또는 확인된 콘텐츠 문제, 제안되거나 또는 협상된 시정 조치, 그리고 시정 완료 일자를 기록하는 일을 포함한다. 이러한 목록은 스프레드시트와 같은 간단한 도구나 데이터베이스와 같은 복잡한 도구를 사용하여 관리할 수 있다. 어느 쪽이든 이러한 결함을 기록하고 시정될 때까지 추적해야 하는 두 가지 강력한 이유가 있다. 첫 번째 이유는 시정 사항이 실제로 테스트된 문서에 적시에 적용되었는지 프로젝트 관리에서 확인할 수 있도록 하는 것이다. 두 번째 이유는 프로젝트의 초기 성공에 있어 현재의 올바른 문서화의 중요성을 보여주기 위한 것이다. 문서를 올바르게 작성하라고 상기시키기 위한 결함 추적을 하지 않으면 "코드를 작성한 후에 문서에 기록하겠습니다"라는 태도가 늘어날 것이며, Capers Jones의 우울한 예측이 우리 프로젝트에서도 현실이 될 것이다.

 

 

NOTE 1.

Capers Jones의 소프트웨어 결함의 근원(source)에 대한 연구에 따르면, 모든 소프트웨어 결함의 85%가 코드가 실행되기 전에 개발 초기 단계에 도입된다고 한다. 코드 실행이 전혀 없다면 이 산더미 같은 결함의 근원은 무엇일까? 답은 문서이다. 즉 요구사항, 사양서, 데이터 설계, 프로세스 설계, 인터페이스 설계, 데이터베이스 구조 설계, 플랫폼 설계, 커넥티비티 설계 등이다.

결함 비율, Applied Software Measurement, Capers Jones, 1996년

 

NOTE 2. 
이 책에서는 리뷰 기법 중 워크쓰루를 가장 형식을 갖춘 기법으로 분류하였지만, 워크쓰루보다 인스펙션을 더 엄격하고 공식적인 검토 기법으로 간주하는 경우도 있다.