페이퍼요약 - 단위 테스팅 관행에 대한 조사 by Runeson

제목: 단위 테스팅 관행에 대한 조사(A Survey of Unit Testing Practices)

저자: Per Runeson, 스웨덴

문서유형: 저널 페이퍼(총 8페이지), 2006년

 

다양한 산업 분야의 실무자들을 대상으로 그룹 토론 및 설문지를 통해 해당 업체의 단위 테스팅에 대한 정의, 강점, 문제점이 무엇인지를 조사한 자료

---

조사 대상

• SPIN-syd는 소프트웨어 프로세스 개선 이슈에 중점을 둔 스웨덴의 비영리 네트워크. 소프트웨어가 업무의 주요 부분을 차지하는 50여개 업체가 참여하고 있음
• SPIN-syd는 매달 1회 정기적인 회의(3시간 세션)를 열며, 때때로 특정 주제에 대한 작업그룹을 조직함
• 단순히 문헌이나 표준에 정의된 단위 테스팅을 넘어 실제 현장의 상황을 알아보기 위해 SPIN-syd 참여 업체들의 단위 테스트 관행을 조사함. 먼저 단위 테스팅에 대한 집중 그룹 토론을 열고(12개 회사의 17명이 참여), 이어서 토론 결과를 기반으로 작성된 설문지를 통해 조사를 수행함

조사 수행 절차

①    집중 그룹 토론 참가자 각자가 몇 분간 질문을 고민한 후에 차트 상에 답을 작성함. 토론은 세 개 주제로 구성됨(무엇이 단위 테스팅 인가, 단위 테스팅 관련 참가자 조직의 강점은 무엇인가, 단위 테스팅 관련 참가자 조직의 문제점은 무엇인가)

②    각 참가자가 질문에 대한 자신의 관점을 발표하고, 이 결과를 사회자의 진행으로 그룹 전체가 토론함

③    토론 후 그 결과를 저자가 문서화하고, 이를 참가자들에게 피드백 함(리뷰를 위한 목적)

④    저자가 Zachman 프레임워크를 사용하여 발견사항을 정성적으로 분석(즉, 그룹 토론의 결과물을 구조화하고 확인용 질문지를 정의). 정보 시스템 아키텍쳐 분석을 위해 제안된 Zachman 프레임워크는 6개 카테고리(what, how, where, who, when, why)로 구성되며, 각 카테고리 별로 질문이 정의되고 조사 대상 분야에 맞게 각색된다.

⑤    집중 그룹 토론의 결과를 기초로 저자가 설문지를 준비함

⑥    SPIN 월 회의에 나온 참가자들이 이 설문지에 응답함(또는 이메일을 통해 참여). 설문 조사의 주 목적은 확인이다(즉, 토론을 통해 식별된 발견사항들이 하나의 특정 회사에 고유한지 아니면 업계에 전반적인지를 판단).

⑦    저자가 기술 통계학(descriptive statistics)를 사용하여 설문지 응답을 분석함

[조사 방법론 개요]

설문지(Questionnaire)

• 설문지는 아래처럼 단위 테스팅이 무엇인지에 대한 26개 질문과 단위 테스팅 강점과 약점에 대한 질문 24개로 구성되며, 각 질문에 대해 5단계 척도로 응답할 수 있음
• 설문지 응답은 참가자들간의 의견 일치(agreement)를 나타내며, 분석에서는 집중 그룹 토론의 결과와 설문지의 결과를 비교함

설문지1 – 아래 각 질문에 어느 정도 동의하는가? (강하게 긍정, 긍정, 중립, 부정, 강하게 부정, 해당 없음)

무엇이 단위 테스트인가? 1. 가장 작은 별개 단위의 테스트 2. 입/출력 패러미터를 가진 기술적 테스트 3. 별개 기능에 집중하는 테스트 4. 시스템의 나머지로부터 따로 실행되어야 하는 테스트   어떻게 단위 테스트가 실시되는가? 5. 프로그램 구조에 기반하여 6. 커버리지 측정에 의해 모니터되어 7. 자동화된 실행에 의해서 8. 자동화된 후속조치(follow-up)에 의해서   개발자들이 어떻게 단위 테스트를 실시하는가? 9. 글(text)로 작성된 명세에 의해 10. 테스트 코드로 작성된 명세에 의해 11. 개발자 스스로에 의해 실행됨   단위 테스트가 어떻게 실시될지를 누가 결정하는가? 12. 개발자/테스터 13. 테스트 부서 14. 품질 부서

