Top Banner
테트 (: 협 름다) 2014.10 at Samsung SDS OpenIT by JungGun home: genycho.blog.me
38

애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

Feb 12, 2017

Download

Software

SangIn Choung
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

애자일에서의 테스트 사례(부제: 협업의 아름다움)

2014.10 at Samsung SDS OpenITby JungGunhome: genycho.blog.me

Page 2: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

애자일테스트사례

이번 세션에서는,No!!Only 테스트 자동화?TDD?완벽한 Whole Team 테스트?

Yes!!!협업의 힘국내 환경을 반영한 현실적 사례

Page 3: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

- 목차 -개요사례 간략 소개테스트 전문가로서의 활동협업 (3Amigos)테스트 자동화자산화정리

Page 4: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

애자일…기존 테스트의 또 하나의 위기또는 기회

2011년 GTAC(Google Test Automation Conf.) – Testing is dead Testing is dead Testing is dead Testing is dead : https://www.youtube.com/watch?v=X1jWe5rOu3g

Page 5: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

협업 – 서로 다른 사람들이 힘을 합치는 것

좋은 개발자 비교 항목 테스터

깊은 지식 개발 지식 얇고 넓은 지식, 잡다한

새로 나온 기술 서적, 프로그래머로 사는 법

좋아하는 책추리소설,제주도 정착하기

코딩, 신기술 웹서핑 회사에서여가 시간에는

테스트 블로그 웹서핑,취업 사이트

코딩 룸에서 나만의 코딩하기,새로 나온 기술, 기계

좋아하는 것사람 만나기,영화/드라마 뒷 얘기 맞추기남 흉보는거

and개발자 테스터

Page 6: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

• 닭닭닭닭(chiken)과과과과 돼지돼지돼지돼지(pig) 이야기이야기이야기이야기

"스크럼(Scrum)에서는 팀원과 비 팀원의 역할을 돼지와 닭 이라고 이름 붙였다. 팀원은 돼지(자존심 접었다!)고비 팀원(관리자, 지원, QA 등)은 닭이다. 이 용어는 농장의 동물이 모여서 식당을 연다는 우화에서 나왔다. 아침 메뉴로 베이컨과 계란 프라이를 내놓으려고 할 때, 닭은 단순히 계란을 하나 내며 참여하는 수준이지만, 돼지는 자기 살을 내어주는 헌신인 것이다. 오직‘돼지’만이 스크럼 스탠드 업 미팅에 참석하는 것이 허용된다."

- 애자일 프랙티스 226쪽에서 -

이이이이 우화는우화는우화는우화는 Scrum 및및및및 XP 등의등의등의등의 Agile 방법론에서방법론에서방법론에서방법론에서 중요하게중요하게중요하게중요하게 중요하게중요하게중요하게중요하게 생각하는생각하는생각하는생각하는 Team Work에에에에 관한관한관한관한 이야기다이야기다이야기다이야기다

외부외부외부외부 테스트테스트테스트테스트조직조직조직조직////인력이인력이인력이인력이

닭? 돼지가 될수 있을까?

외부외부외부외부 테스트테스트테스트테스트조직조직조직조직////인력이인력이인력이인력이

닭? 돼지가 될수 있을까?

Page 7: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

애자일에서 테스트 전담자는 필요할까? 정답은: 필요할 수도 있고, 필요 없을 수도 있다

테스트 전담자는 다음의 일을 할 것이다.

- 사용자 스토리 완료를 확인시켜 줄 수 있는 테스트 시나리오(케이스)를 작성할 것이다

- 고객과 개발자를 이어주는 가교 역할을 할 것이다(2인3각 경주)

- 변화에 유연하게 대응하도록 해주는 테스트 자동화를 고민할 것이다

- 위 일들이 다 끝나면 추가적으로 탐색적 테스팅을 수행할 것이다

- 테스트 자산을 축적할 것이다(빈발결함, 품질 추이, 교육자료 등)

