새 창을 열다

지난 10월 21~22일에 제13회 소프트웨어 품질관리 심포지엄이 섬유센터에서 있었습니다.
무려 10만원이나 하는 세미나였는데, 사장님의 특별(?)지시로 다녀올 수 있었습니다. 품질에 관한 세미나가 10회 이상씩 지속적으로 열리고 있었다는 것을 미쳐 모르고 있었는데 나름 고무적이었습니다. 하지만 대부분의 세션이 문제점만 이야기하고 해결방안은 내놓지 못하는 발표가 많아 아쉬었습니다. 물론 문제를 이야기하기란 쉽지만 역시 해결책을 내기는 어렵다는 것을 알지만요.

개발자 입장에서 참여하는 개발 세미나와 QA 입장에서 참여하는 품질 세미나는 느낌이 살짝 달랐습니다. 지극히 개인적인 느낌이지만 말이니다. 품질 또는 개발은 지식이 아니라 관리 이슈라는 말도 와닿았습니다. 관리되지 않은 모듈과 소스코드는 없는 것이나 마찬가지이기 때문이지요.

또한, 대부분의 회사에서 수행하고 있지못하는 자동화, 정적분석, 화이트박스 테스트 등에 대해 먼저 시행하면서 어려웠던 점과 좋았던 점을 고루 나눌수 있었던 것 같습니다. 많은 세션이 있었지만 그중에 기억에 남는 세션 몇개만 정리했습니다.

Issues and Challenges in S/W Development & quality - 유인경 원장(LG전자 기술원)

     ♣  구체적인 해결방법을 제시하지 못해서 아쉬움, 개발자의 높은 개발 능력이 요구됨을 어필

 

IT/SW융합에서의 품질 확보를 위한 테스팅 방안 - 최병주 교수(이화여대)

• 카 인포테인먼트 시스템 테스트 자동화 도구 AMOS 개발

  • 분석 로봇이 시스템 구조 분석을 통해 테스트 위치(리스크존)을 식별하고 테스트 결과 분석, 결과를 내주는 시스템

  • 짧은 개발 기간과 개발 후반에 테스트가 집중되는 문제

    • Interface Based Test (개발 모듈의 인터페이스화 선행)
    • 블랙박스 테스트 하되, 화이트 박스 테스트로 확인
    • SW 개발자는 최초의 테스터

      ♣  자동화 도구를 개발하여, 결함의 원인을 분석하며, 코드 레벨의 화이트박스의 좋은 예.

 

IT차량 분야 임베디드SW 테스트 프레임워크 구축 및 시범 적용 사례 - 정태하 수석(오토에버시스템즈)

• V-모델(Multiful V-모델) 에 근거한 테스트 프레임워크를 구축함.

• Verification & Validation의 각 레벨의 세부 활동 정의

  • Verification 

    • 사양서 Inspection
    • 설계서 Walkthrough
    • 소스코드 Static Analysis : 자동화 도구 활용

  • Validation

    • 단위 Test : Fuction 단위의 기능성 검증, 자동화 마련, 단위함수레벨의 테스트 커버리지 측정
    • 통합 Test : 구성요소의 Integration Set에 대해서 기능시험, 자동화
    • 시스템 Test : 요구사항기반의 테스트

    ♣ 개발 이전의 사양서, 설계서, 소스 레벨의 테스트가 이뤄지며 모두 자동화되어 있음.
    ♣ 문서 및 사용 변경에 대한 업데이트미 미비하며, 시간이 오래걸린다는 단점이 잇음
    ♣ 테스트 케이스를 소스 코드 기반에서 추출하고 개발자 리뷰를 같이 하는 것으로 보안 노력.

 

국내  SW QA시장 활성화를 위한 소루션 배포 및 기술지원 방안

• 외산 솔루션의 문제점

  • 국내 현실과 다른 프로세스
  • 언어 문제
  • 고가의 도입과 유지보수 비용

•  소프트웨어 테스트 관리시스템 WATT(와이즈와이어즈)

  • 요구 사항관리
  • 테스트케이스관리
  • 결함관리
  • 보고서 기능
• 무료 다운로드 : http://watt.wisewires.com

    ♣ 자사 툴 선전하는 시간이었으나, 외산 툴의 장단점을 소개하고 현실을 이해시키는 세션이었음.

 

ITNHN Quality Practice 적용 사례

• QP(Quality Practice) 도입하여 개발 단계의 Defect Prevention을 강화하고, 품질 활동을 정령화 시킴

  • 도입배경

    • 개발 라이프 후반에 몰아 닥치고, 제대로 테스트 되지않은 모듈이 QA 단계로 넘어옴
    • 단순 기능 테스트 위주의 검증과 버그는 QA가 잡는다는 안일한 마인드가 팽배
    • 개발 품질보다는 개발 진척도에만 관심을 가짐.

  • Quality Practice 활동

    1. Coding Convention : 코드이 가독성 및 유지 보수성 향상을 목표

       • 신규/수정되는 코드에 코딩표준을 준수시키도록 함

    2. Unit Test Coverage

       • 구현단계에서 필수 수행 Unit Test 대상 정의(QA불가한 기능,DB쿼리,데이터가공 등)
       • Unit Test Coverage를 QA 테스트의 Entry Criteria로 사용
    3. Code Inspection : 대상 소스에 대한 리뷰, 공통 협업도구 제공
    4. Static Code Analysis : 결함 사전 제거

    5. Code Complexity : QA 테스트 단계의 Entry Criteria로 지정

       • Critical한 정적 분석 결함을 모두 제거

• Quality Practice 적용 절차
  1. 개발자

  • 코딩 표준 준수
  • Unit Test

  2. 개발팀

• 주기적인 통합빌드
• 5가지 QP 항목 필수적

3.QA

• 구현 단계 말 코드 품질 확인하여 QA 가능 수준인지 판단
  중점적으로 테스트할 부분 식별

• Quality Practice 활동 지표 수립

  • 대시 보드를 구성하여 품질지표를 정량화 하여 표현(Gold, Green, Yellow 등으로 시각화하여 잘하고 있는지 여부를 표시)
  • 수준과 목표를 설정하여 개발자 스스로 도전하게 동기부여
  • KPI 등에 반영하지 않으므로 반발 감소시킴

• 개선 효과 측정 방법

  • QA 단계 완료 및 릴리즈 이후 안정화 시점에서 3가지 빌드 품질 지표를 측정하여 개선효과를 검증
  • 사내 BTS을 이용하여 Build Quality를 측정
  • Quality Practice 활동을 한 소스와 하지 않은 소스를 비교하여, 추후 장애 심각도 등을 측정

• 조직차원의 지원활동

  • 표준 환결 설정, 교육, 기술지원
  • 자동화 도구 지원
  • 커뮤니케이션 강화 및 피드백 활동(사내 Q&A, FAQ, Best Practice 공유)

• 기타 (사용하고 있는 툴 등 구두로 소개해 줌)

• • Style checker
  • Google Test Frameworks
  • Visual Studio tools
  • JUnit, CPPUnit
  • Clover(code coverage tool) : http://www.atlassian.com/software/clover/
  • Hudson : 오픈 소스 CI 서버

    ♣ 구현단계의 품질을 위해 애씀, 전사적인 지원과 노력을 엿볼 수 있음
    ♣ 유/무료 도구의 적극적인 이용과 통합적인 관리가 돋보임

이 글은 스프링노트에서 작성되었습니다.