12장 실사용에서 사용되는 SW

의료용 프로젝트에 있어서의 QA 엔지니어 에세이

---

내용 정리

의료용 SW 프로젝트 소개

의료용 소프트웨어 프로젝트의 특징 (QA 엔지니어의 중요성↑ )

• 의료용 프로젝트 특징
  • 사내 테스트 팀을 통한 제품 검증 이외에도 별도의 검증 작업 수행
    • 산더미 같은 문서 작성 & 정형화된 테스트 프로세스 수행
    • FDA에 의해 최종 제품 승인
  • 잔존하는결함은 치명적 사고 가능성 ↑
    ⇒ 타 프로젝트 대비 QA 엔지니어 역할 중요성 ↑

• 해당 프로젝트의 성공적인 마무리 요인
  • PM의 솔직한 비판 능력
  • TL의 문서 작성 능력 (최종 감사 기준에 적합한 문서 작성)
  • PM의 제품 이해성 ↑ & TL의 테스팅 지식 ↑
  • PM & TL의 활발한 의견 공유
    • TL의 제품 이해 ↑
    • 프로젝트 진행 중 서로의 강점 활용 ↑

의료용 품질 검증 설계

제품 품질 확보에 확신을 가지는 법

• 테스팅 설계 방향
  어떻게 제품이 출시 가능할 정도의 품질을 확보했다고확신을 가질 수 있을까?

• 품질 확보 확신에 대한 방법
  테스팅에 대해 여러가지 접근법을 혼합하여 추가하는 것.

  • 2개의 테스터 팀 구성
    • 기존 테스터 작성 테스팅 <- FDA 감사 기준 이용한 테스팅 작업 수행
    • 새로운 탐색적 테스팅 <- 기존 놓쳤던 테스트에서 놓쳤던 작업 탐색

• 새로운 탐색적 테스팅 팀 수행 방식
  • 기존 테스팅 팀은 세세한 이슈 탐색 집중
  • 새로운 탐색 테스팅 팀은 거시적인 이슈 탐색 집중
  • 새로운 탐색 테스팅 팀은 다양한 사용자 관점에서 테스트 수행

• 여러 가지 테스팅 적용
  • 탐색적 테스팅, 스트레스 테스팅, 멀티 유저 테스팅 등 다양한 테스팅 기법 적용
    ⇒ 제품에 대해 다양한 시각으로 바라보는 것

탐색적, 애드혹, 그리고 스크립트 테스팅

탐색적 테스팅, 스크립트 테스팅, 애드혹 테스팅 분류

• 탐색적 테스팅
  • 정의 : 테스트 설계와 테스트 수행을 동시에 하는 것.
  • 목적 : SW의 어느 부분에 집중해야 하며 어떤 테스트 전략을 수행해야하는 가에 대한 정보 탐색
  • 의의 : 제품에 대한 이해 높임 → 효과적인 테스팅 업무 도움
    ( ∵ 테스팅은 테스터의 제품 이해 & 테스터의 전문 지식에 의해 결정)
  • 탐색vs 애드혹 : 특정 부분에 집중을 하는가 아닌가의 차이

• 스크립트 테스팅
  • 주의사항
    • 단순히 정형성 벗어나기 위해 정형성을 무시하는 것은 도움되지 않음
    • 무엇을 필요하고, 어떻게 합리적으로 적용할지 정확히 이해한 상태에서 진행 필요

• 애드혹 테스팅
  • 탐색과의 차이점 : 계획과 구체적 목표 없이 진행. 누구나 가능하다는 것이 특징
  • 한계 : 테스터 역량에 따른 아이디어 한계 & 발견한 결함에 대해 재현이 어려울 수 있음
  • 장점 : 잠재된 결함의 영역 확인 (결함이 어느 부분에 잠재되어 있는지 아이디어를 얻을 수 있음)

• 스크립트 테스팅과 탐색적 테스팅의 관계
  • 스크립트 → 탐색 : 정형화된 테스팅에서 벗어난 결함 발견으로 탐색적 테스팅에 대한 아이디어 제공
  • 탐색 → 스크립트 : 탐색적 테스팅을 명세화 하는 과정에서 정형화된 테스팅 절차 구축 → 스크립트 테스팅

멀티 유저 테스팅

멀티 유저 테스팅의 중요성

• 멀티 유저 테스팅
  • 정의 : 여러 테스터들이 각각의 테스트 스크립트를 동시에 수행하는 것
  • 목적 : 동시 수행 중에 발생하는 결함 탐지
  • 성능 테스트 vs 멀티 유저 테스트
    • 성능 테스트 : 악조건에서도 정의된 기능이 정상 작동 하는지 확인
    • 멀티 유저 테스트 : 동시 수행에 의해 발생하는 결함 탐지 목적 (ex. 데이터 손상, 저장 오류, 중복 저장 ...)

