기존 발표한 '1인 QA로 살아남는 6가지 방법'의 후속으로 1인 QA 수행사례로 발표한 자료 (W프로젝트 사례)

1. 테스트 수행 사례
- W프로젝트

2. 대상 프로젝트 간략 소개
사례 프로젝트는?
WXX 3.0 프로젝트
통합보안 솔루션,
크게 3가지 서브 업무 시스템으로 구성
(1) CCS(Command Control System),
(2) VMS(Video Management System),
(3) GIS(geographic information systems)
“3.0”?
기존 “1.0”, “2.0”에서 UX/UI적인 요소를 강화하기 위한 “3.0” 수행 프로젝트
개발 목표는?
기존대비 직관적인 워크플로우 설계
CCS, VMS, GIS간의 연동
사용자 친숙한 UI 재정의
사고처리 프로세스 SOP 관리
테스트 목표는?
개발 목표에 따라 UX/UI, 연동 워크플로우에 대한 테스트 수행

3. 2주
13개
정규직 7명(SDET 2명), 협력직 9명
약 6개월(2016.09.01~2017.02.28)
대상 프로젝트 간략 소개
프로젝트 멤버
프로젝트 기간
Sprint 주기
Sprint 개수
133개총 완료 스토리
315개총 결함
사용자 스토리 개수 기준
번다운 차트

4. 전체 테스트 활동
Business Value 측면
개발과 테스트의 목표 정의 2.1 서버 내부 테스트
Test Engineering 측면
1.2 사용자 스토리 Acceptance
Criteria(완료 조건) 정의/ 공유
1.1 Persona 정의와 유스케이스 도
출
1.3 팀 내/외부 협업을 통한
지속적인 피드백
1.4 통합 워크플로우 테스트 정의
2.3 클라이언트 테스트
2.4 기타 품질 활동(with
Jenkins)
2.2 HTTP API 테스트

5. 1.1 업무 분석을 위한 Persona 정의와 유스케이스 도출
- 비즈니스 요건 분석을 위해 WatzEye 관련 사용자 그룹을 정의
- 추가적으로 각 그룹별 상세 유형과 특성을 도출
(1) 오퍼레이터 : 24시간 교대근무 조의 팀원으로 실제 통합보안 관제 업무를 수행하는 사용자
(2) 감독자 : 교대 근무하는 각 조의 팀장으로 오퍼레이터를 감독하는 지침을 내리는 사용자
(3) 시스템 관리자 : 전체 시스템 정보 등을 관리하는 사용자

6. 1.1 업무 분석을 위한 Persona 정의와 유스케이스 도출
오퍼레이터
오퍼레이터에 대한
상세 페르소나 정의를 통해
테스트 요건 고민
※별첨. Persona란?
전문성이
떨어지는
게으른.
불성실
야심 찬,
많은 기능을 원하는

7. 1.1 업무 분석을 위한 Persona 정의와 유스케이스 도출
각 액터별 유스케이스 초안 도출
을 통해 제품에 대한 이해 시도

8. 1.2 사용자 스토리에 대한 AC 작성
Title: Customer withdraws cash
(고객이 현금을 인출한다)
Narrative
As a customer
(고객으로써)
I want to withdraw cash from ATM
(나는 현금인출기에서 현금을
인출하기를 원한다)
So that I don’t have to wait in line at
the bank
(그래서, 은행에서 줄을 서지 않아도
될 수 있도록)
Given the account is in credit,
and the card is valid,
and the dispenser contains cash
(계좌 및 카드가 정상이고 인출기
내부에 현금이 있는 상황에서)
When the customer requests cash
(고객이 현금 인출을 요청하면)
Then ensure the account is debited,
and ensure cash is dispensed,
and ensure the card is returned
(계좌에서 돈이 차감되어야 하고,
현금과 카드가 배출되어야 한다)
대표적인 예
사용자 스토리 종료기준
1..n
※ Acceptance Criteria (인수기준, 완료조건)
: “사용자 스토리가 완료되었다”를 정의할 수 있는 기준 정의
: AC를 통해 사용자 스토리를 더 명확히 정의하고, AC를 통해 이해관계자(PO, 개발,테스트,
고객) 간의 이해 정도를 공유할 수 있다