이 일들을 할 누군가가 있으면 된다

개발자의 테스트를 대신 해주기 위해 테스트 전담자가 필요하다??

Page 8: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

테스트 리더, 엔지니어

테스터

슈퍼맨이 되란 말인가?

돈도, 인원도, 역량도…뭘 해야 할지도…

A프로젝트A프로젝트 B프로젝트B프로젝트 산발적 수명업무산발적 수명업무

S

S

하이브리드 애자일 테스트 수행 조직

- 적용대상 : 애자일 방식을 채용한 개발조직이 수행하는 다수의 중소규모 프로젝트

- 조직구성 : 테스트 인력 부족으로 테스트 인력만의 스크럼 팀을 구성하고 다수의 개발 스크럼팀과

병행으로 애자일 테스트를 수행

Page 9: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

A팀(개발 스크럼)

B팀(개발 스크럼)

테스트팀

(하이브리드) 테스트 스크럼팀 운용 방안

- 부족한 자원을 최대로 활용하기 위해 별도의 테스트 스프린트 운용

설계,개발스프린트

(N-1)

설계,개발스프린트

(N)

설계,개발스프린트(N+1)

테스트(N)

운영방안1Whole Team 테스터

운영방안1Whole Team 테스터

설계,개발스프린트

(N-1)

설계,개발스프린트

(N)

설계,개발스프린트(N+1)

테스트(N)

테스트스프린트

(N-1)

테스트스프린트

(N-1)

운영방안2같은 팀 다른 스프린트

운영방안2같은 팀 다른 스프린트

운영방안3다른 팀 다른 스프린트

운영방안3다른 팀 다른 스프린트

… …

이상적 현실적

운영간 이슈:테스트팀의 비용은누가 지불?

Page 10: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

스크럼 팀에서 테스트 Activity

테스트 설계짝 설계(개발/테스트)테스트 설계짝 설계(개발/테스트)

짝 테스트, 개발/테스트 코드 리뷰짝 테스트, 개발/테스트 코드 리뷰

일일 미팅 참여일일 미팅 참여

타 팀을 위한 자산화타 팀을 위한 자산화

테스트 결과,빈발결함 공유테스트 결과,빈발결함 공유

테스트 수행테스트 수행

테스트 전략, 계획 수립테스트 전략, 계획 수립

테스트 자동화 환경 구축테스트 자동화 환경 구축

테스트 기본교육테스트 기본교육

테스트 코드 작성 가이드테스트 코드 작성 가이드

Page 11: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

타 프로젝트 사례

타사 사례

해외 사례

전문 지식

밥 먹고 테스트만고민하는 사람

테스트 전문가로서의 역할

Page 12: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

프로젝트에 필요한(적합한) 테스트 전략 수립

- 고객 요구사항 전반에 따른 일반적인 테스트 계획 수립

- 타 업무, 타 시스템과의 통합 테스트, 비기능 요구사항에 대한 테스트 전략 수립

(사례)크로스 브라우저 지원, 다국어 등에 따른 별도 테스트 방안

- 프로젝트 초기부터 테스트 자동화, CI 전략 수립

고객 개발팀

테스트

경험 : 타 프로젝트 사례, 세미나

크로스 브라우저지원해 주기 바람

JSP 쓰니알아서 잘 될거임

어떤 브라우저? 어떤 버전?원하는 수준은?

자료 : 크로스 브라우저테스트 가이드

Page 13: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

테스트 기본 교육

- 샘플 기반의 테스트 코드 작성 가이드

- 전체 테스트 프로세스, 관리 툴 교육

[ 테스트 프로세스 및테스트 코드 작성 가이드 ]

Page 14: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

- 빈발 결함 교육 (유사 도메인 타 프로젝트 사례)

[ 빈발결함(화면, API 유형별) ]

Page 15: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

전문성 있는 테스트 결과 공유- 스프린트 종료 시 다음 스프린트를 위한 개선 점 도출 등

