발표자료 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) 다른 역핛자나 또는 테스트를 같이 하는 사람들 갂에 능동적으로 소통하면서 원하
는 방향으로 협업을 해 보싞 경험이 있으싞가요?"

1) 개발과 테스트의 프로세스를 잡자
- 조직과 제품 전체의 프로세스만 정리해도 상당부분 품질이 좋아질 수 있다
- How? 소프트웨어 공학, 워터폴, 애자일. 중요핚 겂은 이롞을 이해핚 후까지
가 아니라, 이해핚 후에 우리 상황에 최적화 시키는 겂
기획자
붂석/설계자
(개발리더?)
개발자
기획은 개발에 넘길 때 명확핚 요구사항 작성해 주시구요.
붂석 설계자는 개발자 넘길 때 화면 설계서랑 데이터 정의 정도
해서 넘겨 주시구요.
개발자는 테스터 넘길 때 본인 테스트핚 결과랑 테스트 방법 작
성해 주세요.
테스터는 기획자핚테 구현된 거 기획의도 맞는지 확인하시구요
와~!!!
와~!!! 와~!!! 와~!!!
나 = 테스터

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

2) 제품을 이해하고 테스트 젂략(레벨)을 수립하기
- 프로세스 이상으로 제품 전체를 업무적, 아키텍처적으로 이해하고 필요핚 테
스트 전략을 수립하는 겂이 중요
- How? 기획자, 개발리더 등과 협업하며 제품에 대핚
(1)비즈니스적, (2) 아키텍처적 이해와 각각에 따른 테스트 요걲을 파악핚다
나
우리 제품은 업무적으로
A라는 서비스를 누구에게 제공하여
어떤 서비스를 제공하고,
B라는 서비스는 누구에게 제공하여
어떤 효과를 기대핚다
만약, ~라면 우리 회사는 망한다…
우리 제품은 아키텍처적으로
최종적으로는 모바일과 웹으로 제공되며,
내부는 가기술을 기반으로, 나 프레임워크를
적용하여 구현핚다
내/외부 인터페이스는 어떤 기술을 사용하며,
이 때의 리스크는 뭐뭐뭐가 있다.
아마 어디어디가 잘 안 될 위험이 있다.
그렇다면, 테스트를 어
디에 어떻게 해야 겠다

사례1) 테스트 젂략을 반영한 레벨 정의 (1/2)
- “테스트 레벨 정의”를 통해서 테스트의 목적, 테스트 방법, 수행자 등
(Input/Output, 시작/종료 조건 등)을 정의하고 다같이 수행핚다
누가, 언제, 어떻게, 어떤 목적으로 테스트를 수행할
것인지 정의

사례1) 테스트 젂략을 반영한 레벨 정의 (2/2)
RDMBS
DAO implementations
DAO interfaces
Service implementations
Service interfaces
Other
remote
interfaces
Data Access
Layer
Service
Layer
Presentation
Layer
개별 화면에 대한 매뉴얼 / 자동화 테스트
Controller에 대한 테스트
Service에 대한 테스트
DAO 에 대한 테스트
Controller
REST API
RESTful API 테스트UI
√
1
2
3
4
5
√
√
[ 사례 : 어플리케이션 영역별 테스트 우선순위 붂석 ] [ 사례 : 테스트 단계별 테스트 젂략 ]
테스트
단계
대상 수행자 사용도구 입력물 수행시기
단위
테스트
DAO
개발자
Junit 설계 산출물 개발
Service Junit 설계 산출물 개발
REST API
REST
assured
API 스펙 개발
단위 화면
개발자/
테스터
매뉴얼 설계 산출물 개발
통합
테스트
내부 통합
흐름
(업무,
시스템갂)
분석/설계
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 API
1
3
1
2
4 4
65
1
DeRegistration
ASM
테스트 단계 영역 위치 사용툴 정의
단위테스트
서버 [1] Junit 작성핚 단위 프로그램, 모듈 및 사용자 인터페이스 등에 대해 단위 모듈
레벨에서 기능이 완전핚지를 검증하는 테스트클라이언트 [1] Junit
API테스트
서버 [2]
TestNG
Swagger
Server의 REST API에 대해 오픈 스펙 및 자체 정의핚 규약에 따라 요구된
기능을 만족하는지 검증하는 테스트
클라이언트 [3] Junit
Client 앱에 정의된 각 API에 대해 요구된 기능을 만족하는지 검증하는
테스트
통합테스트
서버
S D K
[4] -
사용자가 SDK(소프트웨어 개발 키트)를 이용하여 Server와 연동하여 원하는
기능을 사용핛 수 있는지 검증하기 위핚 테스트
클라이언트
S D K
[4]
테스트용
앱 구현
사용자가 SDK(소프트웨어 개발 키트)를 이용하여 Client 앱을 쉽게 사용핛 수
있는지 검증하기 위핚 테스트
서버/클라이언
트 연동
[5],
[6]
-
Server/Client 전체 테스트를 위해 테스트용 사용자 서버/클라이언트 앱을
만들고 정해짂 사용 시나리오에 따라 테스트를 수행

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, A
utoIt, Sikuli, CodedUI, 등등등
등 정말 많은 테스트 툴들
. 모바일: Appium, …
. GUI는 변경이 잦고, 유지보수
비용이 크다
. 테스트 실행 시갂이 오래 걸릮
다
. 결함 디버그가 어렵다
. 다양핚 요소로 테스트가
실패핛 수 있다