언제 단위 테스트가 실행되는가? 15. 각 컴파일/시스템 빌드에 맞춰서 16. 하루에 여러 차례 17. 최소 매일 18. 최소 매주   모든 단위 테스트를 실행하는데 얼마나 시간이 걸리는가? 19. 몇 초 20. 몇 분 21. 몇 시간   왜 단위 테스트가 시행되는가? 22. 단위가 기대한 대로 기능함을 확실히 하기 위해 23. 다른 소스로부터 단위를 받아들이기 위해 24. 단위를 명세하기 위해(테스트 우선 개발) 25. 전반적인 제품 품질을 개선하기 위해 26. 고객 요구사항을 충족시키기 위해

설문지2 - 당신 조직에서는 아래 각 항목이 어떠한가? (매우 좋음, 좋음, 중립, 나쁨, 매우 나쁨, 해당 없음)

무엇(What)? 1. 적절한 단위 식별 2. GUI 컴포넌트 테스트 3. 데이터에 의존하는 기능 테스트 4. 외부 코드에 의존하는 기능 테스트 5. 실시간 측면 테스트 6. 테스트 케이스 선별 7. 테스트 코드 유지보수   어떻게(How)? 8. 좋은 단위 테스트 케이스 명세하기 9. 단위 테스팅을 자동화하기 10. 단위 테스팅을 위한 프레임워크 구축하기/맞추기 11. 빌드 시스템과 통합 12. 구성(형상) 관리 시스템과 통합 13. 문제 보고 시스템으로 통합 14. 단위 테스트 문서화 15. 뼈대 세우기(스터브와 드라이버) 16. 커버리지 측정 또는 다른 테스트 진척 측정

누가(Who)? 17. 개발자가 모든 필요한 단위 테스트를 실행함 18. 외적 단위의 단위 테스팅이 충분함 19. 테스팅이 충분한 우선순위와 상태를 가짐 20. 개발자들이 단위 테스팅을 수행하기에 충분한 능력과 기술을 보유함   언제(When)? 21. 단위 테스트를 충분히 자주 실행함 22. 단위 테스트 완료를 판단하는 분명한 기준을 가짐   왜(Why)? 23. 개발자들이 단위 테스트 실행에 동기 부여가 됨 24. 단위 테스팅에 쏟은 시간의 비용 보다 더 많은 이득을 얻는 것을 인지하고 있음

발견사항: 단위 테스팅이 무엇인가(What is unit testing?)

• 시스템의 가장 작은 단위에 집중한 테스트라는 정의에 대해서는 참가자들의 이견이 없지만, 단위 테스트를 기본 골격(scaffolding) 환경에서 수행해야 하는지 아니면 거의 완성된 시스템 환경에서 수행해야 하는지에 대해서는 의견이 다름
• 업체들은 프로그램 구조(structure)를 기초로 단위 테스팅을 수행하며, 테스트 실행 및 결과 체킹 측면에서 테스트 케이스가 반복 가능하고 자동화될 것을 원함
• 단위 테스트 명세는 글(text)로 쓰여지기 보다는 테스트 코드로 작성됨
• 단위 테스트가 테스트 조직이나 품질 조직 보다는 개발자의 일로 여겨짐. 단위 테스트는 암묵적으로 구현 활동과 연결되며 개발자에게 빠른 피드백을 주는 역할을 함
• 단위 테스팅은 특정 모듈이 개발자가 기대하는 기능성(functionality)을 가지는지를 검증함(이 기능성이 다른 이해관계자가 기대하는 것과 반드시 일치하라는 보장은 없음)

발견사항: 단위 테스팅 강점(Unit testing strengths)