Page 16: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

3 amigos? Introducing the Three Amigos: Shared understanding by discussing together

개발은 그럼,

테스트는 그럼,구현해야 하는 건,

협업!! (세 친구들)

Page 17: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

사용자 스토리 워크샵에서는,

(1) 개발 요건(설계 산출물 등)에 대해 온/오프라인 검토

(2) 테스트 케이스 초안 도출 (마인드맵, BPMN 작성 등)

(3) 개발자, 고객 또는 Product Owner와 리뷰

(4) 리뷰 내용 논의(피드백)

(5) 테스트 케이스 상세 작성

이번 스프린트에 구현해야 하는 기능은…

버스 정류장 이름은 유일해야 하고,…

[ 오프라인 수행사례 : 스프린트 플래닝 ]

음.. 테이블 구성은 이렇게 하고,

체크하는 로직은 어디에 위치시켜야 겠다

테스트 케이스 후보!!!

“정류장 이름이 같은 경우”

같은 이름을 넣는 경우 넣는 순간

체크해야 하나요,

아니면 저장 버튼을 클릭하는 순간

체크해야 하나요?

Page 18: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

[ 온라인 사례 : 설계서 사전리뷰 -> 개발자와 짝설계 -> 고객과 온라인 리뷰 ]

. 수행 방법 : 화면 별로 a)개발자 설명, b) TE 질의, c) 기타 추가 케이스 도출 및

문서 정리를 각 5분씩 수행하여 총 15분 이내로 수행

. 수행 결과 :

1) 각 화면의 컬럼 영역 클릭시 정렬 기능이 적용되어야 하는 사항 공유

2) 파라미터 목록 화면을 제외한 다른 화면에서의 기본(디폴트) 정렬 조건 확인

(파라미터 상세조회의 내역(최근 등록순?), 카드 블랙 리스트의 항목 등)

3) 메시지/버튼명 등에 대한 통일, 다국어 지원 현재는 미적용 내용 공유

4) 스프린트 1에서 엑셀, 인쇄 기능 미구현 확인 필요\

5) 각 화면별 필수입력 필드 표시 미정의, 필수 입력(배포 그룹명 등) 에 대한 Trim

처리 확인 필요

6) [파라미터 조회] 조회 건을 클릭시 기본이 "상세조회 화면" 이나

상태가 '임시저장'인 경우 해당 임시저장 화면으로 이동해야 하는 요건 확인 필요

7) [파라미터 생성] 첨부 파일에 대한 최대 크기, 파일 종류가 정해지 있지 않은지

확인 필요(파일은 1개로 확인)

8) [파라미터 생성] Activate Date, Deactivate Date에 대해 적용 시작일이 오늘,

현재 시간 이후인지 요건 확인 필요

9) [파라미터 배포] 배포중 부분 실패 발생 시 기 성공한 배포 건도 모두 원상 복구

하는지 확인 필요

10) [배포 그룹 생성] 그룹 명에 기존 이름과 동일한 이름으로 등록 가능한지 확인

필요

테스트 케이스 후보들을 정리 수행방법 및 수행결과 예

Page 19: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

테스트를 통한 커뮤니케이션

분석 설계 개발 테스트분석 설계 개발 테스트

분석/설계자 SBE

고객

셀 리더개발자

버스 정류장 등록할 때기존에 존재하는 이름으로등록되어서는 안되겠군

버스 정류장 등록 시이름 중복 체크를 해야합니다

A 개발자님,버스 정류장 등록 화면개발할 때 이름중복 체크 해주세요.

버스 정류장 이름중복체크 해야지.

내가중복 체크(개발)를

했었나?

내가 요건 지시를잘 했었나?

내가 전달을 잘했나?

내가 낸 요건이잘 반영 되었나?

개발팀

PASS(TC1) 이름 중복 테스트

Page 20: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

짝 테스트?