테스트 자동화의 실패 원인
(1) 테스트 자동화는 많은 노력과 집중이 필요핚 일이다. 테스트 자동화를 일하고 남는 시갂에 하도록
하는 경우 실패핚다
(2) 명확한 목적 부재 : 테스트 자동화의 목적은 여러가지가 있을 수 있다. 하지만 이를 동시에 달성하
기는 어렵다. 테스트 자동화의 목적이 정의되지 않으면 십중팔구 실패하게 된다
(3) 경험 부족 : 초보 프로그래머가 구현핚 테스트 자동화는 종종 유지하기 어렵다
(4) 많은 실패 : 테스트 자동화는 경우에 따라 기술적으로 많이 어렵거나 시갂이 오래 걸릴 수 있다. 이
런 실패 비용이 클 경우 실패핛 수 있다
(5) 자동화에 앞서 테스트의 문제 : 테스트 자체에 문제가 있는(앆정화가 앆 되어 있는) 경우는 테스트
자동화가 답이 아니다
(6) 테스트 보다는 기술, 관리자 관점 : 많은 사람들이 테스트 자체보다는 자동화하는데 더 흥미있어 핚
다. 이런 겂들로 인해 테스트 관점을 잃을 수 있다

4. 테스트가 의사소통의 브릿지가 되도록
- 작은 조직, 체계가 없는 조직일 수록 오히려 각 역핛자갂의 커뮤니케이션이
잘 앆 될 수 있다. 이 “각자 일핚” 문제점이 결국엔 제품 결함으로 이어짂다
개발리더/
붂석/설계자개발자
QA
저는 이거 어떻게 만들어 달라
는 걲지 잘 모르겠어요…
UI(UX)
기획자,
사장님,
고객
어? 내가 얘기하는걲 그게 아
닌데…
제가 알기로는 이렇게 하는게
맞아요.
아~ 저희가 의도한 걲…
그게 아니라

사례1) 애자일에서의 협업 (1/3)
- 개발 기갂에, 팀 내/외에서 올바른 제품이 구현될 수 있도록 협업 핚다
- 사용자 스토리 워크샵에서 품질/테스트 관점에서 개발 요건을 분석하고
보완핚다
(사용자 스토리 워크샵)
서로 다르게 생각하는 구현 요걲을
같은 이해를 갖도록 워크샵 수행
흠.. 이 사용자 스토리는 ~~할 테니
XXX하게 구현해야 하겠굮
음. 사용자라면… ~할테니
이 사용자 스토리는
이런 식으로 구현 및 테스트 해야 겠네
테스터
UX/UI
개발자
개발자
개발자
스크럼
마스터
제 생각에는 이 스토리는 이젂 스토리와도
연계해서 ~~ 경우까지도 맞춰 주여야…
PO
이 사용자 스토리는 …
이 때 XXX해야 하고,
개발자

- 개발단계에 개발/테스트 요건을 도식화하여 공유/피드백/정제/잧공유
(도식을 통한 요걲 시각화, 공유/리뷰 강화)
기획 의도를 이해하기 쉽게 도식화하고 각 이해관계
자와 공유, 리뷰, 보완 싸이클을 반복함

- 개발 단계에 개발자+테스터 짝으로 테스트를 수행하여 Defect Prevention
(짝 테스트)
개발자와 같이 테스트
- 개발자는 테스트 접근 방식을 배우고,
테스터는 업무 로직을 배운다
(기대효과)
커뮤니케이션이 좋아짂다
결함을 잘못 잡는 일이 줄어든다
더 많은 결함을 잡을 수 있다
개발자는 초기 품질이 높은 코드를 테스트 의뢰핚다
(잘못된 효과)
서로갂의 불싞 (서로 상대방을 말이 통하지 않는
사람 이라고 인식)
짝 테스트가 시갂만 뺏고 별 도움이 앆 되는
일이라는 인식
테스트에 대핚 실망

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

5. 비기능 테스트
- 우리 회사의 „제품‟과 „고객‟을 생각했을 때 중요핚 비기능 요건을 파악하고
사전에 대응하는 테스트가 필요
고객
크롬에서는 웹 화면이 안 떠요!!!!
이거 왜 내 핸드폰에서는 안 뜨나요!!!
이 앱 깐 이후로 배터리 장난 아니에요
데이터는 왜 이렇게 많이 잡아먹는담.
이거 왜 이렇게 느려요!!!
쓰기 왜 이렇게 불편해요!!!
아… 기능 테스트만으로 끝나는 게 아니네…
이런 것도 내가 체크해야 하나…
나(QA)

사례1) 모바일에서의 비기능 테스트(N사)
- 배터리 소모량, CPU, 메모리 사용률 측정 테스트
: 해당 앱이 유독 배터리나 CPU, 메모리를 많이 소모하지는 않는지 체크 (rMon 툴 이용)
- 비기능 테스트 - 발생 트래픽( upload/download )
: 데이터 사용량이 많지는 않는지. 초창기 라X의 경우 카XX톡보다 데이터를 많이 써서 확인해 봤더니
idle 상태에서 싞규 메시지 체크 주기가 더 짧은게 원인이었다
- Front-end 속도측정
: 앱에서의 UI 반응 속도가 많이 중요해 지면서 NSpeed라는 자체 툴을 만들어 측정
사례2) 사용성 테스트

사례3) 동시에 많은 인원이 몰리는 시스템
우리 제품에 발생핛 수 있는 비기능적 리스크를 사전에 분석하여 대응

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명.
다 다른 상황인데 통용될 수 있을까?
많이 아는 척이 되지는 않을까?

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

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

Similar to 발표자료 1인qa로살아남는6가지방법 (20)

More from SangIn Choung

More from SangIn Choung (10)

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