9. 1.2 사용자 스토리에 대한 AC 작성
분석자,
UX
개발자
SDET
1) 사용자는 CCTV 영상에 대
해 정지, 재시작, 중지 시킬 수
있습니다
4)아, 그렇다면 마우스 컨텍스
트 메뉴 표시라면 왼쪽 어떤
메뉴에서 선택했을 때 표시되
나요?
2) 기능은 마우스 컨텍스트 메뉴
에 있는 건가요? 아니면 상단 툴
바인가요?
3) 한 개 CCTV가 여러 번 중복
재생될 수 있는데 그럼, 여러 개
가 일시에 정지되나요?

10. 1.2 사용자 스토리에 대한 AC 작성
분석 단계
- 기획(분석) 단계에서는 제품의 기능을 모든 이해관계자가 같이 논의
하면서 정의하고 문제의 정의와 해결법을 논의
개발 단계
딜리버리 단계
- 상세 정의가 개발을 가이드하며,
- 각 AC 별 자동화 구축은 개발과 병렬로 진행되며 전체 팀원이 자동
화 구현에 같이 동참하고,마지막에 자동화된 테스트가 통과되면서 개발
완료를 정의할 수 있음
- 이 스펙과 자동화는 그대로 데모가 되고,
- 처음에 정의한 스펙이 그대로 제품에 반영되었음을 확인할 수 있음
상세 정의된 AC상세 정의된 AC
분석자,
UX 개발자 SDET 운영

11. 1.3 팀 내/외부와의 협업
스프린트 안에서 개발과 협업
목 금 월 화 수목 금 월 화 수
HTTP API 테스트
Sprint #N
Sprint #N+1Sprint #N-1
1st week 2nd week
테스트 스크립트
작성 및 수행, 결함보고
사용자
스토리
파악
&
AC
정의
클라이언트/서버
개발 및 단위 테스트
브랜치
Merge
및
확인
결함조치
확인 테스트
결함조치
및
재확인
짝
테스트
(같이,
매뉴얼)
개발
SDET
D-3 개발완료
대상
정의
SP#N-1
GUI 테스트 스크립트
리팩토링
SP#N+1
AC 검토/보완
결과 확인,
코드 리뷰,
결함 보고
외부 공유용
실행 바이너리
내부 공유용
실행 바이너리

12. 1.3 팀 내/외부와의 협업
짝 테스트
- 정해진 시간(30분)동안 개발자와 SDET이 같이 앉아서 테스트를 수행
- 같이 테스트를 진행하면서 개발자는 테스트를, SDET는 제품을 상세 습득
- 짝 테스트 후 SDET은 더 상세 테스트를, 개발자는 바로 결함 수정

13. 1.3 팀 내/외부와의 협업
실제 구현된 제품을 확인하고 최초 정의한 내용과 검증 수행
요건이 명확하지 않은 경우 팀 내부, 외부 이해관계자와 확인
분석자개발자
SDET
저는 이거 어떻게 만들어 달라
는 건지 잘 모르겠어요…
UX
사업부
어? 내가 얘기하는건 그게 아
닌데…
제가 알기로는 이렇게 하는게
맞아요.
아~ 저희가 의도한 건…
그게 아니라

14. 1.4 통합 워크플로우 테스트 정의
개발 중간부터 최종 통합워크플로우 테스트 정의 및 공유
더 많은 이해관계자와 공유하기 위해 워크플로우를 도식화

15. 1.4 통합 워크플로우 테스트 정의
각 워크플로우에 대한 상세 시나리오 작성 및 테스트 수행

