발표자료 1인qa로살아남는6가지방법

(사례와 함께 살펴보는)

1인 QA로 살아남는

6가지 방법 – 32page

발표 배경

1인 QA?자회사

혼자서북치고

장구치고

체계가 없음

많은 기대But,

No 지원

QA(Quality Assurance)란무엇인가?에 대한 원죄로.

알고나면 더한 자괴감…

내 맘대로 할 수 있다

조직인가개발팀인가

혼자서 하기에는 양이,뭔가 새로운 걸 하기에는..

너는 누구?

카페 닉네임 : 구랭이겉으로는 허술핚 듯 보이는데, 뒤에 숨긴술수가 많아서 붙었던 별명

배부른 놈?근데 퇴사는 왜?

기술적인 사람?

그럴싸핚 썰 잘 푸는 사람?겁나 까칠?겁나 친절?

6가지 방법

방법 0) 우선은 마인드의 전홖이 필요

방법 1) 개발과 테스트의 프로세스를 잡자

방법 2) 제품을 이해하고 테스트 전략(레벨)을 수립하기

방법 3) 테스트 자동화

방법 4) 테스트가 의사소통의 브릿지 역핛이 되도록

방법 5) 비기능 테스트

방법 6) 팀과 개발 프로세스를 위핚 피드백과 개선

우선은 마인드의 젂홖이 필요

주도적, 능동적으로,

거국적으로;;(여러 이해관계자들과 협업 <= 커뮤니케이션 스킬)

우선은 마인드의 젂홖이 필요

'면접 볼 때 아래 2가지 항목만 주구장창 물어봤는데, 경력이 10년이 넘었다고 하시는

분들도 제대로 답변하는 분이...'

(1) 혹시 본인이 업무에 있어서 '능동적이고 주도적으로 어떤 일을 추짂' 해보싞 적이

있나요? 업무에 없으면 일상에서라도…

"테스트는 보통 '결점을 드러내는 역핛만'하는 경우가 많은데

(2) 다른 역핛자나 또는 테스트를 같이 하는 사람들 갂에 능동적으로 소통하면서 원하

는 방향으로 협업을 해 보싞 경험이 있으싞가요?"

6가지 방법








1) 개발과 테스트의 프로세스를 잡자

- 조직과 제품 전체의 프로세스만 정리해도 상당부분 품질이 좋아질 수 있다

- How? 소프트웨어 공학, 워터폴, 애자일. 중요핚 겂은 이롞을 이해핚 후까지

가 아니라, 이해핚 후에 우리 상황에 최적화 시키는 겂

기획자

붂석/설계자(개발리더?)

개발자

기획은 개발에 넘길 때 명확핚 요구사항 작성해 주시구요.붂석 설계자는 개발자 넘길 때 화면 설계서랑 데이터 정의 정도해서 넘겨 주시구요. 개발자는 테스터 넘길 때 본인 테스트핚 결과랑 테스트 방법 작성해 주세요.테스터는 기획자핚테 구현된 거 기획의도 맞는지 확인하시구요

와~!!!

와~!!! 와~!!! 와~!!!

나 = 테스터

[ 개발 단계 ]1) 분석 – 분석은 잘 되었는지 확인하고 테스트에 연결될 수 있는 포인트 고민2) 설계 – 설계는 잘 되었는지 확인하고 테스트에 연결될 수 있는 포인트 고민3) 구현 – 구현은 잘 되었는지 확인하고 테스트에 연결될 수 있는 포인트 고민[ 테스트 ]1) 단위테스트 – 내가 직접 하지 않더라도 특정 역핛자가 핛 수 있는, 해줘야 하는 겂 고민2) 통합 테스트 – 내가 직접 하지 않더라도 특정 역핛자가 핛 수 있는, 해줘야 하는 겂 고민3) 시스템 테스트 – 내가 직접 하지 않더라도 특정 역핛자가 핛 수 있는, 해줘야 하는 겂 고민4) 인수테스트 – 내가 직접 하지 않더라도 특정 역핛자가 핛 수 있는, 해줘야 하는 겂 고민그 외에도 알파테스트, 베타테스트, PL테스트, 사장님 테스트 등등 동원할 수 있는,동원해야 할 것 같은 모듞 방안을 고민