[ 수행방식 ]

개발자와 테스트 인력이 같이 테스트를 수행

40(30분)분 동안 각 20분씩 Observer, Operator(Navigator/Driver)로 수행

※ Observer : 테스트 대상에 대한 테스트 케이스를 구상하고

Operator에게 해당 테스트 수행 지시

Operator : 실제 화면에서 테스트를 수행하고, 결함을 보고

※ Observer는 간단한 테스트 Charter를 작성

[ 기대효과 ]

개발자는 테스터의 테스트 방식을 짧은 기간에 습득

테스터는 개발 대상에 대한 이해도를 높임

개발자-테스터 간의 커뮤니케이션 개선

짝테스트 수행 시 유의사항

Page 21: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

[ 수행 사례 ]- 하나의 스프린트 내에 단위/API/UI 영역에 대한 짝 테스트 수행 (인별 40분씩)

- 테스터의 일정표에 본인이 편한 시간을 예약하면 해당 시간에 개발자 자리에서 짝테스트 수행

세션 짝개발자 일시 대상 수행 중 메모 후 이메일로 공유

1 A개발첫째날오전

역할관리 화면

[역할관리 - 조회](1) 화면 리사이즈시 데이터 영역이 잘리는 현상 있음(하단 스크롤로 끝까지 옮겨도 표시되지 않음)(2) (공통-검토필요) 현재 화면 위치를 왼쪽 메뉴에서 초록색으로 표시해 주는데 F5 새로 고침 시 초록색이 표시되지 않음(3) (권고) 조회조건에 역할의 사용여부로 조회할 수 있는 기능이 있었으면 편할 것으로 보임(4) 검색조건에 특수문자 입력이 가능하거나 타 화면과 달리 trim 처리가 적용/ 또는 미적용된 경우가 섞여 있음(5) (검토예정이라고 함) 역할명, 설명등을 주어진 길이만큼 입력하면 목록에서 ... 으로 표시됨.

툴팁이 표시되면 좋을 것으로 보임 * 수정팝업을 띄우면 표시되니 결함보다는 권고사항성입니다~[역할관리 - 추가](6) 입력 시 id, 명에 trim 처리가 필요할 것으로 보임.(조회시는 권고이나 등록/수정 시에는 trim이 필요)(7) (다른 화면도 체크 필요) 신규 추가시에 사용여부를 N으로 하고 저장해도 Y로 저장 됨 <- 쿼리에 'Y'로 박혀 있음[ 사용자 팝업1,2 ](8) 직급 컬럼 등의 정렬이 타 화면과 일치하지 않음 (가운데 정렬 필요)(9) 조회조건 필드가 특수문자는 막혀 있는데 trim 처리는 하는 등 타 검색 필드와 일관성 필요(10) “그거”라고 했던 건 - 체크박스를 선택하고 페이지를 이동하면 다른 페이지에서 선택하지 않은 건들이 선택되어 있는 등 이상 동작을 하는 경우가 발생 함

2 B 개발첫째날오전

업무그룹관리화면 내 팝업

[업무그룹 메뉴팝업](1) 팝업 화면 타이틀명에 공통적으로 언더바가 포함되어 있음(2) 여러 팝업에서 같은 항목의 정렬이 서로 다름

- 길이가 일정한 코드성 데이터는 가운데 정렬, 이메일, 설명 등과 같이 값이 가볍적으로 바뀌는 값들은 좌측 정렬이 맞을 것으로 보임(3) (확인필요) 화면 및 컬럼 폭 리사이즈가 안 되는데 길이가 길어질 수 있는 항목의 경우 툴팁을 검토할 필요가 있음(4) 메뉴에 대해 사용여부를 N으로 수정해도 타 화면 팝업에서 메뉴가 조회됨(5) (권고) 메뉴 추가에서 기존 추가한 메뉴와 새로 추가할 수 있는 메뉴가 구분이 안 됨. 방안 몇가지 얘기했던 것 검토 요청[사용자 팝업](6) 사용자를 선택하지 않고 선택 버튼을 클릭하면 메시지는 "한 건 이상을 선택해 주세요" 라고 정상 표시되나 바로 팝업 창을 닫아버림. 선택할 수 있도록 팝업 창 유지 필요(7) 각 항목들의 좌우 정렬이 타 화면과 다름(8) 팝업 화면 전체에 공통 발생 - 조회 데이터의 필드들이 모두 불필요하게 editable 함

