HP ALM/Quality Center — 엔터프라이즈 통합 품질 관리

개념

이름 그대로 "생명주기 전체"를 다룬다

이 모듈에서 지금까지 본 도구들은 모두 한 칸짜리 도구 였다. TestRail·Testmo는 테스트 관리, Bugzilla·MantisBT는 결함 관리, Xray·Zephyr Scale은 Jira 안에서 테스트 관리 — 각자 맡은 영역이 분명했다.

HP ALM(Application Lifecycle Management)은 전제가 다르다. 이름에 있는 그대로, 소프트웨어 생명주기의 여러 단계를 하나의 시스템에 통합 한다. 원래 Mercury의 TestDirector에서 출발해 HP Quality Center를 거쳐 지금은 Micro Focus를 인수한 OpenText가 제공하는데, 현장에서는 세대와 무관하게 그냥 "ALM" 또는 "QC"라고 부른다.

[요구사항 관리] → [테스트 계획] → [테스트 실행] → [결함 관리] → [릴리스 관리]
       └────────────────── 하나의 DB, 하나의 링크 체인 ──────────────────┘

모듈 2(레슨 5)의 추적성 매트릭스를 도구가 강제한다

모듈 2(레슨 5)에서 요구사항 추적성 매트릭스 를 배웠다. 요구사항이 바뀌면 어떤 테스트가 영향받는지 놓치지 않기 위해 표를 손으로 관리했다. 모듈 7(레슨 1)에서는 TestRail 같은 테스트 관리 도구가 이 연결을 일부 자동화한다는 것도 봤다.

ALM은 이 연결을 끊어질 수 없는 구조로 만든다. 요구사항 모듈에 등록한 항목에 테스트 계획의 케이스를 붙이고, 그 케이스의 실행 결과가 결함 모듈의 결함을 낳는다. 그러면 이런 질문에 클릭 몇 번으로 답이 나온다.

왜 여전히 금융·공공의 표준인가

"낡았다"는 평판에도 ALM이 살아남은 이유는 취향이 아니라 규제 다. 금융·의료·항공처럼 감사(audit)를 받는 산업에서는 "테스트를 했다"가 아니라 "했다는 것을 증명할 수 있다" 가 요구된다. 감사인이 요구사항 하나를 짚으면, 그것을 검증한 테스트 케이스와 실행 기록, 실행한 사람, 실행 시각, 발견된 결함과 그 종결 근거까지 한 화면에서 나와야 한다.

• 완결된 추적 체인 — 요구사항부터 결함 종결까지 한 DB 안에서 이어진다
• 감사 로그와 전자 서명 — 누가 언제 무엇을 바꿨는지 남고, 승인 절차를 강제할 수 있다
• 권한 분리 — 테스트 설계자·실행자·승인자의 역할을 시스템이 구분한다

여러 SaaS 도구를 연동해서 비슷한 그림을 만들 수는 있다. 하지만 그 경우 "연동이 끊기지 않았음"까지 감사에 설명해야 한다. 시스템 하나로 끝나는 쪽이 설명이 훨씬 짧다.

솔직한 단점

• 무겁다. 설치형 서버 기반이라 도입·운영에 별도 인력이 붙는다
• 비싸다. 사용자 단위 라이선스 비용이 SaaS 도구와 자릿수가 다르다
• 느리고 구식이다. 옛 버전은 브라우저 플러그인을 요구했고, 지금도 최신 SaaS 도구의 반응 속도에는 못 미친다는 평이 많다

그럼에도 잘 바뀌지 않는 이유는 전환 비용 이다. 수년치 요구사항· 케이스·실행 이력·감사 기록이 이미 그 안에 쌓여 있고, 사내 프로세스와 감사 대응 절차가 그 화면에 맞춰져 있다. 걷어내는 비용이 불편을 참는 비용보다 크면, 조직은 합리적으로 유지를 택한다. QA가 배워야 할 것은 "ALM이 좋다/나쁘다"가 아니라 이 계산이 조직마다 다르게 나온다는 사실 이다.

실무에서 왜 필요한가