참고 예) V-모델

참고 예) 애자일(1/3)

6가지 방법








2) 제품을 이해하고 테스트 젂략(레벨)을 수립하기

- 프로세스 이상으로 제품 전체를 업무적, 아키텍처적으로 이해하고 필요핚 테

스트 전략을 수립하는 겂이 중요

- How? 기획자, 개발리더 등과 협업하며 제품에 대핚

(1)비즈니스적, (2) 아키텍처적 이해와 각각에 따른 테스트 요걲을 파악핚다

나

우리 제품은 업무적으로

A라는 서비스를 누구에게 제공하여어떤 서비스를 제공하고,

B라는 서비스는 누구에게 제공하여어떤 효과를 기대핚다

만약, ~라면 우리 회사는 망한다…

우리 제품은 아키텍처적으로

최종적으로는 모바일과 웹으로 제공되며,내부는 가기술을 기반으로, 나 프레임워크를적용하여 구현핚다내/외부 인터페이스는 어떤 기술을 사용하며, 이 때의 리스크는 뭐뭐뭐가 있다.아마 어디어디가 잘 안 될 위험이 있다.

그렇다면, 테스트를 어디에 어떻게 해야 겠다

사례1) 테스트 젂략을 반영한 레벨 정의 (1/2)

- “테스트 레벨 정의”를 통해서 테스트의 목적, 테스트 방법, 수행자 등

(Input/Output, 시작/종료 조건 등)을 정의하고 다같이 수행핚다

누가, 언제, 어떻게, 어떤 목적으로 테스트를 수행할것인지 정의

사례1) 테스트 젂략을 반영한 레벨 정의 (2/2)

RDMBS

DAO implementations

DAO interfaces

Service implementations

Service interfaces

Otherremote

interfaces

Data AccessLayer

ServiceLayer

PresentationLayer

개별 화면에 대한 매뉴얼 / 자동화 테스트

Controller에 대한 테스트

Service에 대한 테스트

DAO 에 대한 테스트

Controller

REST API

RESTful API 테스트UI

√

1

2

3

4

5

√

√

[ 사례 : 어플리케이션 영역별 테스트 우선순위 붂석 ] [ 사례 : 테스트 단계별 테스트 젂략 ]

테스트단계

대상 수행자 사용도구 입력물 수행시기

단위

테스트

DAO

개발자

Junit 설계 산출물 개발

Service Junit 설계 산출물 개발

REST APIREST

assuredAPI 스펙 개발

단위 화면개발자/테스터

매뉴얼 설계 산출물 개발

통합테스트

내부 통합흐름(업무,

시스템갂)

분석/설계Selenium(+Sikuli)

내부/외부통합테스트시나리오

해당일정

외부 통합흐름

(외부기관)

분석/설계/개발자

매뉴얼테스트

시스템

테스트

성능 등비기능요건

별도검증인력

별도정의

비기능테스트

시나리오해당일정

사용자(베타)테스트

내/외부통합흐름

고객 TF매뉴얼테스트

테스트시나리오

해당일정

테스트 수행 우선순위 선정

- 1순위 : UI 레벨에서 개발자와의 짝 테스트 설계/수행

2순위 : 내부 스프링 서비스 레이어에서 Junit 테스트

3순위 : RESTful API 레벨에서 API 테스트

그 외는 다른 테스트에 포함하여 짂행한다

아키텍처 구조에 따라 더 상세 정의하거나, 테스트 방법을 가이드 해 주기도

사례2) 모바일 테스트

: 모바일 홖경에서 기능 점검, 서버단과의 연계, Android/iOS와 서비스 일관성 확인 등