16. 전체 테스트 활동
Business Value 측면
개발과 테스트의 목표 정의 2.1 서버 내부 테스트
Test Engineering 측면
1.2 사용자 스토리 Acceptance
Criteria(완료 조건) 정의/ 공유
1.1 Persona 정의와 유스케이스 도
출
1.3 팀 내/외부 협업을 통한
지속적인 피드백
1.4 통합 워크플로우 테스트 정의
2.3 클라이언트 테스트
2.4 기타 품질 활동(with
Jenkins)
2.2 HTTP API 테스트

17. 2. 테스트 레벨별 접근
CCS 서버 내부 테스트
(Controller 테스트 등)
서버단 HTTP 테스트
클라이언트
GUI 테스트
. 대상 : 로직을 담은 일반 자바 클래스에
대한 Junit 테스트
. 주수행자 : 개발자
. 관리여부 : 개발자 판단으로 필요에 따라
(테스트 커버리지 참고)
. 대상 : 스프링프레임워크 상의 Component 대상
. 주수행자 : 개발자
. 검토자 : SDET
. 관리여부 : 대상 도출 후 작성 여부 확인
(테스트 커버리지 참고)
. 대상 : CCS, VMS, GIS 등 변경될 수 있는 서버에
대한 HTTP 요청 테스트
. 주수행자 : SDET
. 관리여부 : 대상 도출 후 별도 계획에 따라 수행
. 대상 : CCS 클라이언트 (VMS, GIS 클라이언트)
GUI 대상
. 주수행자 : SDET
. 관리여부 : 사용자스토리별 테스트 정의
테스트 자동화 피라미드 기반의 접근 전략
각 테스트 대상에 대한 테스트 수행 방안 정의, 샘플 코드 제공 및 수행

18. 2.1 서버 내부 테스트
목적 : 서버 개발과 동시에 쉽게, 빠르게 검증(디버그)하기 위한 Junit 코드 작성
대상 : 신규 개발 기능(기존 기능 제외)
주수행자 : 서버 개발자
TestUtil
테스트에 사용되는
유틸리티 메소드
TestException
테스트 상황에 따른
Exception 정의
TestConstants
테스트에 사용되는
상수값 정의
MockWebApplication
ContextTestCase
setUpClass{~JNDI설정~}
AbstractTransactionalJUnit4
SpringContextTests
스프링이 제공하는
테스트 유틸
MockWebApplication
ContextTestCase
MockWebApplication
ContextTestCase
MockWebApplication
ContextTestCase
가DataOperationTest
:: select가withRequiredParamsOnly
:: select가withAllParams
…
MockWebApplication
ContextTestCase
AABizOperationTest
:: selectUserInfoTest_Normal
:: selectUserInfoTest_Invalid
…

19. 2.1 서버 내부 테스트
개발 IDE에서 바로 테스트를 수행하고 수행 결과와 테스트 커버리지 확인이 가능

20. 2.2 HTTP API 테스트의 구성
WXX 2.0
Server
WXX 3.0
Server
WXX 4.0
Server
WXX 3.0
C# Client
WXX 2.0
C# Client
WXX 4.0
Client
서버, 클라이언트가 서로 이질적으로 구성되고, HTTP API를 통해 인터랙션 됨
각 버전 간 서버, 클라이언트의 속 알맹이는 변경될 수 있지만 API 레벨에서는
일관성이 필요
HTTP Request: {url}/XXBiz, Parameter: ..,.,,.,,.,,
HTTP Response:: 200, SUCCESS, Response body is~~
과거 현재 미래

21. 2.2 HTTP API 테스트의 구성
개발 프로젝트와 별도 프로젝트로 테스트 프로젝트 구성
상수로 정해진 IP 정보(예:개발 WAS)로 HTTP Reqeust 요청 후 결과 검증

