소프트웨어 프로젝트 생존전략 by 스티브 맥코넬

자 유명한 스티브 맥코넬의 저서 "소프트웨어 프로젝트 생존전략"에서 테스팅을 언급한 부분을 발췌했다. 소프트웨어 테스터들이 간과하는 사실중에 하나는 프로젝트 관리 / 프로젝트 / 개발 등은 소프트웨어 테스팅과 QA와 아주 밀접한 관계가 있다는 것이다. 따라서, 프로젝트 관리 서적 중에서도 테스팅에 대한 언급은 수도 없이 많다. 아직도 소프트웨어 테스팅 서적만 탐독하던 분들은 반성하시라. 지혜와 지식이 더해갈수록 "프로젝트 관리"라는 녀석과 맞닥들이게 될 것이다. ^^

pp. 177

9장 품질 보증

예전에는 소프트웨어 품질 보증을 전적으로 테스트 단계에서 하는 것으로 생각했다. 그러나 효율적인 프로젝트에서의 품질 보증은 이제 테스트, 테크니컬 리뷰, 프로젝트 계획 등과 같이 프로젝트 초기에 경제적인 방법으로 결함을 발견하여 수정하기 위한 모든 방법을 포함한다.

사람들이 말하는 '품질'에는 서로 다른 많은 의미가 있다. 그것은 시스템이 죽지 않는 것일 수도 있고, 소프트웨어가 사용자 기대에 부응하는 것일 수도 있고, 프로그램에 기대하는 막연한 완성도일 수도 있다. 명시된 요구사항을 만족시키는 것일 수 있고, 처음에 요구사항을 올바르게 정하는 것일 수도 있다. 품질에 대한 합리적이고 일반적인 정의는 '소프트웨어가 명시적 암시적 요구사항을 모두 충족하는 정도'다. 이 장은 이러한 종류의 품질을 보증하는 방법에 대해 설명한다.

품질이 중요한 이유

소프트웨어의 신뢰성을 완벽하게 보장할 수 없다 하더라도 결함을 꾸준히 통제 아래 두는 것은 중요하다. 왜냐하면 이들 결함이 개발 속도와 개발 비용 및 프로젝트의 기타 특성에도 영향을 미치기 때문이다. 제3장 '생존의 개념'에서 설명한 상류/하류 효과와 같이, 상류가 아닌 하류에서 결함을 발견하여 수정하면 50~200배의 비용이 더 든다. 이것만으로도 품질에 초점을 맞춰야 할 이유가 충분하지만 다른 근본적인 이유도 있다.

사람들은 현재 프로젝트에서 품질 문제를 빨리 건너뛰고, 다음 프로젝트에서 이를 수정할 수 있을 거라 생각한다. (한두 달 안에 끝낼 수 있는) 아주 작은 규모의 프로젝트에서는 감독자를 속일 수도 있다. 그러나 더 많은 시간이 걸리는 프로젝트에서 품질 문제를 대충 건너뛰는 것은 스스로 무덤을 파는 일이다. 대충 건너뛴 품질 문제 때문에 발생하는 부작용을 다음 프로젝트로 또 연기할 수도 없고, 이런 부작용은 바로 현재의 프로젝트에 영향을 미칠 것이다.

소프트웨어 품질은 비즈니스 비용에 근본적인 영향을 끼친다. 저질의 소프트웨어 때문에 최종 사용자를 지원하는 부담이 증가한다. 마이크로소프트와 같은 선도 업체들의 경우 이런 최종 사용자 지원 비용을 기술 지원 소프트웨어를 제작했던 부서가 떠맡아야 했다.

저질의 소프트웨어를 개발하고 이를 불안정한 기초 위에 구축하는 것은 유지보수 비용도 증가시킨다. 여러분은 프로그램 수명이 3~5년 정도일 것이라 생각하겠지만, 일반적인 프로그램은 이를 지원하는 유지보수 개발자를 평균 10번 가량 거칠 정도로 오랫동안 유지된다. 프로그램 생존 비용 중 50~80퍼센트는 일반적으로 최초 릴리스 이후 발생하므로, 경제면에서 볼 때 최초 버전을 성공적인 기초 위에 구축하는 것이 바람직하다.