3 C 개발첫째날오후

업무그룹관리메인 화면

[업무그룹관리](1) 업무그룹 ID에 한글이 들어갈 수 있으나 조건조회 해당 필드에 한글이 입력되지 않음(2) (확인필요-일관성) 신규 추가후 리프레시 될 때 추가된 건이 전체 페이지의 제일 하단에 표시되는데 타화면과 기준 논의 필요 <- 사용자 추가의 경우 해당 정렬 위치에

추가되었던 것으로 보임(3) (권고) 조회조건에 업무그룹의 사용여부별로 조회할 수 있었으면 좋겠음(4) 업무그룹ID 등에 trim처리를 해야 할 것으로 보임(5) "그거" 라고 했던, a) 목록 조회에서 전체 조회하여 여러 페이지 조회, b) 조회조건 입력 후 조회버튼이 아닌 끝 으로 이동 선택 => 아무 건도 조회되지 않음, c) 조회조건

삭제하여 전체 조회 => 전체조회는 정상적으로 되나 하단 페이지 숫자가 표시되지 않음.

4 D 개발둘째날오전

로그인,회원가입 / 사용자관리(일부)

[회원가입](1) 로그인 ID 값에 대해 trim 처리를 하지 않음(2) ID 입력, 중복체크 한 상태에서 사용자 이름을 입력하지 않고 저장하면 ID 중복 체크를 하라는 메시지가 표시 됨(3) 비밀번호, 비밀번호 체크에 대해 필수입력 표시 누락(4) (검토) 이메일, 전화번호에 대한 영문자 입력 등에 대해 체크 로직 적용에 대해 검토 권고

* ID, 비밀번호 생성 규칙은 반영 예정이라고 함[로그인] - N/A[사용자관리](5) UI 브라우저 리사이즈 시 사용자 관리만 하단 스크롤이 2개 생기는 현상 있음(6) 전체 화면이 아닌 경우 하단 footer가 페이지 네비게이션 영역을 덮는 현상 발생(7) (권고,공통) 왼쪽 메뉴 접기 아이콘이 있는데 접은 상태에서는 화살 방향이 반대여야 펼치는 기능으로 인지하기 쉬울 것으로 보임(8) 조회 조건의 사용여부 콤보박스 값이 직접 선택 및 수정이 가능함(9) 브라우저 리사이즈 시 조회 영역은 정상 확장되나, 하단 데이터 영역이 확장되지 않는 현상 발생(10) 사용자 정보 수정 팝업에서 필수값을 입력하지 않았을 때의 메시지가 ID중복체크를 하지 않았다는 잘못된 메시지 발생(11) (동시성) A 관리자가 사용자 정보를 수정(팝업)하고 있을 때 B 관리자가 해당 사용자를 삭제. 다시 A 관리자가 수정 저장하면 메시지 상으로는 정상적으로 수정되었다고

표시가 됨(해당 사용자는 삭제) - 서버 상에서 수정하려는 id가 없어서 정상 반환하는 현상 때문으로 보임.

5 E 개발둘째날오후

메뉴관리

[메뉴관리](1) 메뉴에 대해 사용여부를 N으로 수정해도 타 화면 팝업에서 메뉴가 조회됨(2) 메뉴 하위의 메뉴페이지 리스트에 대해 N으로 수정해도 Y로 다시 변경되어 조회 됨(3) 메뉴 하위의 메뉴페이지 신규 추가시 사용여부를 N으로 하고 추가하면 추가는 되었다고 메시지 표시되나