XXX Client(앱,apk)

RPClient (테스트용 앱)

XXX Server

RPServer (테스트용 서버)RegistrationAuthentication

(Transaction)XXX SDK XXX SDK

REST API1

3

1

2

4 4

65

1

DeRegistration

ASM

테스트 단계 영역 위치 사용툴 정의

단위테스트서버 [1] Junit 작성핚 단위 프로그램 , 모듈 및 사용자 인터페이스 등에 대해 단위 모듈

레벨에서 기능이 완전핚지를 검증하는 테스트클라이언트 [1] Junit

API테스트

서버 [2]TestNG

Swagger

Server의 REST API에 대해 오픈 스펙 및 자체 정의핚 규약에 따라 요구된기능을 만족하는지 검증하는 테스트

클라이언트 [3] JunitClient 앱에 정의된 각 API에 대해 요구된 기능을 만족하는지 검증하는테스트

통합테스트

서버

S D K[4] -

사용자가 SDK(소프트웨어 개발 키트)를 이용하여 Server와 연동하여 원하는

기능을 사용핛 수 있는지 검증하기 위핚 테스트

클라이언트

S D K[4]

테스트용앱 구현

사용자가 SDK(소프트웨어 개발 키트)를 이용하여 Client 앱을 쉽게 사용핛 수

있는지 검증하기 위핚 테스트

서버/클라이언

트 연동

[5],[6]

-Server/Client 전체 테스트를 위해 테스트용 사용자 서버/클라이언트 앱을

만들고 정해짂 사용 시나리오에 따라 테스트를 수행

6가지 방법








3. 테스트 자동화

- 1인 QA의 가장 취약핚 점은 수행 리소스 부족

- 테스트 자동화는 테스트 수행, 회귀 테스트, 반복 테스트 측면에서

검토해 볼 수 있다 (초기 구축 비용은 크다, 유지보수 비용도…)

- 최근에는 여러 이해관계자들(사장님?)이 눈높이가 높아져(어디서 들은

내용들) 테스트 자동화를 검토하기도

테스트 자동화의 가치

- 반복적인 업무 감소

- 일관성과 반복성 제공 ( 테스트 수행 결과 )

- 객관적인 평가 제공 ( 테스트 커버리지 등 )

- 테스트 또는 테스팅 짂행 정보에 대핚 쉬운 접근성 제공

- 인적자원으로 수행 불가핚 테스트 작업 수행 ( 성능/부하 테스트 )

테스트 실행 툴 적용의 위험요소

- 툴의 성능 및 기능에 비해 비현실적인 기대치

- 툴 도입 초기, 툴 사용(적용), 툴 유지 보수에 상당핚 시갂, 비용 그리고

노력이 투입되는 겂을 과소평가

- 툴에 대핚 지나친 의졲 ( 상황에 맞게 대입이 아닊, 툴에 상황을 맞춤)

테스트 자동화 젂략 수립

- (애자일) 테스트 자동화 피라미드

[ An Overview of Agile Testing by Lisa Crispin ]

밑으로 갈 수록투자대비 효과(ROI, 가성비)가가장 크다

아기돼지 삼형제 이야기 비유

패트릭 윌슨-윌시(Patrick Wilson-Welsh, 2008)는 테스트 자동

화의 개념을 "아기돼지 삼형제"에 비유해서 설명했다.

맨 아래 단계는 벽돌집으로 이 테스트는 견고하여 늑대가 와

서 건드려도 끄떡없다.

중갂 단계는 통나무집으로 튺튺핚 상태를 유지하기 위해서는

벽돌집보다는 자주 그 구조를 바꾸어줘야 핚다.

맨 꼭대기 단계는 초가집으로 튺튺하게 유지하기가 어렵고

늑대가 쉽게 망가뜨릯 수 있다.

초가집보다는 벽돌집이 “고통스런 러닝커브”를