결국, 저질의 소프트웨어를 릴리스 하여 여러분의 비즈니스에 어떤 영향이 돌아오게 할지를 결정할 사람은 바로 여러분 자신이다. 고객들은 그 소프트웨어가 사용하기 좋은지 여부를 기억할 뿐이며, 양질의 소프트웨어가 늦게 릴리스 되는지 혹은 저질의 소프트웨어가 제때에 릴리스 되는지는 중요하지 않다.

신속하지만 얼룩이 남는 문제는, 누군가 말했듯이 신속에서 오는 장점이 잊혀진 후에도 얼룩은 오랫동안 남는다는 것이다.

품질 보증 계획

이 책의 주제 가운데 하나는, 성공적인 소프트웨어 프로젝트를 원하는 조직이라면 반드시 프로젝트의 생존에 전념해야 한다는 것이다. 소프트웨어 프로젝트의 생존을 위해서는 적어도 다음 요소들을 포함하는 품질 보증에 전념해야 한다.

• 소프트웨어 품질 보증 활동에 대한 계획을 세워야 한다.
• 소프트웨어 품질 보증 활동 계획을 반드시 문서화해야 한다.
• 소프트웨어 품질 보증 활동은 소프트웨어 요구사항 활동 혹은 그 이전에 시작해야 한다.
• 소프트웨어 품질 보증을 전담하는 별도 부서가 반드시 있어야 하고, 프로젝트의 규모에 따라 한 명으로 구성될 수도 있다. 서로 다른 프로젝트에서 개발자 한 명씩 교환하여 각 프로젝트에 대해 품질 보증 활동을 수행하게 할 수도 있다.
• 이 부서의 구성원들은 소프트웨어 품질 보증 활동을 어떻게 수행하는지 교육을 받아야 한다. 단지 상급 개발자가 "여보게, 자네는 이제부터 품질 보증 부서 소속이라네."하는 것만으로는 충분치 않다.
• 소프트웨어 품질 보증 활동을 수행하기 위한 적당한 자금을 제공해야 한다.

품질 보증 계획의 요소

효과적인 품질 보증 계획은 결함 추적, 단위 테스트, 소스 코드 추적, 테크니컬 리뷰, 통합 테스트, 시스템 테스트 등의 품질 보증 작업을 포함한다.

결함 추적은 이러한 품질 보증 활동 전반에 걸쳐 수행된다. 프로젝트 팀은 결함이 발견되면 해당 소스, 발견된 때, 해결된 때, 해결 방법(수정되었는지에 상관없이) 등에 대해 기록해두어야 한다. 결함 추적은 프로젝트의 추적과 통제에 있어 핵심적인 요소다. 훌륭한 결함 정보는 프로젝트의 릴리스 시기가 어떻게 될지, 품질은 어떤지 그리고 어디에서 개발 프로세스의 효율성을 획기적으로 향상시킬 수 있는지를 파악하게 도와준다.

단위 테스트는 개발자가 자신이 작성한 소스코드를 비공식으로 테스트하는 것이다. '단위'라는 용어는 서브루틴, 모듈, 클래스 혹은 이보다 더 큰 프로그래밍 항목을 의미할 수 있다. 단위 테스트는 보통 비공식으로 수행되지만, 해당 단위를 마스터 파일(master source)에 통합하거나 별도의 리뷰나 테스트로 넘겨지기 전에 반드시 수행되어야 한다.

소스코드 추적은 디버깅 도구를 사용하여 소스코드를 한 라인씩 진행시키는 것이다. 이 작업은 해당 소스를 개발한 개발자가 수행한다. 이 작업이 코드의 결함을 발견하는 아주 가치 있는 방법임이 많은 개발자들에 의해 입증됐으며, 필자의 경험도 마찬가지다. 개발자들이 자신의 코드를 통합시키기전에 디버거를 통해 한 스텝씩 진행시켜보면 그렇지 않은 경우보다 통합 문제가 훨씬 적게 발생한다.

