�ݺ�ߣ

2021.09.
Validation of XXX Product
(SQE team)

2
Contents
Overview
• SQE Team
• What is ‘Product Quality’ for SQE
• CASES : Quality Failures
How we work
• Dev & Test Process(V-Model)
• Software Life-cycle
• Details
1) Review / Planning
2) Test Execution
3) Other types of Testing
4) Release / Operation
Conclusion
• Summary
• Goals and Concerns
• Messages

Overview
- SQE Team(Radiology)?
- What is ‘Product Quality’ for SQE
- CASES : Quality Failures

4
What is “Product Quality”?
product
Quality?
https://kalyan-city.blogspot.com/2013/05/what-is-product-quality-definition.html
Product(or Service) meets
customer needs(wants) and expectations
사용자의 요구사항과 기대사항을 충족시키는 것

5
Lunit INSIGHT Quality
‘Product Quality’ for SQE
제품
파트너사,DE팀
인허가, 인증
비즈니스
제품 사용자
(환자, 의사,)
- 제품이 기대한 대로 잘 동작하는지
- 정해진 절차와 방식으로 개발하고
검증하고 있는지
- 설치하고 사용하기 용이한지
- 문제가 발생했을 때 문제의 현상과
추정 원인 파악이 용이한지
- 우리 고객의 needs를 빠르게 반영
- 우리 제품만의 강점을 잘 표현하고
있는지
- 환자들의 병변을 적절하고 효과
적으로 알려주는지
- 의사들의 업무를 더 효율적이고
쉽게 지원하고 있는지
SQE
다양한 이해관계자의 요구사항과 기대사항을 충족시키는 것!!
!?!

6
Quality Failure Cases : General
New Coke의 실패 방사선 치료기(Therac25)
가상화폐 거래소(일본,Zaif) 오류
직접적인 손실 외에도 회사 이미지, 신뢰도에 큰 타격
코카콜라 회사의 마케팅 부서가 눈을 가리고 Coca
Cola와 Pepsi Cola를 시음하는 테스트를 했는데 다수
가 펩시를 선호함.
따라서 코카콜라 측이 Coke를 Pepsi의 맛과 유사하게
변경했지만 기존 Coke 제품에 강한 애착을 가진 고객
들이 이 New Coke를 거부하고 불만을 표출함. 4개월
후 회사는 Classic Coke라는 이름으로 원래 제품을 되
돌려 놓았으며 New Coke는 완전 중단
제품 전략 실패

7
Quality Failure Cases : Lunit
MMG Contour가
엉뚱한 곳에 그려짐
내부 공통 라이브러리에서
메모리 누수 의심
참조 라이브러리
(버전)호환 오류로 분석실패
~~
~~
~~

How we work
- Validation Strategy & Approach
- Dev & Test Process(V-Model)

9
Dev & Test Process(V-Model)
V-Model 상에서 개발 프로세스와 검증 프로세스
Detailed
Software
Design
Unit
Implement
ation
Unit/
Module
Test
Software
Integration
Software
System
Testing
- 요구사항 검토
- 검증요구사항분석
- 코드 리뷰
- 코드 정적분석
- Alpha Test
- RC Test
- Aging 테스트
- Score 비교 테스트
- 마이그레이션 테스트,…
- Unit Test(pytest,…)
- Dev Test
- 개발계획 수립
- 요구사항 분석
- 상위 기획
- 상세 기획
- 기본/상세설계
- 코드 구현
- (API) Test Automation
- pytest /coverage
(*IEC 62304 based)
- 검증계획 수립
Requirements
Analysis
- 아키텍처/설계 검토
- 테스트 설계
- 테스트 데이터 정의,확보
- 테스트 환경 구성
Verification
&
Validation