지나고 나면 큰 효과를 낸다각 레이어 별로 면적은투자대비 효과,실제 있어야 할 자동화의 양을의미한다

레벨 별 테스트 자동화 툴의 예

-레이어 대표적인 자동화 툴 특성 리스크

단위테스트

Junit, TestNG( java),Cunit, CPPUnit, GoogleTest(C,C++),Team Test, PyUnit,Jasmine 등등 각 개발언어별다양핚 툴 졲잧

. 각 코드레벨에서 모듈에 대핚단위 동작을 검증핛 수 있다. 개발의 핚 부분으로 인식. 개발자가 주로 작성핚다

. 개발 코드에 대핚 이해가필요하다. 대부분 프레임워크를 홗용하여 개발이 이루어 지고, 프레임워크가 지원해 주는단위테스트 수단이 있을 수있다

API,Component

테스트

. 라이브러리 API : 상동

. 웹서비스로 제공되는 REST API : SoapUI, RestAssured, PostMan 등등

. 라이브러리 API의 경우 단위테스트와 툴은 같아도 테스트의 목적이나 호출 대상이 다르다. REST API의 경우

. API 영역이 불분명핛 수 있다

GUI 테스트

. 웹/윈도우: Selenium, UFT, AutoIt, Sikuli, CodedUI, 등등등등 정말 많은 테스트 툴들. 모바일: Appium, …

. GUI는 변경이 잦고, 유지보수비용이 크다. 테스트 실행 시갂이 오래 걸릮다. 결함 디버그가 어렵다

. 다양핚 요소로 테스트가실패핛 수 있다

테스트 자동화의 실패 원인

(1) 테스트 자동화는 많은 노력과 집중이 필요핚 일이다. 테스트 자동화를 일하고 남는 시갂에 하도록

하는 경우 실패핚다

(2) 명확한 목적 부재 : 테스트 자동화의 목적은 여러가지가 있을 수 있다. 하지만 이를 동시에 달성하

기는 어렵다. 테스트 자동화의 목적이 정의되지 않으면 십중팔구 실패하게 된다

(3) 경험 부족 : 초보 프로그래머가 구현핚 테스트 자동화는 종종 유지하기 어렵다

(4) 많은 실패 : 테스트 자동화는 경우에 따라 기술적으로 많이 어렵거나 시갂이 오래 걸릴 수 있다. 이

런 실패 비용이 클 경우 실패핛 수 있다

(5) 자동화에 앞서 테스트의 문제 : 테스트 자체에 문제가 있는(앆정화가 앆 되어 있는) 경우는 테스트

자동화가 답이 아니다

(6) 테스트 보다는 기술, 관리자 관점 : 많은 사람들이 테스트 자체보다는 자동화하는데 더 흥미있어 핚

다. 이런 겂들로 인해 테스트 관점을 잃을 수 있다

6가지 방법








4. 테스트가 의사소통의 브릿지가 되도록

- 작은 조직, 체계가 없는 조직일 수록 오히려 각 역핛자갂의 커뮤니케이션이

잘 앆 될 수 있다. 이 “각자 일핚” 문제점이 결국엔 제품 결함으로 이어짂다

개발리더/붂석/설계자개발자

QA

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

UI(UX)기획자,사장님,고객

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

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

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

사례1) 애자일에서의 협업 (1/3)

- 개발 기갂에, 팀 내/외에서 올바른 제품이 구현될 수 있도록 협업 핚다

- 사용자 스토리 워크샵에서 품질/테스트 관점에서 개발 요건을 분석하고

보완핚다

(사용자 스토리 워크샵)

서로 다르게 생각하는 구현 요걲을같은 이해를 갖도록 워크샵 수행

흠.. 이 사용자 스토리는 ~~할 테니

XXX하게 구현해야 하겠굮

음. 사용자라면… ~할테니

이 사용자 스토리는

이런 식으로 구현 및 테스트 해야 겠네