테크니컬 리뷰는 개발자가 자신의 동료들이 완료한 작업을 리뷰(review)하는 것이다. 이러한 리뷰는 사용자 인터페이스 프로토타입, 요구 명세서, 아키텍쳐, 설계 및 기타 기술적 산출물의 품질을 보증하기 위한 것이다. 테크니컬 리뷰는 새로운 소스코드와 변경된 소스코드들까지 리뷰해야 하며, 보통 개발팀에 의해 수행된다. 품질 보증 담당자는 테크니컬 리뷰가 제대로 수행되고 있는지 그리고 리뷰 시기 동안 결함이 추적되고 있는지 확인해야 한다.

통합 테스트는 새로 개발된 코드를 기존의 통합된 코드에 결합시키는 과정이다. 이런 종류의 테스트는 해당 신규 코드를 개발한 개발자가 비공식(informally) 1) 으로 수행한다.

시스템 테스트는 결함을 찾아내기 위해 소프트웨어를 실행시키는 것이다. 시스템 테스트는 별도의 테스트 조직이나 품질 보증 팀에서 수행한다.

이 같은 품질 보증 활동들을 모두 수행한다는 것이 대단한 부담으로 느껴질 수 있다. 그러나 실제로 수행해보면 오히려 그 반대다. 이와 같은 여러 단계(단위 테스트에서 시스템 테스트까지)에 걸치 품질 보증 방식은 많은 결함을 가능한 빨리 발견하여 결함 수정에 따르는 비용을 줄일 수 있다.

결함 추적
{생략}

테크니컬 리뷰
{생략}

시스템 테스트

리뷰가 소프트웨어 품질을 상류에서 향상시키기 위한 핵심적인 방법이라면, 시스템 테스트는 하류에서 향상시키기 위한 핵심적인 방법이다. 다음은 소프트웨어 시스템 테스트를 성공적으로 수행하기 위한 핵심적인 원칙이다.

