테스트 수행 사례

- W프로젝트

대상 프로젝트 간략 소개

사례 프로젝트는? 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, 연동 워크플로우에 대한 테스트 수행

2주

13개

정규직 7명(SDET 2명), 협력직 9명

약 6개월(2016.09.01~2017.02.28)

대상 프로젝트 간략 소개

프로젝트 멤버

프로젝트 기간

Sprint 주기

Sprint 개수

133개 총 완료 스토리

315개 총 결함

사용자 스토리 개수 기준 번다운 차트

전체 테스트 활동

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 테스트

1.1 업무 분석을 위한 Persona 정의와 유스케이스 도출

- 비즈니스 요건 분석을 위해 WatzEye 관련 사용자 그룹을 정의

- 추가적으로 각 그룹별 상세 유형과 특성을 도출

(1) 오퍼레이터 : 24시간 교대근무 조의 팀원으로 실제 통합보안 관제 업무를 수행하는 사용자

(2) 감독자 : 교대 근무하는 각 조의 팀장으로 오퍼레이터를 감독하는 지침을 내리는 사용자

(3) 시스템 관리자 : 전체 시스템 정보 등을 관리하는 사용자

1.1 업무 분석을 위한 Persona 정의와 유스케이스 도출

오퍼레이터

오퍼레이터에 대한

상세 페르소나 정의를 통해

테스트 요건 고민

※별첨. Persona란?

전문성이 떨어지는

게으른. 불성실

야심 찬, 많은 기능을 원하는

1.1 업무 분석을 위한 Persona 정의와 유스케이스 도출

각 액터별 유스케이스 초안 도출

을 통해 제품에 대한 이해 시도

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, 개발,테스트, 고객) 간의 이해 정도를 공유할 수 있다

1.2 사용자 스토리에 대한 AC 작성

분석자, UX

개발자

SDET

1) 사용자는 CCTV 영상에 대해 정지, 재시작, 중지 시킬 수 있습니다

4)아, 그렇다면 마우스 컨텍스트 메뉴 표시라면 왼쪽 어떤 메뉴에서 선택했을 때 표시되나요?

2) 기능은 마우스 컨텍스트 메뉴에 있는 건가요? 아니면 상단 툴바인가요?

3) 한 개 CCTV가 여러 번 중복 재생될 수 있는데 그럼, 여러 개가 일시에 정지되나요?

1.2 사용자 스토리에 대한 AC 작성

분석 단계 - 기획(분석) 단계에서는 제품의 기능을 모든 이해관계자가 같이 논의

하면서 정의하고 문제의 정의와 해결법을 논의

개발 단계

딜리버리 단계

- 상세 정의가 개발을 가이드하며,

- 각 AC 별 자동화 구축은 개발과 병렬로 진행되며 전체 팀원이 자동

화 구현에 같이 동참하고,마지막에 자동화된 테스트가 통과되면서 개발

완료를 정의할 수 있음

- 이 스펙과 자동화는 그대로 데모가 되고,

- 처음에 정의한 스펙이 그대로 제품에 반영되었음을 확인할 수 있음

상세 정의된 AC 상세 정의된 AC

분석자, UX 개발자 SDET 운영

1.3 팀 내/외부와의 협업

스프린트 안에서 개발과 협업

목 금 월 화 수 목 금 월 화 수

HTTP API 테스트

Sprint #N

Sprint #N+1 Sprint #N-1

1st week 2nd week

테스트 스크립트 작성 및 수행, 결함보고

사용자 스토리 파악

& AC 정의

클라이언트/서버 개발 및 단위 테스트

브랜치 Merge

및 확인

결함조치 확인 테스트

결함조치 및

재확인

짝 테스트 (같이, 매뉴얼)

개발

SDET

D-3 개발완료

대상 정의

SP#N-1 GUI 테스트 스크립트

리팩토링

SP#N+1 AC 검토/보완

결과 확인, 코드 리뷰, 결함 보고

외부 공유용 실행 바이너리

내부 공유용 실행 바이너리

1.3 팀 내/외부와의 협업

짝 테스트

- 정해진 시간(30분)동안 개발자와 SDET이 같이 앉아서 테스트를 수행

- 같이 테스트를 진행하면서 개발자는 테스트를, SDET는 제품을 상세 습득

- 짝 테스트 후 SDET은 더 상세 테스트를, 개발자는 바로 결함 수정