22. 2.3 클라이언트 GUI 테스트 자동화
Challenge & Risk
. 개발과 동시에 GUI 테스트 자동화를 구축(스크립팅)할 수 있을까?
. 변경이 심한 GUI에 대해 변경을 잘 반영할 수 있을까?
. C#, WPF UI에 대한 GUI 테스트 자동화는 어떻게 구현할 수 있을까?
- 발췌: 테스트 자동화 회고 -
(1) 개발과 동시에 해보니 UI가 결정되지 않거나, 이후 변경되기로 결정되는(?)
상황이 비일비재
(2) WPF기반에 커스터 UI 콤포넌트를 많이 쓰다보니 변경이 되면 처음부터 재작업해야
하는 경우가 대부분
(3) CodedUI라는 툴을 발굴하여 해결, Best Practice는 더 해 봐야…
(4) GUI 테스트 자동화의 우선순위가 제일 낮고, 개발 완료가 더디다 보니 제일 뒷전이…

23. 2.3 클라이언트 GUI 테스트 자동화
GUI 테스트 툴 선정
항목
Windows
Automation API
Coded UI White Sikuli autoit
설명
UI Automation Library, low
-level library
Visual Studio 엔터프라이즈에
내장된 UI Automation 기능,
based on the low-level UI Aut
omation library
based on the low-level U
I Automation library,
(https://github.com/TestSt
ack/White)
이미지 인식 기반의
범용 GUI 테스트 툴
윈도우 기반 프로그램의
오브젝트 인식 기반 GUI
매크로 툴 – WPF 인식이
안 되어 대상 제외
비용 오픈소스(무료)
Visual Studio 2015 Enterpris
e 버전에 포함
(기존 VS Ultimate or Premiu
m 에 포함)
Free
(TestStack-Thoughtsworks
)
오픈소스(무료) 오픈소스(무료)
대상 WPF WPF, MFC, 웹 등등 WPF applications only anything 윈도우 기반 프로그램
방식
라이브러리이고 이 라이브러
리를 활용해서 코드전체를 다
짜야 함
Record 방식 지원
블랙박스 형태로 접근
UI Automation library
를 사용하여 스크립트 작
성
이미지 인식 기반으로
automates anything you
see on the screen
윈도우 오브젝트 인식 방
식
스크립트
언어
C# C# whatever.NET language Python
Jenkins
연계
-
Jenkins 플러그인인 MSTest
를
활용하여 테스트 수행 가능
좌동
커맨드 라인 명령어 등
으로
연계
BDD툴
연계
-
.NET 기반의 SpecFlow 연계
가
가능하기는 함
커맨드라인 레벨에서
robot framework과 연
계 가능하다고 함
강점
라이브러리로
무료 사용 가능
해외 레퍼런스 다수 있음
MicroSoft가 보장하는 상용툴
무료, 특정 기술이 의
존적이지 않고 거의 대부
분의 동작 자동화 가능,
위치에 관계없이 이미지
만 같으면 인식 가능
약점
실제 API 수준으로
코딩 작업 필요
유료
BDD 연계를 위해서는
Wrapper를 이용해서 모듈화
해서 호출해야 하는 것으로 보
임
이미지 인식을 위해 수
행 PC의 해상도 통일이
필요,
이미지 변경 시 민식 안
됨
BDD 연계가 취약

24. Client UI
2.3 클라이언트 GUI 테스트 자동화
GUI 레벨에서 동작을 Record하고,
스크립트로 생성한 후 Play하는 방식의 툴
기록 <> 일시정지
기록된 단계 표시
콘트롤 조사 및 어설션 추가
코드생성
COMMON폴더
: 공통 파일
Tests 폴더
: 테스트 코드
UIMaps 폴더
: 화면별 UIMap 코드
샘플 테스트 프로젝트
1)Record
4) Play
2)Generate
3)Modulize&Refactoring
Assertion

25. 2.3 클라이언트 GUI 테스트 자동화
데모 시나리오 간략 소개
[ 동영상 1 ]
1) CCS 로그인(“관리자”)
2) 알람 발생 (테스트용 임의 HTTP Request 수행)
3) 해당 알람을 오퍼레이터(“operator”)에게 처리지시
[ 동영상 2 ]
4) CCS 로그인(“오퍼레이터”)
5) 할당 받은 알람을 접수(Acknowledge)
6) 해당 알람 대응(Response탭 이동)
7) 정해진 대응 절차(SOP)에 따라
(1) 각 절차 Complete 처리 후 내용 입력
(2) Add Task
(3) 최종 완료 처리
8) 목록 조회