10
Software Life-cycle
SW
개발계획
SW
요구사항
분석
개발단계별 QA Process
(*IEC 62304 based)
Customer
Needs
SW
아키텍처
설계
SW
상세설계
SW
유닛 구현
및 검증
SW
통합 및
통합테스
트
SW
시스템
테스팅
SW
릴리즈
SW
설치 및
운영
Customer
Needs
Satisfied
. 전체 검증계획 수
립
(검증 목표, 공수,
일정)
. 요구사항 검토
. 테스트 요구사항
분석
. 검증계획 상세 수
립
. 아키텍처 검토
. 테스트환경
구상
. 테스트 설계
. 테스트 데이터 정
의, 확보
. 테스트 환경 구성
. 코드 리뷰
. 개발자 테스트
. 코드 정적 검사
(pylint, sonarlint,
…)
. 알파 테스트
. RC 테스트
(회귀테스트)
. Dicom Set
테스트
. API 테스트
. 에이징 테스트
. 장비 설치 테스트
(버전 호환, 데이터
마이그레이션 등)
. 릴리즈 노트 작성
. known-issue 정
리
. 릴리즈 히스토리
관리
. 운영 모니터링 및
이슈 대응
*검증 일정 *QC Plan *QC Plans *TestCase
*QC Plan
*pytest/coverage
*개발자테스트 체
크리스트
*테스트결과(결함) *테스트결과 *release note
*QC Summary

11
Details
1) Review / Planning
- Requirements, Architecture/Design Review
- Planning(QC Plan, Test Design)
- Test Design