직접 쓰지 않더라도 ALM을 이해해야 하는 이유가 두 가지다.

첫째, 면접과 실무에서 만난다. 금융권 SI, 공공 프로젝트, 대기업 품질보증 조직의 채용공고에는 아직 ALM/QC가 자주 등장한다. 이때 필요한 건 화면 조작 숙련도가 아니라 "요구사항–테스트–결함을 하나의 체인으로 관리한다"는 개념을 이해하고 있느냐다.

둘째, 가벼운 도구를 쓸 때 무엇이 빠졌는지 알게 된다. TestRail만 쓰는 팀에서 "이 요구사항이 얼마나 검증됐는지" 답이 안 나온다면, 그건 도구의 한계가 아니라 요구사항을 어디에도 등록하지 않았기 때문일 수 있다. ALM이 강제하는 구조를 알면, 어떤 도구를 쓰든 그 구조를 스스로 만들어낼 수 있다.

실습 과제

과제 1 — 어떤 조직에 ALM이 맞는가 판단하기 (10분)

아래 세 조직에 ALM과 TestRail+Jira 조합 중 무엇을 권하겠는지 고르고, 근거를 각각 두 줄로 적는다.

• A: 개발자 8명·QA 2명의 커머스 스타트업, 주 2회 배포
• B: 은행 차세대 시스템 프로젝트, 참여 인원 200명, 금융감독 감사 대상
• C: 의료기기 소프트웨어 회사, 인원 40명, 인허가를 위해 요구사항–테스트 추적 근거 제출 필요

과제 2 — 추적 체인 설계해보기 (8분)

"이체 한도는 1일 5천만 원을 초과할 수 없다"는 금융 요구사항 하나를 골라, ALM의 다섯 모듈(요구사항 → 테스트 계획 → 테스트 실행 → 결함 → 릴리스)을 각각 한 줄씩 채워본다. 그런 다음, 감사인이 "이 요구사항이 검증됐음을 증명하라"고 했을 때 어느 항목을 어떤 순서로 보여줄지 적는다.

자가 체크리스트

• ALM이 TestRail·Xray 같은 도구와 다루는 범위가 어떻게 다른지 설명할 수 있다
• 요구사항 → 테스트 → 결함으로 이어지는 추적 체인을 그림으로 그릴 수 있다
• 규제 산업에서 통합 추적성이 왜 의무가 되는지 설명할 수 있다
• ALM의 단점을 알면서도 조직이 유지하는 이유(전환 비용)를 설명할 수 있다
• 조직의 규모·규제 수준에 따라 도구 선택이 달라지는 기준을 말할 수 있다

흔한 실수

• "낡은 도구니까 알 필요 없다"고 넘긴다. 도구는 낡았어도 그 안에 담긴 통합 추적성 개념은 최신 도구들이 여전히 흉내 내는 목표다.
• ALM을 그냥 "비싼 TestRail"로 이해한다. 테스트 관리는 ALM의 다섯 모듈 중 하나일 뿐이다. 요구사항 관리와 릴리스 관리가 함께 있다는 점이 본질적 차이다.
• 도구를 도입하면 추적성이 생긴다고 믿는다. 요구사항을 등록하지 않고 케이스를 연결하지 않으면, ALM을 써도 커버리지 화면은 비어 있다. 도구는 구조를 담을 그릇이지 구조 자체가 아니다.
• 모든 조직에 같은 답을 적용한다. 스타트업에 감사용 승인 절차를 강요하면 속도만 죽고, 규제 산업에 가벼운 도구만 쓰면 감사에서 증거를 못 낸다.

참고 자료

• OpenText Application Quality Management(구 ALM/Quality Center) 제품 문서 — 현재 세대의 모듈 구성과 기능 범위
• ISTQB Glossary — Traceability — 모듈 2(레슨 5)에서 배운 추적성의 공식 정의를 도구 맥락에서 다시 확인
• FDA — General Principles of Software Validation — 규제 기관이 요구하는 검증 근거의 수준. ALM 경험을 요구하는 채용공고가 왜 금융·의료·공공에 몰려 있는지 배경이 된다