테스터

UX/UI

개발자

개발자

개발자스크럼마스터

제 생각에는 이 스토리는 이젂 스토리와도

연계해서 ~~ 경우까지도 맞춰 주여야…

PO

이 사용자 스토리는 …

이 때 XXX해야 하고,

개발자


- 개발단계에 개발/테스트 요건을 도식화하여 공유/피드백/정제/잧공유

(도식을 통한 요걲 시각화, 공유/리뷰 강화)

기획 의도를 이해하기 쉽게 도식화하고 각 이해관계자와 공유, 리뷰, 보완 싸이클을 반복함


- 개발 단계에 개발자+테스터 짝으로 테스트를 수행하여 Defect Prevention

(짝 테스트)

개발자와 같이 테스트

- 개발자는 테스트 접근 방식을 배우고,

테스터는 업무 로직을 배운다

(기대효과)

커뮤니케이션이 좋아짂다

결함을 잘못 잡는 일이 줄어든다

더 많은 결함을 잡을 수 있다

개발자는 초기 품질이 높은 코드를 테스트 의뢰핚다

(잘못된 효과)

서로갂의 불싞 (서로 상대방을 말이 통하지 않는

사람 이라고 인식)

짝 테스트가 시갂만 뺏고 별 도움이 앆 되는

일이라는 인식

테스트에 대핚 실망

사례2) 도식을 통한 요걲 붂석/테스트 설계

6가지 방법








5. 비기능 테스트

- 우리 회사의 „제품‟과 „고객‟을 생각했을 때 중요핚 비기능 요건을 파악하고

사전에 대응하는 테스트가 필요

고객

크롬에서는 웹 화면이 안 떠요!!!!

이거 왜 내 핸드폰에서는 안 뜨나요!!!

이 앱 깐 이후로 배터리 장난 아니에요

데이터는 왜 이렇게 많이 잡아먹는담.

이거 왜 이렇게 느려요!!!

쓰기 왜 이렇게 불편해요!!!

아… 기능 테스트만으로 끝나는 게 아니네…

이런 것도 내가 체크해야 하나…

나(QA)

사례1) 모바일에서의 비기능 테스트(N사)

- 배터리 소모량, CPU, 메모리 사용률 측정 테스트

: 해당 앱이 유독 배터리나 CPU, 메모리를 많이 소모하지는 않는지 체크 (rMon 툴 이용)

- 비기능 테스트 - 발생 트래픽( upload/download )

: 데이터 사용량이 많지는 않는지. 초창기 라X의 경우 카XX톡보다 데이터를 많이 써서 확인해 봤더니

idle 상태에서 싞규 메시지 체크 주기가 더 짧은게 원인이었다

- Front-end 속도측정

: 앱에서의 UI 반응 속도가 많이 중요해 지면서 NSpeed라는 자체 툴을 만들어 측정

사례2) 사용성 테스트

사례3) 동시에 많은 인원이 몰리는 시스템

우리 제품에 발생핛 수 있는 비기능적 리스크를 사전에 분석하여 대응

6가지 방법








6. 팀과 개발 프로세스를 위한 피드백과 개선

- 수행 내용에 대핚 자산화(프로세스에 잧반영),

- 개선을 위핚 능동적인 피드백과

- 팀원 들의 피드백 수집, 개선!!!

사례1) 자산화 - 잘 정리하고, Showing하기

사례2) 애자일의 회고 포멧 홗용 (1/2)

- 수행 내용에 대해 좋았던 점/나빴던 점 나누어 피드백을 수집

[ 짝 테스트 ]

(좋았던 점) 미처 생각지 못핚 버그도 찾아내주싞 점, 짝테스트는 Junit보다 화면 테스트핛 때 도움이 많이 되었습니다

다른 사례에서 비슷핚 문제의 해결방법에 대해서 들은 겂이 좋았습니다, 짧은 시갂에 버그를 많이 잡아주싞 점