26. 2. Jenkins 기반의 개발 빌드/테스트 자동화 구축
[ 서버 ] [ 클라이언트 ]
개발빌드(jar) 1
소스 내려받기,
ant 빌드 스크립트
개발빌드(war) 2
소스 내려받기
Ant 빌드 스크립트
Junit 서버 테스트,
테스트 커버리지 측정
코드 인스펙션(pmd)
HTTP API 테스트
(Maven 스크립트)
클라이언트 소스 빌드
(소스 내려받기,
MSBuild 로 클라이언트 빌드)
GUI 테스트 수행
MSBuild로 테스트 프로젝트 빌드,
MSTest로 테스트 실행
개발
빌드
서버
테스트
코드
인스펙션
HTTP API 스펙 문서생성
(mvn –doc)
HTTP API
테스트
C#
빌드
클라이언트
GUI 테스트

27. 2. Jenkins 기반의 개발 빌드/테스트 자동화 구축
서버 테스트 서버 코드 인스펙션
Jenkins 잡 구성
API 테스트 결과
API 스펙 생성

28. 3. 정리
API 테스트 결함
API 테스트 결함
API 테스트 결함
클라이어트 빌드 실패
GUI 테스트 결함
클라이어트 빌드 실패
API 테스트 결함
API 테스트 결함

29. 3. 정리
클라이언트 개발자 회고
(좋았던 점)
(나빴던 점)
구분 가 업무 나 업무
AC 정의 및
사전 리뷰,
(A)AC리뷰를 통해서 개발 전에 무엇을 할지 2중으
로 자세히 체크해서 좋았다.
(B) 나는 AC회의를 참석 안 해서 시간 절이 많이
됐다-업무 리더가 다시 정리해서 공유해 줬다
(가)개발 전에 AC를 통해서 공유하고 의사소통할 수 있
었다
(마) AC 회의를 참석할 수 있어서 좋았다. 적힌 내용 외
에도 궁금한 내용을 다이렉트로 묻고 확인했다
(A)업무리더로 AC리뷰를 하기는 했는데 나중에 보
니 놓친게 있거나 원래 의도가 잘 전달 안 된 부분
이 있었다
(가)AC공유가 스프린트 첫째날이 아니어서 좀 늦었다
짝 테스트
(A) 짝테스트를 하고 싶었는데 많이 못했다 (마) 테스트하는 사람만큼 다른 이해관계자들도 제품이
나 개발 상황에 대해 깊게 봐줬으면 좋겠다
(사)짝 테스트를 많이 못했다
테스트 수행,
결함관리
(MyTask)
(A) 테스트를 통해서 내가 체크 안 했던 부분도 체
크 됨
(C) 테스트 잘 찍어서 해주어서 도움이 많이 되었
다
(가)업무 역할자 별로 서로 말이 잘 통해서 좋았다
(마)테스트 수행 시 SDET이 다른 역할자간 조율이 좋았
다. 노련미가 돋보였다
(A) UI감수 내용과 겹치는 결함이 너무 많았다/
SDET이 빌드를 해서 개발자의 일을 덜어줬으면 좋
겠다
(B) MyTask 사용법을 잘 모르겠다. 전체 프로세스
도 잘 파악 못함.
(C) UI감수와 겹치는 결함이 많았다
SDET이 UX와 먼저 검토 후 진행했으면 좋겠다
(마) 지나고 난 다음에 기능 변경이 많기도 했고, 프로
젝트 말미에 다른 기술을 검토하는 과정에서 되던 기능
이 안 되어 안타까웠다
(사) MyTask 에 Resolve 넘기는 시점과 바이너리 넘기
는 시점이 안 맞았는데, 이에 대해 SDET이 사전 설명
없이 퇴짜를 놓아 서운했다(사전 교육 때 설명 안 해 줬
음)

30. 감사합니다