실제로는 저장 안 됨(4) 메뉴 페이지를 여러개 등록한 후 삭제하면, 삭제가 1,2건만 되고 이후 삭제가 되지 않음(5) 하나의 메뉴에 대해 동시에 다른 페이지에서 접근하는 테스트에 대해

A가 보고 있는 상태에서 B가 삭제하는 경우 A에서 다른 동작을 하면 "알 수 없는 에러가 발생하였습니다" 라는 상황을 파악하기 어려운 메시지가 표시됨

(6) UI 브라우저 리사이즈 시 조회 영역은 정상 확장되나, 하단 데이터 영역이 확장되지 않는 현상 발생

사용자 화면 짝 테스트 수행 사례

Page 22: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

짝 테스트 수행회고(사례)

- 좋았던 점 -

(A) 미처 생각지 못한 버그도 찾아내 준 점,

각 활동마다 30분 씩 시간 맞추어서 하신 점도 정말 좋았습니다

(B) 짝테스트는 Junit보다 화면 테스트할 때 도움이 많이 되었습니다.

다른 사례에서 비슷한 문제의 해결방법에 대해 들은 것이 좋았습니다.

(C) 짧은 시간에 버그를 많이 잡아준 점

- 나빴던 점, 개선 점 -

(B) 짝테스트 30분은 시간이 좀 짧아서 더 많이 찾을 수 있었는데 아쉬웠습니다

짝 테스트시 네비게이터와 드라이버가 아니고 같이 동작해보고 얘기하는 시간도 있으면

좋을 것 같습니다

(C) 개발자가 네비게이터가 되면 매일 하던 방법으로 테스트 하게 되는 것 같아서 더 자주 많이

했으면 합니다

Page 23: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

테스트 자동화

[ An Overview of Agile Testing by Lisa Crispin ]

[ 애자일 테스트 자동화 피라미드 ]각 피라미드의 영역은 자동화했을 때 투자대비 효과를

의미하며, 이는 곧 자동화해야 하는 양을 뜻한다

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

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

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

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

서 건드려도 끄떡없다.

중간 단계는 통나무집으로 튼튼한 상태를 유지하기 위해서는

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

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

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

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

지나고 나면 큰 효과를 낸다밑으로 갈 수로 ROI가 크고자동화의 양이 많아야 한다

Page 24: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

잦은 변경에 대비한 테스트 자동화, 회귀 테스트

http://www.softwaretestinghelp.com/regression-testing-tools-and-methods/

Page 25: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

테스트 레벨 별 테스트 자동화 전략 수립 사례

※ 아키텍처 레벨에서의 테스트 수행 우선 순위- 1순위 : UI 레벨에서 개발자와의 짝 테스트 설계/수행 > 자동화

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

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

RDMBS

DAO implementations

DAO interfaces

Service implementations

Service interfaces

Other remote interfaces

Data AccessLayer

ServiceLayer

PresentationLayer

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

Controller에 대한 테스트

Service에 대한 테스트

DAO 에 대한 테스트

Controller

REST API

RESTful API 테스트UI

11

22

33

44

55

우선순위 : 중DAO가 SQL문을 실행해 DB에 CRUD 기능을 수행하는측면에서 별도 테스트가 필요

우선순위 : 상사용자의 요청에 대해 비즈니스 로직 및 DAO를호출하여 실제 해당 기능을 수행하는 주요 클래스로별도 테스트가 필요 함

우선순위 : 하Controller 자체는 UI의 요청 값을 Service에잘 전달하기 위한 목적으로 Service 레벨 테스트와 비교해봤을 때 테스트 방법이 어렵고 유지보수가 어려워 중요도

가 떨어짐

우선순위 : 상재사용 모듈 및 다양한 클라이언트 방식(웹, 폰 등)을 지원한다는 측면에서 REST API 레벨에서의테스트 강화가 필요 함