• 시스템 테스트는 별도의 테스터를 통해 수행하자 효과적인 테스트를 위해서는 소프트웨어를 개발한 개발자가 아닌 다른 사람이 테스트해야 한다. 개발자도 자신의 코드에서 어느 정도 결함을 발견할 수 있지만, 결함을 최대로 발견하기 위해서는 소프트웨어를 '망가뜨려야 한다.'는 식의 발상 전환이 필요하다. 동일한 프로젝트 내에서 이 두 역할을 모두 수행할 수 있는 개발자는 거의 없다.
• 요구사항이 알려지자마자 테스트 계획을 세우자 효과적인 시스템 테스트는 효과적인 계획에 달려 있다. 테스트 사례(테스트 케이스)는 소스코드와 마찬가지로 설계, 리뷰, 구현되어야 한다. 테스트 때문에 릴리스 시기가 미루어지기를 원하지 않는다면, 요구사항이 알려지자마자 가능한 빨리 테스트 계획 수립을 시작해야 한다.
• 제1단계부터 시스템 테스트를 시작하자 단계별 납품 방식에서는 소프트웨어의 실행 파일을 첫째 단계부터 사용할 수 있으므로, 이때부터 시스템 테스트를 시작해야 한다.
• 요구사항 추적표에 모든 요구사항이 포함되어 있는지 확인하자 소프트웨어 시스템 테스트는 소프트웨어 기능을 100퍼센트 포함하도록 계획되어야 한다. 이는 보통 '요구사항 추적성' 이라는 절차를 통해 보장되는데, 이는 요구사항을 행(row)으로 하고 테스트 사례(테스트 케이스)를 열(column)로 하는 커다란 도표다. 행과 열의 '1'은 해당 열의 테스트가 행의 요구사항을 검증하는 데 필요한 것임을 의미한다. 열에 '1'이 없으면, 이 열의 테스트는 요구사항을 검증하는 데 도움을 주지 못하는 불필요한 것이며 따라서 삭제할 수 있다. '1'이 없는 행은 이 행의 요구사항을 검증하기 위한 테스트 사례(테스트 케이스)가 작성되지 않은 것이다. 모든 행과 모든 컬럼은 최소한 한 개의 '1'을 지녀야 한다. 요구사항 추적표를 작성하는 것은 지루한 작업이지만, 소프트웨어의 모든 범위가 테스트되고 있음을 확인하기 위한 최상의 방법이다.
• 시스템 테스트를 위해 충분한 인력을 제공하자. 소프트웨어를 테스트하기 위해 필요한 인력은 개발하는 소프트웨어의 종류에 따라 다르다. 높은 품질로 제작해야 하는 상용 소프트웨어의 경우 개발자 한 명당 테스터 한 명이 적합한데, 마이크로소프트나 기타 선두 업체들도 이 비율을 사용한다. 이만큼의 테스터가 필요한 이유는 테스트 과정을 자동화하여 소프트웨어에 변화가 있을 때, 가끔은 매일 품질 관리자가 처음부터 끝까지 테스트할 수 있게 하려는 것이다. 미션 크리티컬한 업무를 수행하는 비즈니스 시스템의 경우에도 이만큼의 테스트가 필요할 것이다. 생명과 관련된 핵심적 기능을 수행하는 소프트웨어는 훨씬 많은 테스터가 필요하다. 우주선의 비행 통제 소프트웨어의 경우는 개발자 한 명당 10명의 테스터가 투입되었다. 반면에 신뢰성이 심각하게 문제되지 않는 내부 비즈니스 시스템의 경우는 테스트가 더 적게 이루어지며 대략 개발자 3~4명 당 한 명 이하의 테스터가 필요하다. 이 경우, 테스트 사례(테스트 케이스)를 완전히 자동화할 필요는 없으며, 소프트웨어의 신뢰성을 극도로 높일 필요가 없으므로 필요한 테스트도 더 적어진다.
• 테스트에 중독되지 말자 저울에 올라간다고 해서 몸무게가 줄지 않는 것처럼, 테스트 자체만으로는 소프트웨어 품질을 높일 수 없다.

테스트는 소프트웨어 시스템의 품질을 파악하는 것이지 품질을 보장하는 것이 아니다.

테스트와 결함 수정을 결합하여 테스트-수정 작업을 함께 펼치면 소프트웨어의 품질을 높일 수 있지만, 그다지 효율적인 방법이 아니다. 보다 효과적인 방법은 사용자 인터페이스 프로토타잎, 테크니컬 리뷰와 같은 상류의 품질 보증 활동과 하류의 테스트를 병행하는 것이다. 이 방법이 더 경제적이며 효과적이다.

상류에서 품질 보증 활동이 없는 조직은 '테스트 중독'에 빠진다. (* 옮긴이: 품질 보증 조직이 없다는 의미가 아니다. 상류에서의 품질 보증 활동이 없는 조직을 의미한다.) 이런 조직에서 개발된 소프트웨어는 상류 작업이 거의 이루어지지 않았기 때문에 품질이 떨어지며, 너무나 많은 결함을 하류에서 발견해 내야 한다. 결함이 너무 많다 보니 많은 테스터가 필요하고, 이후의 프로젝트에서 효과적인 상류 작업을 위해 필요한 품질 보증 인력을 할당하기도 어려워진다. 하류 테스트 작업에 필요한 인력이 많아질수록 다음 프로젝트에서 상류 작업에 투입될 인력이 적어지고, 따라서 '테스트 중독'은 더욱 악화되어 다음 프로젝트의 하류에 더 많은 문제점이 생기고, 더 많은 하위 단계 테스트가 필요해진다.
이러한 테스트 중독 악순환을 벗어나는 유일한 방법은 이를 악물고 프로젝트의 품질 보증에 필요한 상류 인력을 확보하는 것이다. 한 프로젝트에서 이런 방식의 장점을 맛보고 나면 다음 프로젝트에서 상류 인력을 확보하는 것은 더 쉬워진다.

베타 테스트