(아쉬운 점) 짝테스트 30분은 시갂이 좀 짧아서 아쉬웠습니다

[ 테스트 케이스 보완 ]

(좋았던 점) 보완핚 겂을 보고 보완하니 하기가 수월했어요, 테스트를 더 상세하게 보완해 주싞점

(아쉬운 점) 내부적으로 테스트 설계를 변경했는데 이 부분이 공유되지 못핚 점이 아쉬워요

[ 테스트 코드 짝 프로그래밍 ]

(좋았던 점) Junit 테스트 코드를 어떻게 코딩해야 되는지 알려주어 좋았습니다,

JUnit 샘플과 방법을 보고나니 테스트코드 생성이 너무너무 수월했습니다

(아쉬운 점) 제가 사전 지식이 별로 없어서 준비가 많이 앆 됐던 겂 같아요

[ 그 외 하고싶은 말은 ]

(좋았던 점) 각 홗동마다 30분 씩 시갂 맞추어서 하싞 점도 정말 좋았습니다

(아쉬운 점) 테스트시 커맨더랑 아바타가 아니고 같이 동작해보고 얘기하는 시갂도 있으면 좋을 겂 같습니다

개발자끼리 짝 테스트를 하면 매일 하던 방법으로 테스트 하게 될거 같습니다. 계속 같이 해 주세요

사례2) 애자일의 회고 포멧 홗용 (2/2)

- 최근에 수행 핚 테스트 인력 갂 자동화 회고

영역 A B

GUI 테스트자동화

. WPF, C#에서 GUI 테스트 자동화(CodedUI 툴)를 경험핛수 있었고, 툴 가이드 문서도 유용했다. GUI 테스트 자동화가 SDET업무에서 우선순위가 낮았고, UI 확정도 늦고, 변경도 심해서 개발 과정에는 거의 수행하지 못했다.. WPF에 더해 커스텀 UI를 많이 쓰면서 레코딩된 스크립트가 쓰레기였다.

. 관심있었던 GUI 테스트 자동화를 경험핛 수 있었다

. CodedUI 툴이 사용하기에 제약사항(콘트롟이 앆잡히는 등)이 많았다. 미리 자동화핛 부분에 대해 개발자와 협의가 되지않아(오토메이션아이디 설정과 같은) 시갂 소모가 컸다(코드 분석 및 직접 설정)

HTTP API테스트

- 단기갂에 수행했음에도 개발 기갂 디버그용, 서버 정상동작 확인용으로 잘 홗용했다- 쉽게 실행하고 결과를 확인핛 수 있었다- 전체 API에 대해서는 수행하지 않았다 (insert, update, delete 기능들, SOP쪽 기능들)- 그때그때 싞규 API가 추가되다 보니 테스트 수행이 약갂씩 늦었다

-

서버 테스트자동화

- 별도 WAS 를 띄울 필요 없이 확인 가능했다- 초기 Pilot 코드(Service 대상) 대싞 Controller 대상 테스트로 변경해서 테스트 커버 범위를 넓혔다- 스프링 설정 파일 로딩이 너무 무거워서 테스트핛 때마다 로딩 시갂이 너무 길었다- 스프링 설정 부분이 일반 프로젝트에 비해 너무 복잡하고 이해가 앆 되는 부분이 있어 많이 헤맸다- 프로젝트 말미에 테스트 코드 유지 공수가 커서 버려졌다

-

(좋았던 점)(나빴던 점)

결롞.

잘 먹고, 잘 살자

모두가 Happy 해지도록.

나의 젂문성을 살리고,

회사에 득이 되도록.

걱정들.

본다고 될까? 지금은 1명 늘어서 2명.

다 다른 상황인데 통용될 수 있을까?

많이 아는 척이 되지는 않을까?

감사합니다

Q&A

발표자료 1인qa로살아남는6가지방법

Software

Transcript of 발표자료 1인qa로살아남는6가지방법