우선순위 : 상화면 매뉴얼 테스트는 현재 품질이 떨어진다는 측면에서가장 강화가 필요한 영역임. 이후 항구적인 테스트 수준향상을 위해 테스터-개발자 짝으로 테스트를 진행할 필요 있음

우선순위 : 중화면 테스트 자동화는 재사용 모듈로서 BP관점에서 적용할 가치가 있으며,멀티 브라우저 테스트 자동화를 통해 테스트 공수를 크게 절감할 수 있음

Page 26: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

테스트 자동화 환경 구축

- Jenkins, SonarQube 등을 이용한 자동화 환경 구축

- 구조화된 테스트 코드, 공통함수, 데이터 기반 테스트 등 BP 적용

Structured Test Utility

Jenkins TestCoverage report

Jenkins Test Result Report

TestCoverage in sourcecode

Page 27: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

자산화

시행착오에 대한 Smart한 절차 정의

Page 28: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

빈발결함 정제, 화면, API, 프레임워크 레벨 개발 표준 정의

- 빈발결함 정제

- 결함 예방을 위한 개발표준 정의 등(예외 처리, 로그처리 가이드,

기능 명세서 가이드 및 사례,

도메인 특화된 테스트 체크리스트)

Page 29: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

� 애자일 테스트는

전하고 싶은 메시지…

다 덤벼,다 덤벼,

다덤볏!!

가까이,

끊임없이,

닭이 아닌 돼지로(같이) 협업.

현실적이고 지속 가능한 형태

보람

Page 30: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

사례에 대한 테스트 스스로의 회고

- 일회성 보여주기 식이 아닌, 내재화된 프랙티스화에 대한 어려움( “그분” 들과의 갭…)

- 테스트 인력 확보 및 역량 강화( *점점 더 축소되는 테스트 수행 역할 )

- 테스트에 대한 인식 변화는 언제쯤..

- 애자일을 제대로 하는 스크럼 팀?

- 인수 테스트, 비기능 테스트 등 더 넓은 영역으로의 확장

Page 31: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

감. 사. 합. 니. 다.

Page 32: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

별첨.기존 테스트 조직의 위기

테스트 조직테스트 조직테스트를 어렵게 하는

기술적 이슈

과거의 동료,현재의 적?품질을 포기하고 어둠의 세계로~

품질이 취약한‘말로만’ 애자일

품질 마인드가 없는무한복제 개발자

왜 테스트가 애자일을 고민하지?발췌 : 테스트 패러다임의 변화 문서

클라우드, 모바일 테스트, 원격 테스트 등새롭게 떠오르는 위협들

Page 33: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

별첨.기존 테스트 조직의 위기

[ 애자일 ]- 기민한

- 문서, 산출물 보다는 실제 제품- 작고 빠른 릴리즈

- 애자일 모르면 사람 아님 - 애자일 열풍

애자일?

애자일 내용 참조

Page 34: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

별첨.기존 테스트 조직의 위기

[애자일 선언문의 바탕에 깔려있는 원칙들]

- 최고 우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 고객에게 전달함으로써 고객을 만족시키는 것이다. - 작동하는 소프트웨어가 진척 측정의 주된 척도이다. - 간결함-하지 않아도 되는 일의 양을 최대화하는 기술-은 필수적이다.

- 비록 개발 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게한다. - 작동하는 소프트웨어를 자주 전달하라. 약 2주에서 2개월의 정도의 간격으로 전달하되, 간격이 짧을수록 좋다.

- 비즈니스 영역 사람들과 개발자들은 프로젝트 전체에 걸쳐 매일 함께 일해야 한다. - 어떤 다른 개발팀을 상대로, 혹은 개발팀 내에서, 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 보고 하는 대화이다. - 최상의 아키텍처, 요구사항, 그리고 설계는 자기조직화(self-organizing)되어 있는 팀에서 나온다.

