u 발표한 주제는 통신회사 시스템 구축(3년)과 유지보수(3년) 진행 현황 및 향후 방향 이었음
u 회사 사정으로 구조조정이 있었으나 이러한 와중에도 품질조직은 오히려 인력을 보강하는 움직임이 있다고 합니다.
u 발표자는 최근에 “마이크로소프트~” 책을 읽으면서 자신에게 어울리는 단어를 찾았다고 하더군요 (TA : Test Architect) 저도 이 책 리뷰하면서 이 단어가 재미있다는 생각을 하면서 읽었던 기억이 나더군요.
u 현재 QMO라는 품질 관리 조직으로 유지보수를 수행하고 있다고 합니다.
u QMO 조직 구성은
l 산출물 점검팀 : 3명 정도이며, 사용자 요구사항 정의서 등 유지보수와 관련된 모든 문서를 검토
l QM Test : 사용자 또는 업무 전문가로 구성된 10명 정도의 팀이며, 전체 기능 중 우선순위가 높은 기능을 직접 검증함. 2009년의 경우 신규 개발 기능의 33% 정도만 테스트를 수행했다고 함. 정해진 TC없이 참가자들의 경험과 지식으로 만 테스트를 진행한다고 합니다. 보통 1주일에 2~300개의 기능 목록이 Update 된다고 함. 정기 배포는 1주일 단위, 수시(긴급)배포는 거의 매일 발생함
l 자동화 테스트팀 : Core로 분류한 230개의 Test Case만을 자동화 시켜 검증하는 팀으로 4명 정도가 요일 단위로 T/C를 구분하여 구동하고 결과를 확인하며, 주말에는 전체 230개의 TC를 모두 구동시켜 월요일 오전에 결과를 공식 Reporting 함. 테스트 자동화의 단점인 Test script 유지 관리가 역시 가장 큰 이슈인 것 같습니다. 이 팀은 가끔씩 외부 프로젝트를 지원하기도 하며 지원 시 해당 프로젝트 담당자로부터 좋은 반응이 있다고 합니다. (테스트 관리 툴과 기능 테스팅 툴 사용하고 있음)
l Source Code 표준/보안 검토 : 사내 자체 표준 Coding Rule(Online 18개, Batch 20개) 준수 여부를 검증하는 팀으로 자동화 테스트팀원들이 같이 지원하는 경우가 많다고 합니다. 최근에는 평균 95% 평가결과를 보인다고 합니다. (정적 분석 툴 사용)
l 고객사에 제안할 사업 방향 (SI 회사 -> 통신회사)
n End-to-End T/C 개발 : 비즈니스 플로우를 고려한 정형화된 테스트 케이스를 개발. 2~3억 사업 규모로 올해 제안 예정
n 상시 테스팅 환경 구축 : 프로젝트 구축 시 테스트 환경에 대한 충분한 고려가 없어, 3년이 지난 현재에 이르러서야 시스템 유지 과정에서 실환경에 근접한 Test Bed가 절실하다는 것을 인식했으며, 이에 대한 투자 제안함
n 개발자 단위 테스트를 정형화 시키고 Source의 테스트 커버리지를 레포팅할 수 있는 시스템(도구)를 구축하고자 함
n 테스팅 영역 확대 : 시스템의 일부만만 테스팅 업무로 가져가고 있는데, 나머지 시스템도 테스팅 사업 영역으로 가져가고자 함
n 각 단계별 테스트 강화 방안 제안
n 지속적인 테스팅 도구 개선 및 투자 요청
l 품질 관리를 해 오면서 느낀 점 (아쉬운 점)
n 품질 관리의 효과를 정량적으로 표현할 객관적인 Data 필요
n 장애 예방의 효과 검증 (객관적인 Data…)
n 자동화 테스팅의 한계 (요구사항 변경이 잦으므로 테스트 자동화가 적당하지 않음)
n 품질 관리 투자에 조직의 의지 필요 (의사 결정권자의 의지만으로도 효과를 볼 수 있다고 보고 있으며, 중역의 의견 합의 결과 올해 15억 정도를 품질 부문에 투자하겠다고 함)
è 개인 소감 : 큰 시스템을 유지하는 업무이므로 품질 관리에 대한 고민을 많이 하고 있는 것 같았고,
è 정량화된 품질 관리 효과를 도출해 내고자하는 이 시대의 품질 관리자의 고충을 공감하였습니다
[출처] STEN - http://www.sten.or.kr/bbs/board.php?bo_table=test_story&wr_id=4295
댓글 없음:
댓글 쓰기