Software 품질과 관련된 연구
결함이 적은 소프트웨어는 개발 일정도 가장 짧고 생산성이 가장 높았다. 166명의 전문 프로그래머들이 동일한 명세로 프로그램을 작성하였다. 작성된 프로그램의 평균 코드 길이는 200줄이고 작성 시간은 5시간에 못 미쳤다. 흥미로운 결과는 프로그램을 완성하기 위해서 평균 시간이 걸린 프로그래머들이 오류가 가장 많은 프로그램을 작성한 것이다. 평균보다 많거나 적게 걸린 프로그래머들은 눈에 띄게 오류가 적은 프로그램을 작성했다.
주요 품질 향상 기법을에 대한 결함 감지 비율은 다음과 같다.
- 코드에 대한 개인 탁장 검사: 40%
- 단위 테스트: 30%
- 통합 테스트: 35%
- 회귀 테스트: 35%
- 대량 베타 테스트(1,000 사이트): 75%
높은 결함 감지율을 얻기 위해선 다양한 기법을 조합하여 사용해야 한다.
사람이 수행하는 정밀 검토에 대한 연구
- IBM은 한 시간의 정밀 검사가 약 100 시간의 관련 작업(테스트와 결함 수정)을 예방한다는 것을 발견하였다.
- 큰 프로그램들에 대한 한 연구는 정밀 검사에 1시간을 투자하면 평균 33시간의 유지 보수 작업을 줄일 수 있으며, 테스트보다 20배 효율적이라는 것을 발견하였다.
사람이 하는 검토는 불분명한 오류 메시지, 주석, 직접 입력된 변수 값, 정리되어야 하는 코드 패턴의 방복 등을 해결할 수 있지만, 테스트를 그렇게 할 수는 없을 것이다. 부수적인 효과는 사람들이 자신의 작업이 누군가에 의해서 검토될 것임을 알고 있을 때, 보다 주의 깊게 자신의 작업을 살펴보는 것이다.
정밀 검사의 절차
- 설계, 코드를 중개자에게 전달한다.
- 리뷰어가 프로젝트에 익숙하지 않을 때에는, 작성자가 설계나 코드가 작성된 기술적인 환경을 1시간 정도 설명한다.
- 각 리뷰어는 설계나 코드의 오류가 있는지를 정밀하게 조사하기 위하여 혼자 일한다.
- 회의를 통해 리뷰어가 발견한 오류를 설명하고 서기는 이를 기록한다.
- 중개자는 수정을 요청하고, 수정을 한 뒤 후속 확인을 거친다.
개발자 테스트
테스트는 소프트웨어 품질 프로그램 중에서 중요한 부분이면서, 많은 부분에서 유일하다. 하지만, 다양한 형태의 협력적인 개발 방법이 테스트보다 오류 발견율이 훨씬 높고, 발견된 오류당 비용은 절반도 안 되기 때문이다.
테스트 자체는 소프트웨어의 품질을 향상 시키지 않는다. 테스트 결과는 품질의 지표이지만, 그 자체로서 품질을 향상시키지 않는다. 테스트를 늘려서 소프트웨어의 품질을 향상시키기 위한 노력은 체중을 더 자주 재서 체중을 줄이려는 것과 같다. 만약 체중을 줄이고 싶다면 체중계를 사지 말고 식이요법에 변화를 주어야 한다.
개발자 테스트는 코드가 깨지는 다양한 상황에 대해서 테스트하기 보다는 코드가 작동하는지를 살펴보기 위해서 테스트하는 경향이 있다. 미성숙한 조직은 모든 dirty 테스트마다 다섯 개 정도의 clean 테스트를 갖는 경향이 있고, 성국한 테스트 조직은 그 반대이다.
일반적인 프로그래머들이 스스로 95%의 테스트 커버리지를 달성하고 있다고 믿지만, 전형적으로 30~80% 정도이다.
프로그램이 정확하다는 것을 테스트로 검증할 수 없는 이유는 프로그램에 가능한 모든 입력 값과 입력 값의 가능한 모든 조합을 테스트해야 하는게 불가능하기 때문이다.
현실적으로 완전한 테스트는 불가능하기 때문에, 가장 오류를 잘 발견할 것 같은 테스트 케이스를 선택하는 것이 바로 테스트의 기술이다.