이 책의 추천 방식에 의하면 일반적인 품질 보증은 별도 테스트 부서에 의한 테크니컬 리뷰, 시스템 테스트와 같은 내부 절차를 통해 이루어진다. 그러나 표 9-2에서 요약한 것과 같은 다양한 이유 때문에 외부의 베타 테스터에게 소프트웨어를 릴리스하는 회사도 있다. 이런 이유에는 기술적인 것도 있지만 대부분은 기술 외적인 것이다. 명심해야 할 것은 호환성 문제를 제외하면 기술적인 이유 때문에 베타 테스트를 실시하는 것보다는 다른 방법이 더 낫다는 것이다.
베타 테스트 때 전문가로부터 컨설팅을 받는 경우는 별로 많지 않으며 또 너무 늦다. 전문가의 컨설팅이 필요하다면 요구 분석 시기에 사용자 인터페이스 프로토타입에 대한 반응을 조사할 때 활용하기 바란다. 전문가의 컨설팅을 받아 사용자 인터페이스 설계를 다듬는 것도 역시 드문 경우이며 또 시기적으로도 너무 늦기 때문에, 이 역시 베타 테스트 시기가 아닌 요구 분석 시기에 추진해야 한다.
예전에는 베타 테스트를 하는 주된 이유가 품질 보증을 위한 것이었다. 하지만 근간에 소프트웨어 회사들은 외부 베타 테스트를 수행하는 것이 그다지 좋은 일이 아니라는 것을 알게 되었다. 회사가 베타 소프트웨어를 보냈을 때, 소프트웨어를 받은 사람들 대부분은 어떠한 결함도 보고하지 않았고, 제품에 대한 코멘트조차 하지 않은 경우도 많았다. 그래서 회사들은 베타 소프트웨어를 배포하는 대상에 제한을 두기 시작했다. 그후 베타 사용자들로부터 소프트웨어를 변경하라는 요구사 밀려들었지만, 이 역시 결함에 대한 보고는 아니었다. 이와 같은 경험을 겪은 후에 회사들은 베타 테스트가 유용한 마케팅 자료로 사용될지는 몰라도, 그 피드백이 너무 형편없어 품질 보증 목적으로는 활용할만하지 못하다는 사실을 알게 되었다.
여러분이 실제 사용자로부터 피드백을 원한다면, 베타 테스트 프로그램을 여기저기 배포하지 말고, 대표성 있는 사용자에게 대가를 지불하고 프로젝트 현장으로 데리고 와서, 관리자의 감독 하에 소프트웨어를 사용하게 해야 한다. 사용자가 소프트웨어에 행하는 전체 행위를 비디오테이프로 녹화해 두었다가 그 사용자가 겪었던 문제를 개발팀이 재현해 볼 수 있게 해야 한다. 베타 테스트보다는 관리자의 감독 하에서 이루어지는 테스트가 더 집중적인 피드백을 준다. 이런 이유로 상용 소프트웨어 업계의 선두 업체들 대부분은, 품질 보증 목적으로 베타 테스트를 활용하는 방식을 중지하였다.

베타 테스트를 효율적으로 수행하려면 많은 조정과 인력이 필요하다. 이런 자원을 조직 내부로 집중하면 더 효율적인 품질 관리를 수행할 수 있다.

여러분의 소프트웨어가 궁극적으로는 수도 없이 많은 사용자에게 배포될 것이라면, 아마도 최종 릴리스 이전에 특정 외부 릴리스를 생성하고자 할 것이다. 이러한 외부 릴리스는 일반적인 품질 보증 목적이 아닌 호환성 테스트를 위해 생성하는 것이다. 아무리 자금이 풍부한 기업이라도 엄청나게 다양한 하드웨어와 소프트웨어 조합을 모두 구매하여 철저한 테스트를 수행할 수는 없다. 시스템 테스트를 거친 소프트웨어에 대해 이런 다양한 환경에서 실용적인 호환성 테스트를 수행하는 유일한 방법은 관대한 외부 사용자들에게 이를 배포하는 것이다.