• 멀티 유저 테스팅 작업시 체크사항
  1. 각각의 테스터들은 그들이 무엇을 해야 하는지 이해하는가?
  2. 테스트 리더가 그 목적을 달성했다고 평가하는가?
  3. 결론이 무엇이 확실히 결정할 수 있을 정도의 충분한 시간 동안 테스트가 수행되었는가?
  4. 어떤 이슈도 발견되지 않았는가?

최종 테스트 환경 구축

최종 테스트 환경 구축시 고려사항

• 최종 테스트 환경 구축 배경
  프로젝트 진행에 따라 SW 내부 테스트 이외에도 같이 이용될 의료 장비와 조합된 상태에서의 테스트 진행 다수 필요

• 최종 테스트 환경 구축 고려사항
  • 실제와 동일한 환경 구축 목표 X
  • 실제와 비슷하나 그러나 테스터들이 효율적으로 테스팅 가능토록 환경 구축

• 최종 테스트 환경 구축에 테스터 참여하는 이유
  • 최종 테스트 환경 이용법에 대한 이해
  • 조합된 각 의료 장비 연결의 이해

의료용 프로젝트에서의 사용자 시나리오 설계 방법

사용자 시나리오가 필요한 이유 & 의료용 프로젝트에서의 사용자 시나리오 설계 방법

• 사용자 시나리오 설계 필요성
  개발자가 특정 목적을 가지고 개발했을지라도, 사용자가 실제로 제품을 어떻게 사용할지는 미지수
  ⇒ 사용자 측면 테스팅에 있어 가장 중요한 것은 "제품이 어떻게 사용되는지 알아내는 것"

• 의료용 프로젝트 중 사용자 시나리오 설계의 어려움
  • 타 분야 프로젝트 : 사용자 시나리오 분석 위해 사용자 로그 추출하여 사용자 시나리오 설계 진행
  • 의료용 프로젝트 : 법률에 의해 환자 데이터 추출 금지

• 해결 방법
  • 실제 전문가와의 긴밀한 현업이 이상적인 해결법... → 사실상 어려움
  • 테스터들이 기술적인 측면을 감춘 채, 실제 엔드-엔드 관점으로 제품 접근 분석하여 임의의 시나리오 설계

의료용 프로젝트에서의 최종 점검

의료용 SW에서의 최종 검증 절차 및 검증에 대한 한계

• 의료용 프로젝트 최종 검증 절차
  외부 단체(FDA)에 의해 최종 승인 진행

• 외부 단체에 의한 검증의 한계

  1. 문서에 의해서만 검증 진행
     • 결함 보고서, 추적 매트릭스, 최종 검증 보고서만 이용
  2. 프로젝트 최종 마무리 단계만 참여
     • 최종 단계에서 엄격한 규약 적용 → 결함 발견 및 수정 시, 수 많은 TC 및 관련 문서 모두 재작성 필요

• 이 밖에 의료용 프로젝트의 한계
  • 프로젝트 설계에 있어 사업적, 고객(의사), 사용자(환자), 시스템관점에 대해서만 요구사항 정의
    → 각 요구사항의 충족에 대한 명확한 증명 기준은 정의되지 않음 ( ∵ QA 없이 개발자와 기획자만 설계)

• 이와 관련한 QA 엔지니어의 희망사항
  • FDA는 테스터와 긴밀한 소통 진행 희망
  • FDA 검증 시, PM뿐만 아니라 TL도 같이 참여 희망
  • 프로젝트 설계 시, QA 엔지니어도 참여 희망

---

정리

기억에 남는 문장

• 의료용 SW 검증 과정이 아주 엄격할 것이라는 선입견에서 벗어나게 되면, 의료용 SW에서 테스트 하는 것이 QA 엔지니어에 많은 부분을 의존하고 있다는 사실을 알게 될 것이다.
• "어떻게 제품이 출시 가능할 정도의 품질을 확보햇다고 확실을 가질 수 있을 것인가?"
• "결국 제품이 어떻게 사용되는지를 알아내는 것이 가장 큰 관건이었다."
• 내가 FDA의 수행하는 사람이었다면, PM보다 테스터들과 더 많은 이야기를 진행했을 것이다.
• 사람들은 요구사항에 대해 어떻게 증명할 것인가에 대해 생각도 해보지 않고 요구 사항을 작성한다.

배운 것

• 최종 품질 검증은 결국 문서로 이루어진다. 그렇기에 QA 엔지니어의 문서 작성 능력은 중요하다.
• 테스팅은 제품에 대한 이해 & 테스터의 전문 지식에 의해 결정된다. 그렇기에 둘 다 함양하는 능력이 중요하다.
• 사용자가 제품을 어떻게 사용할지는 예측하기 어렵다. 그렇기에 정의된 시나리오 의외에도 다양한 사용자 시나리오를 만들어 내는 것이 중요하다.

참고도서

Adam Goucher, ⌜뷰티풀 테스팅⌟, 지앤선, 2011