번역: 권민혁 (슈어소프트테크  SW시험자동화연구소 선임)

원문: http://accelerateddevelopment.ca/blog/2012/12/

작성일 : 2012년 10월 10일

소프트웨어 전문가는 인스펙션을 한다.

여러분은 소프트웨어 전문가 입니까? 그렇지 않습니까?

저는 여기서 공식적인 자격 증명에 대해 말하려는 것이 아닙니다. 과연 여러분이 반복에 기초한 고품질의 코드를 만드는 것이 최우선 순위인지에 대해 물어보는 것입니다.

전문가들은 가능한 모든 노력을 다하여 높은 품질의 코드를 작성합니다. 여러분과 여러분의 조직은 높은 품질의 코드를 작성하기 위해 가능한 모든 일을 하나요? 물론 당신이 전문가이건 그렇지 않든간에 이 대답은 당신의 동료만이 할 수 있을 것입니다.

만약 여러분이 소프트웨어에 대한 인스펙션을 수행하고 있지 않다면, 여러분은 코드이 품질을 높이기 위한 가능한 모든 작업을 하고 있지 않는 것입니다.

소프트웨어 인스펙션은 코드를 살펴보는 것, 즉 다른 팀원들에게 여러분이 작성한 코드가 무엇인지 보여주고 교육을 목적으로 하는것과 동일하지 않습니다. 코드를 단순히 훝어보는 것은 단지 눈에 보이는 결함들만을 검출 할 수 있습니다.

이러한 코드 훝기는 가능한 많은 결함을 발견해 내기 위해서 수행하는 것은 아닙니다.

어떻게 코드에 결함이 들어갔을까요? 이건 어느날밤 요정들과 고블린이 갑자기 나타나서 여러분의 코드에 결합을 넣는 식은 아닐겁니다. 만약 결합이 있었다면 당신의 팀원 중 하나가 넣었을 겁니다.

많은 결합들은 개발하는 도중에 실제 문제를 일으키기 전에 발견되고 예방 될 수 있습니다. 결함은 여러분이 직접 그것들을 살펴볼때에만 식별됩니다. 일반적으로 이러한 작업은 QA 에 의해서 이뤄지죠.

인스펙션의 이점

인스펙션은 다양한 사람들의 참여되고, 리뷰를 위해 많은 준비가 필요합니다. 인스펙션의 목적은 가능한 빨리 결함들을 검출하고 제거하기 위함입니다. 인스펙션은 소프트웨어 개발의 모든 산출문에 대해서 수행합니다. 산출물은 다음과 같습니다.

• 요구사항(유즈케이스, 사용자 스토리)

• 설계 (고차원/저차원 설계, UML 다이어그램)

• 코드

• 테스트 계획과 테스트케이스들

인스펙션 메소드는 1970년대에 M.E. Fagan 의 그의 IEEE 논문에서 잘 정리하고 있습니다. 인스펙션의 기본 아이디어는 가능한 빨리 결함을 검출하고 그것들을 제거하는 것입니다. 인스펙션을 수행하지 않으면 결함들은 테스팅을 수행하기 전까지 누적될 것이고 테스팅시에 발견되는 결함들은 소프트웨어 개발 전체 프로세스 곳곳에 존재했던 결함이 될 것입니다.

Radice 으로 부터 발췌해온 이 다이어그램은 테스팅이 시작될때까지 결함은 누적된다는 사실을 보여줍니다. 여러분의 소프트웨어 품질은 소프트웨어를 출시하기 전까지 검출한 결함의 수에 의해 결정됩니다. 

인스펙션을 각 단계의 산출물이 나오는 시기에서 부터 수행하면, 결함이 다음 단계로 누적되지 않고 제거될 수 있습니다.  예를 들면, 요구사항이나 아키텍쳐 설계 때 생성된 결함은 코딩시에 늦게 검출 되고 이것이 문제를 유발할 수 있습니다.

인스펙션을 수행하면 다음과 같은 결함 제거 추이를 얻을 수 있습니다.

효과적인 인스펙션이 필수가 되면 품질 갭이 매워지면서 소프트웨어 품질이 극적으로 향상됩니다.

Capers Jones 와 Olivier Bonsignour 의 Economics of Software Quality 라는 책에서는 인스펙션을 수행하지 않았을때 결함 제거율이 80% 인데 반해 인스펙션을 수행하면 97% 가 된다고 설명합니다.

왜 인스펙션을 하지 않을 까요?

인스펙션은 시간낭비라는 잘못된 믿음이 있습니다. 하지만 이후의 많은 연구들이 오히려 인스펙션이 결과적으로 시간을 줄여준다고 말합니다. 인스펙션을 수행하기 위해 추가적인 시간이 필요한 것은 의심할 여지가 없지만, 이것은 나중에 모두 돌려받게 됩니다. 인스펙션의 숨겨진 기능은 다음과 같습니다.

문제는 사람들은 실수를 하지만 그것을 인정하지 않으려 한다는 것입니다. 누가 좋아하겠어요? 분명히 동료들이 모르게 하려 할겁니다!

소프트웨어 시스템의 많은 결함들은 '무시', '집중력 결핍', '근면성 부족' 등에 의해 생겨납니다. 이러한 대부분의 결함들은 인스펙션에 의해 찾아 질 수 있지만, 다른 사람에게 당하게 될 무시나 부끄러움 때문에 쉽게 기피하게 됩니다.

인스펙션 활동을 할때는 반드시 '비판없는 환경' 에서 해야 합니다. 목적은 오직 결함을 제거하고 코드의 품질을 높이기 위함이니까요. 만약 인스펙션이 마녀사냥 같은 스타일로 진행되면 결과적으로 시간낭비만 될 뿐입니다.

소프트웨어 전문가는 높은 품질의 코드를 걱정합니다. 여러분이 어떻게 결함있는 코드를 작성했는지를 가능한 빨리 알아내는 것이 결함을 예방하고 더 나은 개발자가 되는 가장 빠른 방법입니다.

 전문가는 스스로에게 '어떻게 하면 더 나아질까?' 하고 끝없이 질문합니다. 여러분도 그런가요?

결론

코드 인스펙션은 40여년 동안 추가적인 시간이나 일정없이 소프트웨어 품질을 높이는데 탁월하다고 증명되어 왔습니다. 만약 여러분이 인스펙션을 수행하지 않는다면 여러분들 절대 최고 품질의 소프트웨어를 만들 수 없을 것입니다.

Bibliography

• Bonsignour, Olivier and Jones, Capers; The Economics of Software Quality; Addison Wesley, Reading, MA; 2011; ISBN 10: 0132582201.

• Gilb, Tom and Graham, Dorothy; Software Inspections; Addison Wesley, Reading, MA; 1993; ISBN 10: 0201631814.

• Radice, Ronald A.; High Qualitiy Low Cost Software Inspections; Paradoxicon Publishingl Andover, MA; ISBN 0-9645913-1-6; 2002; 479 pages.

• Wiegers, Karl E.; Peer Reviews in Software – A Practical Guide; Addison Wesley Longman, Boston, MA; ISBN 0-201-73485-0; 2002; 232 pages.