품질 보증 대상 산출물

품질 보증 계획에는 리뷰하고 테스트할 산출물을 지정해야 한다. 표 9-3에 이 책의 각 산출물에 적용해야 할 품질 보증 작업을 수록했다.

보다시피 변경통제를 받는 모든 작업 산출물은 검토되고, 어떤 것들은 테스트까지 수행된다. 사용자 매뉴얼과 같은 산출물에서 테스트란, 매뉴얼에 설명되어 있는 모든 작업을 하나하나 입력까지 수행해서 적혀 있는 내용대로 실행되는지 확인하는 것을 의미한다.

프로젝트마다 문서, 관리자, 고객, 마케팅 담당자 및 최종 사용자의 기술과 관심사에 따라 해당 프로젝트에 고유한 책임이 약간씩 달라질 수 있다.

<표 9-3> 이 책의 산출물에 대한 권장 품질 보증 작업

지원 활동

품질 보증 부서는 자신의 고유 업무인 품질 보증 외에도, 소프트웨어 개발 계획의 작성과 리뷰에 참여한다. 품질 보증 부서는 소프트웨어 개발 활동을 검토하여, 리뷰, 단위 테스트, 소스코드 추적이 제대로 수행되고 있는지 검증한다. 또한 자신의 활동 결과를 개발자와 관리자에게 주기적으로 보고하고, 상급 관리자와 함께 자신의 활동도 주기적으로 검토한다.

소프트웨어 릴리스 기준

필자가 컨설팅 했던 기업들 중에는 소프트웨어 개발 조직이 소프트웨어의 릴리스 시기를 결정하는 경우가 많았다. 이는 고양이에게 생선을 맡기는 격이다. 개발자와 개발팀의 관리자는 목표 일정을 맞추는 데만 혈안이 되어 있으며, 자신이 개발한 소프트웨어 품질이 우수한 것이라 생각한다. 그들이 이런 경향에 치우치지 않도록 점검하고 바로잡아줄 필요가 있다. 바로 품질 보증 부서가 이 역할을 수행한다.

이런 이유로 품질 보증 계획은 소프트웨어의 릴리스 기준에 관한 상세한 척도를 마련해야 한다. 릴리스 기준은 예를 들어, '소프트웨어가 다시는 다운되지 않는다.', '결함이 평균 8시간에 한 번 꼴로 발견된다.', '보고된 결함의 95%가 수정되었다.', '심각한 오류 No.1Sev 1)과 No.2(Sev 2) 에러가 모두 수정되었다.'와 같은 것일 수 있다. 릴리스 기준은 품질 보증 부서가 외부 영향에 의해 치우치지 않고 릴리즈 준비가 되었는지 객관적으로 보고할 수 있도록 측정 가능한 것이어야 한다.

[생존 진단표]

생존) 프로젝트 팀에 작성, 승인된 품질 보증 계획이 있다.
위험) 프로젝트가 작성된 계획을 따르지 않는다.

생존) 품질 보증은 요구 분석과 함께 시작되었다.

생존) 요구사항 개발 시부터 결함 추적 소프트웨어를 운영하여, 프로젝트 초기부터 결함을 추적한다.

생존) 개발자가 모든 설계와 코드를 리뷰한 이후에야 설계와 코드의 상태를 '완료'된 것으로 취급한다.
위험) 리뷰를 통과하지 못한 설계나 코드가 없다. 즉 리뷰가 피상적이었음을 암시한다.
위험) 리뷰 단계로 넘기기 전 개발자가 자신의 소스코드를 추적하고 단위 테스트를 시행하지 않는다. 이로 인한 많은 결함을 이후의 리뷰 단계에서 발견하게 만든다.

생존) 품질 보증 계획을 수행하기 위한 별도의 품질 보증 부서가 존재한다.
위험) 독립된 품질 보증 부서를 운영하기 위한 예산이 없다.

생존) 품질 보증 계획은 소프트웨어의 릴리스 시기를 결정하기 위해 사용하는 측정 가능한 기준을 담고 있다.

{끝}