- 동기가 갖추어져 있는 개인들로 프로젝트를 구성하라. 그들에게 그들이 필요로 하는 환경과 지원을 제공하라. 그리고 그들이 일을 끝낼 수 있도록 신뢰하라. - 기술적 탁월함과 좋은 설계에 대한 지속적 관심이 기민함을 향상시킨다. - 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 그리고 사용자들은 일정한 속도를 계속 유지할 수 있어야 한다.

- 정기적으로, 팀 차원에서 어떻게 하면 더 효과적일 수 있을지에 대해 되돌아보며 자신들의 행동을 이에 따르도록 조율하고조정한다.

문서,산출물 보다는 실제 제품문서,산출물 보다는 실제 제품

유연함=잦은 변경유연함=잦은 변경

각 역할자간의 가까운 (위치,업무형태)구성각 역할자간의 가까운 (위치,업무형태)구성

동기부여, 사람 중심의 개발동기부여, 사람 중심의 개발

회고회고

Page 35: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

별첨.기존 테스트 조직의 위기

ScrumScrum

테스트 인력

어디서부터어디까지 같이 해야 하지? 같이하지 않아도 되나?

Page 36: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

별첨.기존 테스트 조직의 위기

XP(eXtreme Programming)XP(eXtreme Programming)

1. 함께 앉기

2. 전체 팀 : 필요한 기술과 시야를 지닌 사람들을 전부 팀에 포함시켜라.

3. 정보를 제공하는 작업 공간누구든지 팀이 사용하는 공간에서 15초 안에 프로젝트가 어떻게 진행되는지 대략 감을 잡을 수 있어야 한다

4. 활기찬 작업

5. 짝 프로그래밍

6. 스토리 : 고객에게 가치를 줄 수 있는 최소한의 기능을 단위로 해서 계획하라.

7. 일주일, 분기별 주기

9. 여유

10. 10분 빌드

11. 지속적인 통합

12. 테스트 우선 프로그래밍 (TDD)

13. 점진적인 설계 : 시스템의 설계에 매일 투자하라.

1990년대 후반 켄트 벡(Kent Beck)을 중심 으로 여러 엔지니어들이 프로젝트에서의 교훈을기반으로 효과적이라 생각되는 개발 기법을 모아 하나의 방법론으로 정립

한 팀한 팀

짝 프로그래밍,라이트한 빌드,지속적인 통합

TDD

짝 프로그래밍,라이트한 빌드,지속적인 통합

TDD

Page 37: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

별첨.기존 테스트 조직의 위기

테스트 인력

애자일 프로젝트에 전통적인 테스트 방식으로 접근했을 때의기존 경험담

- 폐쇄적인 개발팀- 산출물- 잦은 변경 및 이 잦은 변경이 애자일이기 때문이라는 설명

- 팀 별로 테스트 인력 배정을 위해서는 인원부족- 테스트 인력의 역량 문제(애자일, 개발 지식 등)- 팀 내에서 개발자들과 달리 정형화된 테스트 업무가 정의되지 않음

난.. 누구?..여긴.. 어디?

돌아가기돌아가기돌아가기돌아가기

Page 38: 애자일 테스트 프랙티스와 사례들 (부제: 협업의 힘)

별첨. 짝테스트 수행 시 유의사항

유의사항. 전체 시간 40분(30분)은 조정 가능하나 너무 길게 하지 말 것

(많은 에너지가 필요한 일임)

. 테스트 외적인 얘기는 가급적 지양

. 안 맞는 사람한테 무리하게 하려고 하지 말 것

. 한 번에 많은 것을 얻으려고 하기 보다는 짧게 자주해서 생활화

. 대상을 배우고, 품질 마인드를 심어주는 목적이 달성되면 줄이는 것도 검토( 시간 대비 얻는 효과가 적어지는 시점)

돌아가기돌아가기돌아가기돌아가기