12
요구사항 검토
(1)_Review for Requirements, Architecture
요구사항이 논의되고, 제품 아키텍처/설계를 고민하는 단계에서부터 같이 검토
아키텍처/설계 검토
SW
요구사항
분석
SW
아키텍처/
상세설계
. 요구사항 정제 : 요구 사항에 오류가 없는지, 제품 특성과 맞지
않은 요구사항 인지, 이미 존재하는 기능에 대한 중복 요구사항
인지 등의 관점에서 검토 및 논의
. 요구사항 상세화 : 사용자의 요구사항으로부터 숨어있는 시나
리오(비기능 요구사항 포함)를 찾아내어 구체적으로 요구사항을
정리
A 사용자의 요구사항이 다른 B 사용자의
요구사항과 유사한 점이 있어, 2가지를 묶
어 같이 검토되면 좋을 것 같습니다
이 요구사항을 반영하면, 기존에 존재하는
기능과 다양한 상황이 발생할 수 있어, 각
상황별 동작을 정의할 필요가 있습니다
. 아키텍처/설계 검토
- 배포 및 설치에 용이한 구조인지(문제가 없을지)
- 비기능적 특성(사용성, 유지보수성, 재사용성, 신뢰성, 성
능 등)에 따른 문제가 발생하지 않을지
- 상세 기획 내용과 상이함이 없는지
이 기능, 제품을 더 범용적으로 사용하
기 위해서 이런(#) 구조로 가져가는건
어떨까요?
현재 구현방안으로는 원래 얘기됐던
요구사항을 부분적으로만 만족시킬수
있을 것 같습니다.

13
검증계획 수립
(2)_Planning
신규 버전에 반영할 기능에 대해 검증 대상,
범위, 공수, 일정 등의 계획을 수립
필요한 테스트 도구나 필요 기술 사전 스터디
전체 릴리즈 일정에 대한 계획 수립 -> 주요 반영 Feature별 검증 계획 -> 상세 기능단위 테스트 계획 수립
[ 작성항목 ]
각 검증대상 기능별
. 개요
. 영향받는 제품(모델) 확인
. 필요인원 및 예상 기간
. 테스트 환경 구성 계획
상세 QC Plan 작성 테스트 설계
분석한 테스트 포인트에 대해 상세 테스
트 케이스를 작성
[ 작성항목 ]
- 테스트 목적
- 사전 설정 조건
- 테스트 데이터
- 수행절차
- 기대결과
- 실제 테스트결과
기획서, 구현방안 등을 참조하여 상세내용
을 파악한 후 상세 QC Plan을 작성
[ 작성항목 ]
. 테스트 목적
. 테스트 대상(범위)
. 테스트 환경
. 테스트 일정
. 주요 검증 내용
Test Point#N
Feaures#N
SW
개발계획
SW
요구사항
분석

14
(3)_Test Design
제품 App Type 구분
Feature
(테스트 목적)
Prio
rity
테스트
데이터
사전조건 절차
기대
결과
테스트
결과
GW CXR3
기본
흐름
dicom분석
병변이 있는 환자
의 영상 분석
P1
“A_patient.dcm
”
GW Admin을 통해
SC(Report), color
map, 출력 설정
1.storescu 기능을 이용하여 환자의
x-ray 영상을 전송
2.GW(BE 및 IS)의 로그 모니터링
3.GW의 received, repository 저장
소 확인
4. GW Admin의 Task 결과 확인
5. 결과 dicom이 요청한 설정대로
정상 생성되었는지 확인
2.정상분석 로그 출력
3.원본 dicom파일 및 결과 sc
jpg 이미지가 각각 received,
repository 폴더에 생성된다
4.분석결과가 Task 메뉴에 조회
된다
5.결과 dicom 정상생성
(상세 옵션 : ~ )
GW CXR3
에러
흐름
dicom분석
출력설정이 잘못된
경우
P1
GW Admin 설정에
서 출력 정보가 잘못
설정
: 미존재 ip address
1.storescu 기능을 이용하여 환자의
x-ray 영상을 전송
3.GW Admin의 Task 결과 확인
2. 사전 설정값에 따라 {30}초단
위로 {3}회 재전송 시도 후 최종
실패 로그 출력
3. 최종 결과 Fail로 조회된다
BE CXR3
기본
흐름
API: (POST)
/{app}/dcm/
정상업로드 P1 “A_patient.dcm”
BE Admin 기본(#)설
정
API 호출 후 응답 결과 확인
200(ok)응답 및 BE상에 저장된
uuid를 반환한다
IS CXR3
기본
흐름
API: (POST)
/predict/
기본동작 P1
[요청파라미터]
filtering=true
threshold = 0.15
……
200(ok)응답 및 분석결과과
json 형태로 반환된다
각 제품 개별/통합 관점에서
상세히 확인해야지
테스트 설계
• 다양하게 발생하는 있는 상황과 기대하는 동작을 분석하여 다양한 “테스트 케이스” 를 설계
• 각 제품별 개별 접근, 전체 제품 통합 관점에서 테스트를 고민
• 테스트하기 위해 필요한 테스트 환경과 데이터 확인
SW
상세설계

15
Details
2) Test Execution
- Typical Test Procedure
- Alpha / RC Test
- Products Integration vs Isolated Test
- API Test (Automation)

16
(4)_General Test Procedures - 1/5
안녕하세요. Lunit여러분!!
저는 의사 sue예요.
저는 XX 제품이 제공해 주는
SC 영상을 이용해 환자분의 상태를 잘 파악하고, 환자
분에게도 잘 설명해 드리고 싶어요.

17
Admin
PACS
dicom-gateway insight-backend insight-inference-server
0) settings
1) Dicom received
2) Upload dicom
3) Request to analyze
5) Get the results
4) predict
insight
engine
6) Send result
제품 구성과
동작
• 어드민 기능을 이용해 제품의 상세 설정
• 3개의 제품- GW(Dicom-Gateway), BE(Insight-Backecn), IS(Inference-Server) 으로 구성
• 요청받은 영상 이미지를 GW-BE-IS의 연동을 통해 결과 제공
미리 설정어드민을
통해 원하는 결과가
출력되도록 설정
GW는 BE에 분
석 요청
BE는 IS에 분석
요청
분석 결과를 반
환

18
설치 설정값 수정/
제품설치
어드민 설정 변경 영상 입력 명령 실행 각 제품 로그 확인
결과 파일(dicom)확
인
( Docker settings )
- TIMEZONE
- ~
테스트 수행
다양한 테스트 케이스에 따라 필요한 환경을 구성하기 위해
• 제품 설치 시 설정 값 변경 및 docker 기반 설치
• 각 제품의 어드민 설정을 이용해 상세 설정 변경
- Docker start
( ADMIN settings )
- Network (Input/ Output)
- Output Dicom
- SC Display mode
- SC Result type
- Language
…

19
테스트 수행
각 제품 로그 등을 통해 분석 과정 확인
• 테스트 케이스에 맞는 테스트 데이터(영상)를 준비하고, 해당 영상을 업로드
• 각 제품의 로그 모니터링
• 분석 결과에 대한 상세 확인
설치 설정값 수정/
제품설치
어드민 설정 변경 영상 입력 명령 실행 각 제품 로그 확인
결과 파일(dicom)확
인
별도 Viewer를 이용해 결과 상세 확인
- 테스트를 위한 영상 dicom 파일 준비
- DIMSE 프로토콜로 전송