1.3 팀 내/외부와의 협업

실제 구현된 제품을 확인하고 최초 정의한 내용과 검증 수행

요건이 명확하지 않은 경우 팀 내부, 외부 이해관계자와 확인

분석자 개발자

SDET

저는 이거 어떻게 만들어 달라는 건지 잘 모르겠어요…

UX

사업부

어? 내가 얘기하는건 그게 아닌데…

제가 알기로는 이렇게 하는게 맞아요.

아~ 저희가 의도한 건… 그게 아니라

1.4 통합 워크플로우 테스트 정의

개발 중간부터 최종 통합워크플로우 테스트 정의 및 공유

더 많은 이해관계자와 공유하기 위해 워크플로우를 도식화

1.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 테스트

2. 테스트 레벨별 접근

CCS 서버 내부 테스트 (Controller 테스트 등)

서버단 HTTP 테스트

클라이언트 GUI 테스트

. 대상 : 로직을 담은 일반 자바 클래스에 대한 Junit 테스트 . 주수행자 : 개발자 . 관리여부 : 개발자 판단으로 필요에 따라 (테스트 커버리지 참고)

. 대상 : 스프링프레임워크 상의 Component 대상

. 주수행자 : 개발자

. 검토자 : SDET

. 관리여부 : 대상 도출 후 작성 여부 확인 (테스트 커버리지 참고)

. 대상 : CCS, VMS, GIS 등 변경될 수 있는 서버에 대한 HTTP 요청 테스트 . 주수행자 : SDET . 관리여부 : 대상 도출 후 별도 계획에 따라 수행

. 대상 : CCS 클라이언트 (VMS, GIS 클라이언트) GUI 대상 . 주수행자 : SDET . 관리여부 : 사용자스토리별 테스트 정의

테스트 자동화 피라미드 기반의 접근 전략

각 테스트 대상에 대한 테스트 수행 방안 정의, 샘플 코드 제공 및 수행

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 …

2.1 서버 내부 테스트

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

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~~

과거 현재 미래

2.2 HTTP API 테스트의 구성

개발 프로젝트와 별도 프로젝트로 테스트 프로젝트 구성

상수로 정해진 IP 정보(예:개발 WAS)로 HTTP Reqeust 요청 후 결과 검증

2.3 클라이언트 GUI 테스트 자동화

Challenge & Risk

. 개발과 동시에 GUI 테스트 자동화를 구축(스크립팅)할 수 있을까?

. 변경이 심한 GUI에 대해 변경을 잘 반영할 수 있을까?

. C#, WPF UI에 대한 GUI 테스트 자동화는 어떻게 구현할 수 있을까?

- 발췌: 테스트 자동화 회고 -

(1) 개발과 동시에 해보니 UI가 결정되지 않거나, 이후 변경되기로 결정되는(?)

상황이 비일비재

(2) WPF기반에 커스터 UI 콤포넌트를 많이 쓰다보니 변경이 되면 처음부터 재작업해야

하는 경우가 대부분

(3) CodedUI라는 툴을 발굴하여 해결, Best Practice는 더 해 봐야…

(4) GUI 테스트 자동화의 우선순위가 제일 낮고, 개발 완료가 더디다 보니 제일 뒷전이…

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/TestStack/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 연계가 취약

Client UI

2.3 클라이언트 GUI 테스트 자동화

GUI 레벨에서 동작을 Record하고,

스크립트로 생성한 후 Play하는 방식의 툴

기록 <> 일시정지

기록된 단계 표시

콘트롤 조사 및 어설션 추가

코드생성

COMMON폴더 : 공통 파일

Tests 폴더 : 테스트 코드

UIMaps 폴더 : 화면별 UIMap 코드

샘플 테스트 프로젝트

1)Record

4) Play

2)Generate

3)Modulize&Refactoring Assertion

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) 목록 조회

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 테스트

2. Jenkins 기반의 개발 빌드/테스트 자동화 구축

서버 테스트 서버 코드 인스펙션

Jenkins 잡 구성

API 테스트 결과

API 스펙 생성

3. 정리

API 테스트 결함

API 테스트 결함

API 테스트 결함

클라이어트 빌드 실패

GUI 테스트 결함

클라이어트 빌드 실패

API 테스트 결함

API 테스트 결함

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이 사전 설명 없이 퇴짜를 놓아 서운했다(사전 교육 때 설명 안 해 줬음)

감사합니다