• 대부분의 조직이 쉽게 단위를 식별하고 단위 테스트 코드를 유지보수 할 수 있다고 답변
• 두 개 업체가 단위 테스트 자동화를 위한 프레임워크를 수립한 것을 강점으로 뽑음. 이런 프레임워크가 조직 내부의 지원을 받으면 테스트 관행을 개선할 수 있음
• 단위 테스팅이 빌드 시스템과 통합됨. 즉, 시스템의 모든 버전을 위하여 선별된 테스트 케이스 집합을 자동으로 실행
• 단위 테스팅이 개발자에 의해 수행되는 것이라고 정의하기는 했지만 업체들이 독립적인(또는 제 3자에 의한) 단위 테스트도 선호함. 이를 위해 단위 테스팅 범위를 좀 넓혀서 직접 개발한 개발 팀 뿐만 아니라 다른 팀에 의한 테스팅도 허용함
• 지속적인 회귀 테스트도 강점으로 꼽힘. 한 회사는 자동 테스트(자동적인 결과 체킹도 포함)를 매일 밤 실행하고, 또 다른 회사는 코드를 손 볼 때마다(refactoring) 회귀 테스트 실행함. 이 회사는 또한 기본 기능성과 특징에 변함이 없는지 확인하기 위해 메모리 테스트도 지속적으로 실행함

발견사항: 단위 테스팅 약점(Unit testing weaknesses)

• 참가자들이 공통적으로 GUI 모듈 테스팅(특히 자동화 관련)을 문제 영역으로 손꼽음
• 설문 조사에서는 단위 식별이 양호한 것으로 응답했지만 그룹 토론에서는 테스트를 위한 단위를 식별하는 것에 문제가 있다는 의견이 나옴(테스트 대상 오브젝트가 개별 단위보다는 관련 단위들의 그룹인 경향이 있다)
• 많은 업체들이 테스트 자동화를 원하지만, 자동화를 시작한 이후 곧 많은 양의 코드가 축적되고 제품의 진화에 따라 이 코드를 유지보수 해야만 하여 많은 노력이 요구됨
• 큰 데이터 구조를 가지거나 이에 의존하는 모듈을 테스팅 하는데 문제가 있음. 즉, 복잡한 시스템 상태(또는 복잡한 시스템 환경)과 상호작용하는 모듈을 위한 관련 테스트 환경을 생성하기가 어려움
• 적절한 문서화 없이는 비정형적인 반복성만이 가능하므로 문서화(documentation)도 문제로 꼽힘. 테스트 자동화가 하나의 솔루션으로 제안되지만(즉, 테스트 스트립트를 최신으로 유지하도록 장려), 그에 따른 비용이 추가될 수 밖에 없음
• 테스트 프레임워크가 성공의 열쇠로 여겨지지만 통합 문제를 수반함. 모든 신규 소프트웨어 엔지니어링 방법이 그렇듯 맨 처음부터 시작하는 편이 것이 더 쉽지만 대부분의 프로젝트가 레가시 코드 상에 구축되므로 그런 경우가 드물다.
• 지속적 회귀 테스트를 위한 테스트 케이스 선별이 어려운 작업으로 손꼽힘. 회사가 테스트 선별을 위한 체계적인 방법을 사용 안하고 개발자의 전문성과 판단에 의존함에 따라 너무 많거나 또는 너무 적은 테스트 케이스가 실행될 수 있음
• 테스트 메트릭(metrics)이 드물어 정량적 방법이 테스트 관리를 위하여 그다지 많이 사용되지 않음(커버리지 상태, 진척 정도 측정 등)
• 단위 테스팅을 위한 전략을 가진 업체가 적음. 대신 개발자들이 스스로 단위 테스팅 정도를 정하며, 따라서 그 수준이 천차만별
• 명확한 투자 수익(ROI) 모델이나 계산법이 없어서 단위 테스트에 쏟은 노력 대비 얻은 이익에 대하여 테스트 관리자가 판단하기 어렵고 개발자들이 단위 테스트를 실행하도록 동기부여 하기도 어려움