20
제품 App Type 구분
Feature
(테스트 목적)
Prio
rity
테스트
데이터
사전조건 절차
기대
결과
테스트
결과
GW CXR3
기본
흐름
dicom분석
병변이 있는 환자
의 영상 분석
P1 “A_patient.dcm”
GW Admin을 통해
SC(Report), color
map, 출력 설정
1.storescu 기능을 이용하여 환자의 x-
ray 영상을 전송
3.GW의 received, repository 저장소
확인
4. GW Admin의 Task 결과 확인
5. 결과 dicom이 요청한 설정대로 정
상 생성되었는지 확인
2.정상분석 로그 출력
3.원본 dicom파일 및 결과
sc jpg 이미지가 각각
received, repository 폴더에
생성된다
4.분석결과가 Task 메뉴에
조회된다
5.결과 dicom 정상생성
(상세 옵션 : ~ )
PASS
GW CXR3
에러
흐름
dicom분석
출력설정이 잘못된
경우
P1
GW Admin 설정에
서 출력 정보가 잘
못 설정
: 미존재 ip address
1.storescu 기능을 이용하여 환자의 x-
ray 영상을 전송
3.GW Admin의 Task 결과 확인
2. 사전 설정값에 따라 {30}
초단위로 {3}회 재전송 시도
후 최종 실패 로그 출력
3. 최종 결과 Fail로 조회된
다
PASS
BE CXR3
기본
흐름
API: (POST)
/{app}/dcm/
정상업로드 P1 “A_patient.dcm”
BE Admin 기본(#)설
정
200(ok)응답 및 BE상에 저장
된 uuid를 반환한다
FAIL
IS CXR3
기본
흐름
API: (POST)
/predict/
기본동작 P1
[요청파라미터]
filtering=true
threshold = 0.15
……
200(ok)응답 및 분석결과과
json 형태로 반환된다
PASS
앗, 문제가 있어!!
개발팀과 확인해 봐야겠다.
테스트 수행
• 각 테스트 케이스 별 실제 결과를 작성
• 결함이나 이슈가 있는 경우 별도 관리시스템(Asana)를 통해 기록을 남기고, 개발팀과 확인

21
(5)_Alpha / RC Testing
구분 Test Target Test Environment Test Results
Alpha Test
New and Changed features only
각 기능별 테스트 케이스, 데이터
각 기능 또는 QE별 개별 테스트 환경 구축 신규/변경된 기능의 테스트 결과
RC Test
전체 테스트 케이스
(Regression Test)
통합된 테스트 환경 전체 테스트 결과
점진적 통합 : Alpha 테스트에서는 주요한 신규/변경 기능을, RC 테스트에서는 기존 기능 포함 전체 테스트를 수행합니다
* RC: Release Candidate
Alpha Test RC Test
a1
a2
a3
feature A
feature B,C
feature D
issue#N~ fix
issue#M~ fix
code freezing
New/Changed
Features
Not changed
Features
…
(RTM)
Release
SW
통합테스트
rc2
rc1
rc...
* RTM: Release To
Manufacturing

22
A Product Isolation Testing
Products Integration Testing
(6)_개별 제품 테스트
GW BE IS
요청,
정상 응답
제품간의 연동 상황에서
임의의 에러상황이나 특정 결과
를
반환하게 하고 싶다!!!!
요청 요청,
정상 응답
GW
요청
요청,
비정상 응답
(더미서버 응답 설정)
400(bad request),
{
‘message’:’request…’
}
BE IS
요청,
정상 응답
각 제품간에 발생할 수 있는 다양한 상황을 임의로 발생시켜 테스트 커버리지 향상
실제 제품이 아니라,
임의로 동작을 지정할 수 있는
‘더미서버＇를 활용
상황 예1) 특정 API의 응답이 오래 걸리거나, 응답이 안 오도록 설정
상황 예2) 다른 제품에서 오는 분석 결과를 원하는 특정 응답으로 오도록 상세 설정
상황 예3) 임의의 응답 에러(404 Not Found, 400 Bad Request, 500 Server Error,...)와
메시지가 발생한 상황에서 제품 동작 확인 등
dummy
-BE
dummy
-IS
SW
통합테스트

23
(7)_API 테스트(자동화) SW
통합테스트
검증 공수 절감을 위해 반복적이고 결과가 명확한 부분에 테스트 자동화 적용 검토
- 코드레벨에서는 개발팀이 테스트 코드 작성(pytest 등), QE팀에서는 테스트 결과/커버리지 결과 확인
- QE팀에서는 HTTP API에 대해 PostMan, Jmeter, pytest(requests)를 이용하여 테스트 스크립트 작성
자동화 대상 선정
기본 동작 확인 외에도,
반복적이고 결과가 확실한 부분
을 API 테스트 자동화 대상으로
선정
테스트 스크립트 작
성
Python/Requests (PostMan,
JMeter) 등을 이용하여 자동으
로 반복적으로 호출하고 그 결
과를 확인하는 스크립트를 작성
테스트 자동수행
스케쥴러(Jenkins)를 통해 매일
, 또는 코드 변경이 발생할 때마
다 자동으로 수행
테스트 결과 알림
테스트 결과 보고서를 생성하고
, 그 결과를 슬랙 등을 통해 실
시간으로 알림
pytest
/requests
GW BE IS
10개 결과 텍스트가
9개 언어별로 정상 출력되는지
매번 확인해야 하네…
10X9=…

24
Details
3) Other types of Testing
- Pre-defined Dicom-Set Test
- Aging(Soak) Test
- Other Non-Functional Test

25
CXR, MMG 스코어 비교 결과
(8)_Predefined Dicom-Set Test
미리 정해놓은 테스트 셋(Validation Dicom Set)에 대해 신규 버전의 유효성 검토 (오류, 기존 버전과의 스코어 차이 정도)
… …
신규 버전
기존 버전
-
- 비교 검사 셋
이번 MMG 5.7.2 모델에서
기존대비 전체적으로
Max Score가 높게 나온 현상
이…
아!! 특정 장비에 대한 fine-
tuning을 더해서 5.7.2.1로
내도록 하겠습니다!
(CXR 결과 예)
a) 각 병변별 스코어 차이 평균값,
b) 스코어 차이 구간별 분포도,
c) 스코어 차이가 가장 큰 top 3,
d) 비교 버전별 전체 대비 스코어 분포
SW
시스템
테스트
Pre-defined dicom set (CXR/MMG)

26
테스트 결과(실시간 모니터링)
(9)_Aging(Soak) Test
Aging(Soak) Test : 오랜 시간동안 대량 부하(huge volume of load) 상황에서, 애플리케이션의 성능을 측정하는데 사용되는 비기능 테스트의
한 유형으로 저희는 긴 시간(2-3일)동안 반복적으로(ex.10초단위) 분석요청을 진행해서 테스트 시간에 따른 시스템의 메모리 증가, 성능 정보의
변화 등을 확인합니다
- 메모리 사용량
- 평균 분석 시간 등 추이 모니터링
각 제품의 성능 지표와 저장된 분석 소요 시간 등을
수집하여 Grafana로 시각화
SW
시스템
테스트
XX 제품의 메모리 사용량 추이
가 점점 높아지는데…
어딘가 메모리 누수가 있는 것
같아요!!
확인해 보니, 저희가 내부적으로
참조하는 외부 라이브러리의 특
정 로직을 타는 경우에...

27
설치 환경 호환성, 이식성 / 파트너 제품 연동 네트워크 이슈 상황
버전 업데이트 확인 보안관점 테스트
(10)_Other types of validations
SW
시스템
테스트
- 이전 데이터에 대한 정상 유지, 이전(Migration) 확인
- 업데이트 시점에 분석 중인 건에 대한 동작 검토
- 네트워크 단절, 방화벽 상황에서 적절한 처리
- 의존 관계에 있는 다른 제품의 네트워크 단절 상황 등
- 인증된 키에 대한 적절한 체크
(유효하지 않은 접근에 대한 차단)
- 라이센스 정책에 따른 올바른 동작 확인
- 세션 타임아웃, 로그인/비밀번호 정책 적용 확인
- 비밀번호 변경 주기 적용 등
- NVIDIA(GPU), Jetson, OpenVINO 등 다양한 설치환
경에서 정상 동작 확인
- GE,FF 등 파트너 제품과의 연동 관점
기능 검증
//

28
Details
4) Release / Operation
- Release
- On-site Issue monitoring

29
(11)_Product Release SW
릴리즈
- 테스트 결과 정리, 배포되는 기능 정보, 릴리즈 노트, Known-Issue 등 정리
- DE팀과 설치 및 현장 대응을 위한 인수인계
릴리즈 및 배포를 위한 DE팀 인수인계 세션
a) 반영된 주요 Feature 설명
b) 설치 시 유의사항
c) Known-Issue
d) 릴리즈 노트 설명
[QC
Summary]
~~
~~
제품 릴리즈 개요
주요 Feature
(상세링크)
상세 컴포넌트별
테스트 결과, 특
이사항 등
제품별
릴리즈 정보
설치시 유의사항
[ QC Summary ]

30
(12)_현장이슈 1차 분석 및 대응
- 현장 이슈, 문의 내용에 대해서도 DE팀과 함께 확인 및 대응 (DE팀 - QE팀 - 개발팀)
SW
릴리즈

3. Conclusion
- Summary
- Goals and Concerns
- Final Message

32
Summary - SQE Activities & Strategy
Strategy & Approach
작은 단위에서 점점 더 큰 단위로
더 이른 단계에서
이해관계자와 협업
자동화 검토/적용
Review for Requirements, Architecture
Planning
Test Design
Alpha / RC Testing
Test Execution
API 테스트(자동화)
개별 제품 테스트
Validation Dicom SetTest
Aging(Soak) Test
Other types of Non-Functional Testing
Learning From Everything
Continuous Improvement
Activities

33
고민중
목표
Goals and Concerns
제품 품질!!
고객의 만족
고객,
비즈니스
제품팀,
개발
회사 내,외부 다양한 이해관계자 간에
브릿지 역할을 하여 좋은 품질의 제품을 만드는 것!!
SQE!!!
- SQE Goals and Concerns

35
Final Message
‘Product Quality’ for ALL
제품
파트너사,DE팀
인허가, 인증
비즈니스
제품 사용자
(환자, 의사,)
- 제품이 기대한 대로 잘 동작하는지
- 정해진 절차와 방식으로 개발하고
검증하고 있는지
- 설치하고 사용하기 용이한지
- 문제가 발생했을 때 문제의 현상과
추정 원인 파악이 용이한지
- 우리 고객의 needs를 빠르게 반영
- 우리 제품만의 강점을 잘 표현하고
있는지
- 환자들의 병변을 적절하고 효과
적으로 알려주는지
- 의사들의 업무를 더 효율적이고
쉽게 지원하고 있는지
Quality!!

37
Software Life-cycle
SW
DEV Planning
SW
Requirem
ents
Analysis
Product QA Process in Software Life-cycle
(*IEC 62304 based)
Customer
Needs
SW
Architect
ure
SW
Detailed
design
SW
Unit
impleme
ntaion/T
est
SW
Integrati
on /IT
Test
SW
System
Test
SW
Release
SW
Release /
Operatio
n
Customer
Needs
Satisfied
. Release QC Plan . review
requirements
. test
requirements
analysis
. Feature QC Plan
. review
Architecture/desig
n
. plan test
environments
. test design
. design test data
. develop test
environments
. code review
. developer tests
. code inspection
(tools)
. Alpha Test
. RC Test
(Regression Test)
. pre-defined
dicom set Test
. API Test
. Aging(Soak) Test
. Deploy Test
(version update,
data migrations,...)
. Release notes
. known-issue
. release version
history managing
. onsite issue
monitoring,
analysis
*QC Schedule *QC Plan *QC Plan *TestCase
*QC Plan
*pytest/coverage
*developer test
checklist
*Test Results and
issues
*Test Results *release note
*QC Summary

�ݺ�ߣ

우리 제품의 검증 프로세스 소개 자료

Recommended

More Related Content

What's hot (20)

Similar to 우리 제품의 검증 프로세스 소개 자료 (20)

More from SangIn Choung (18)

우리 제품의 검증 프로세스 소개 자료