Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)

1,796 views

Published on

상업적 이용 및 출처없는 무단전재를 금합니다.
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일의 스크럼, XP에 대한 기본적인 소개와 스크럼 팀 안에서 테스트 역할자로써 사용자 스토리 리뷰, 테스트 설계, 짝 테스트, 테스트 자동화 등에 대한 내용을 사례 기반으로 소개하고 있습니다.

Published in: Software
  • Be the first to comment

애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)

  1. 1. 테스트 엔지니어 교육 - 테스트 기본교육 - 테스트
  2. 2. 테스트 교육 2. 애자일과 애자일 테스트
  3. 3. 애자일이란 - 정보통신산업진흥원 소프트웨어공학센터 (http://www.software.kr/) 2.1 애자일이란
  4. 4. 해당 자료로 다음 항목 설명 - 애자일 선언문 - 기원 및 종류 - 스크럼, XP, 린 - 사용자 스토리 - 릴리즈 플래닝 - 추정 - 플래닝포커 - 스프린트, 스프린트 플래닝 - 일일 스크럼 - 짝 프로그래밍 - CI - 스프린트 리뷰 - 회고 2.1 애자일이란 - 팀이 소통하기 시작하다 - 애자일 팀에 개발자 말고 또 누가 있나요? - 애자일 적용 시 빠지기 쉬운 함정 애자일 설명 속에서 테스트 역할자는 어느 시점, 어느 장소에서 어떤 일을 할 것인지… 또는 아예 안 할 것인지 해당 자료로 다음 항목 설명
  5. 5. 애자일 테스트가 따로 있나요? 2.2 애자일 테스트란 애자일 테스트? 애자일에서 테스트하는 것? 테스트를 애자일스럽게 하는 것? 팀의 일원? 객관성은… 애자일도 모르는데 애자일 테스팅은 무슨 일을 해야 할지? 설계? 테스팅? 자동화? 커뮤니케이션? 개발 코드를 봐야 하나?
  6. 6. 테스트와 애자일, 또는, Waterfall의 테스트와 애자일의 테스트 2.2 애자일 테스트란 닭닭닭닭((((chikenchikenchikenchiken))))과과과과 돼지돼지돼지돼지(pig)(pig)(pig)(pig) 이야기이야기이야기이야기 "스크럼(Scrum)에서는 팀원과 비 팀원의 역할을 돼지와 닭 이라고 이름 붙였다. 팀원은 돼지(자존심 접었다!)고 비 팀원(관리자, 지원, QA 등)은 닭이다. 이 용어는 농장의 동물이 모여서 식당을 연다는 우화에서 나왔다. 아침 메뉴로 베이컨과 계란 프라이를 내놓으려고 할 때, 닭은 단순히 계란을 하나 내며 참여하는 수준이지만, 돼지는 자기 살을 내어주는 헌신인 것이다. 오직‘돼지’만이 스크럼 스탠드 업 미팅에 참석하는 것이 허용된다." - 애자일 프랙티스 226쪽에서 - 이이이이 우화는우화는우화는우화는 Scrum 및및및및 XP 등의등의등의등의 Agile 방법론에서방법론에서방법론에서방법론에서 중요하게중요하게중요하게중요하게 중요하게중요하게중요하게중요하게 생각하는생각하는생각하는생각하는 Team Work에에에에 관한관한관한관한 이야기다이야기다이야기다이야기다 외부외부외부외부 테스트테스트테스트테스트 조직조직조직조직////인력이인력이인력이인력이 닭? 돼지가 될 수 있을까? 외부외부외부외부 테스트테스트테스트테스트 조직조직조직조직////인력이인력이인력이인력이 닭? 돼지가 될 수 있을까?
  7. 7. 2.2 애자일 테스트란 애자일에서 테스트 전담자는 필요할까? 정답은: 필요할 수도 있고, 필요 없을 수도 있다 테스트 전담자는 다음의 일을 할 것이다. - 사용자 스토리 완료를 확인시켜 줄 수 있는 테스트 시나리오(케이스)를 작성할 것이다 - 고객과 개발자를 이어주는 가교 역할을 할 것이다(2인3각 경주) - 변화에 유연하게 대응하도록 해주는 테스트 자동화를 고민할 것이다 - 위 일들이 다 끝나면 추가적으로 탐색적 테스팅을 수행할 것이다 - 테스트 자산을 축적할 것이다(빈발결함, 품질 추이, 교육자료 등) 이 일들을 할 누군가가 있으면 된다 단위 테스트를 대신 해주기 위해 테스트 전담자가 필요하다??
  8. 8. 2.2 애자일 테스트란 [애자일 선언문의 바탕에 깔려있는 원칙들] - 최고 우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 고객에게 전달함으로써 고객을 만족시키는 것이다. - 작동하는 소프트웨어가 진척 측정의 주된 척도이다. - 간결함-하지 않아도 되는 일의 양을 최대화하는 기술-은 필수적이다. - 비록 개발 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다. - 작동하는 소프트웨어를 자주 전달하라. 약 2주에서 2개월의 정도의 간격으로 전달하되, 간격이 짧을수록 좋다. - 비즈니스 영역 사람들과 개발자들은 프로젝트 전체에 걸쳐 매일 함께 일해야 한다. - 어떤 다른 개발팀을 상대로, 혹은 개발팀 내에서, 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 보고 하는 대 화이다. - 최상의 아키텍처, 요구사항, 그리고 설계는 자기조직화(self-organizing)되어 있는 팀에서 나온다. - 동기가 갖추어져 있는 개인들로 프로젝트를 구성하라. 그들에게 그들이 필요로 하는 환경과 지원을 제공하라. 그리고 그들 이 일을 끝낼 수 있도록 신뢰하라. - 기술적 탁월함과 좋은 설계에 대한 지속적 관심이 기민함을 향상시킨다. - 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 그리고 사용자들은 일정한 속도를 계속 유지할 수 있 어야 한다. - 정기적으로, 팀 차원에서 어떻게 하면 더 효과적일 수 있을지에 대해 되돌아보며 자신들의 행동을 이에 따르도록 조율하고 조정한다. 문서,산출물 보다는 실제 제품문서,산출물 보다는 실제 제품 유연함=잦은 변경유연함=잦은 변경 각 역할자간의 가까운 (위치,업무형태)구성각 역할자간의 가까운 (위치,업무형태)구성 동기부여, 사람 중심의 개발동기부여, 사람 중심의 개발 회고회고
  9. 9. 2.2 애자일 테스트란 ScrumScrum 테스트 인력 어디서부터 어디까지 같이 해야 하지? 같이하지 않아도 되나?
  10. 10. 2.2 애자일 테스트란 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
  11. 11. 2.2 애자일 테스트란 테스트 인력 애자일 프로젝트에 전통적인 테스트 방식으로 접근했을 때의 이슈 - 외부에 폐쇄적인 개발팀 - 산출물 - 잦은 변경 및 이 잦은 변경이 애자일이기 때문이라는 설명 - 팀 별로 테스트 인력 배정을 위해서는 인원부족 - 테스트 인력의 역량 문제(애자일, 개발 지식 등) - 팀 내에서 개발자들과 달리 정형화된 테스트 업무가 정의되지 않음 난.. 누구?.. 여긴.. 어디?
  12. 12. 2.2 애자일 테스트란 테스터가 본 애자일 프로젝트 Risk (2011년 11월, 수원의 모 PJT) 1. 우리에게는 익숙하지 않은 “스프린트’, ‘사용자 스토리”… 품질 관리가 어렵다 - “화면 단위” vs 각 개발팀(스크럼팀)별로 천차만별 크기의 “사용자 스토리” - “모든 기능 개발완료” vs “이번 스프린트 대상 개발완료” + 식별되지 않는 연계 2. 각 팀 별로 테스터를 배치하기에는 인력 부족 - 기존의 테스트 인력 규모로는 각 스크럼 팀별 지원이 불가능 3. Product Owner의 역량 부족 - 고객이 각 팀 별로 배치한 Product Owner(팀내 테스터 겸직)은 고객을 대변하지도, 테스트를 수행할만한 역량을 갖지 못함 (PO는 신입사원 또는 타 업무로 바빠서 신경 쓸 수 없는 상황) 4. 커뮤니케이션은 어디로… - 스크럼팀 내에서의 커뮤니케이션은 잘 되는지 모르겠으나, PMO–PL–스크럼 팀간 커뮤니케이션은 전혀 되지 않음 5. 애자일이란 이름으로 면제부를 받은 요구사항 관리 ??? … - 애자일이기 때문이라며 스프린트 중에도 고객으로부터 바로 전달되는 변경 사항(개발자가 이 말을…) - 개발 범위, 일정도 이에 따라 유연하게 바뀌더니… 결국 프로젝트는 연장
  13. 13. 2.2 애자일 테스트란 (참고) 애자일 프로젝트에서 테스터의 역할 - 테스터는 애자일 팀의 일원이다. (Testers are integral part of the team) - 릴리즈/ 이터레이션 계획에 참여 (Participate in Release/Iteration planning) - day1(개발시작) 부터 테스팅 활동을 시작 (Start Testing activities from the day 1) - 인수 테스트의 테스트 기준을 정의하기 위해 고객과 협업한다. - 시스템이 예상한 대로 정확하게 동작하는지 검증한다. - 스토리가 완료되면 그것들을 테스트한다. (Tests Stories once they are complete) - 테스트 자동화에 관심을 갖는다. (Focuses on test automation) - 탐색적 테스팅에 더 집중한다. (Focuses more on exploratory testing) - 동료 테스팅을 수행한다. (Practices pair testing (similar to pair programming) ) - 개발 팀과 협업한다. (Collaborates with Development team) - 팀에 지속적인 피드백을 제공한다. (Provides continuous feedback to the team) 2008년 인도 테스팅 세미나, Role of QA and Testing in Agile, Mayank Gupta 자료
  14. 14. 스크럼 팀에서의 테스트 Activity 2.3 애자일 테스트 프랙티스 테스트 설계 짝 설계(개발/테스트) 테스트 설계 짝 설계(개발/테스트) 짝 테스트, 개발/테스트 코드 리뷰 짝 테스트, 개발/테스트 코드 리뷰 일일 미팅 참여일일 미팅 참여 타 팀을 위한 자산화 타 팀을 위한 자산화 테스트 결과, 빈발결함 공유 테스트 결과, 빈발결함 공유 테스트 수행테스트 수행 테스트 전략, 계획 수립테스트 전략, 계획 수립 테스트 자동화 환경 구축테스트 자동화 환경 구축 테스트 기본교육테스트 기본교육 테스트 코드 작성 가이드테스트 코드 작성 가이드
  15. 15. 2.3 애자일 테스트 프랙티스 고객의 테스트 요구사항 파악 및 테스트 계획 수립 - 고객 요구사항 전반에 따른 일반적인 테스트 계획 수립 - 크로스 브라우저 지원, 다국어 등에 따른 별도 테스트 방안 - 테스트 자동화 전략 수립 고객 개발팀 테스트 경험 : 타 프로젝트 사례, 세미나 크로스 브라우저 지원해 주기 바람 JSP 쓰니 알아서 잘 될거임 어떤 브라우저? 어떤 버전? 원하는 수준은? 자료 : 크로스 브라우저 테스트 가이드
  16. 16. 2.3 애자일 테스트 프랙티스 테스트 기본 교육 - 샘플 기반의 테스트 코드 작성 가이드 - 전체 테스트 프로세스, 관리 툴 교육 [ 테스트 프로세스 및 테스트 코드 작성 가이드 ]
  17. 17. 2.3 애자일 테스트 프랙티스 테스트 설계를 짝으로 수행하기 (1) 개발 요건(설계 산출물 등)에 대해 오프라인 또는 온라인 리뷰 (2) 테스트 케이스 초안 작성 (3) 개발자 인터뷰 (4) 고객 또는 Product Owner와 리뷰 (5) 개발자 피드백 (6) 테스트 케이스 상세 작성 이번 스프린트에 구현해야 하는 기능은… 버스 정류장 이름은 유일해야 하고,… [ 오프라인 수행사례 : 스프린트 플래닝 ] 음.. 테이블 구성은 이렇게 하고, 체크하는 로직은 어디에 위치시켜야 겠다 테스트 케이스 후보!!! “정류장 이름이 같은 경우” 같은 이름을 넣는 경우 넣는 순간 체크해야 하나요, 아니면 저장 버튼을 클릭하는 순간 체크해야 하나요?
  18. 18. 2.3 애자일 테스트 프랙티스 [ 온라인 사례 : 설계서 사전리뷰 -> 개발자와 짝설계 -> 고객과 온라인 리뷰 ] . 수행 방법 : 화면 별로 a)개발자 설명, b) TE 질의, c) 기타 추가 케이스 도출 및 문서 정리를 각 5분씩 수행하여 총 15분 이내로 수행 . 수행 결과 : 1) 각 화면의 컬럼 영역 클릭시 정렬 기능이 적용되어야 하는 사항 공유 2) 파라미터 목록 화면을 제외한 다른 화면에서의 기본(디폴트) 정렬 조건 확인 (파라미터 상세조회의 내역(최근 등록순?), 카드 블랙 리스트의 항목 등) 3) 메시지/버튼명 등에 대한 통일, 다국어 지원 현재는 미적용 내용 공유 4) 스프린트 1에서 엑셀, 인쇄 기능 미구현 확인 필요 5) 각 화면별 필수입력 필드 표시 미정의, 필수 입력(배포 그룹명 등) 에 대한 Trim 처리 확인 필요 6) [파라미터 조회] 조회 건을 클릭시 기본이 "상세조회 화면" 이나 상태가 '임시저장'인 경우 해당 임시저장 화면으로 이동해야 하는 요건 확인 필요 7) [파라미터 생성] 첨부 파일에 대한 최대 크기, 파일 종류가 정해지 있지 않은지 확인 필요(파일은 1개로 확인) 8) [파라미터 생성] Activate Date, Deactivate Date에 대해 적용 시작일이 오늘, 현재 시간 이후인지 요건 확인 필요 9) [파라미터 배포] 배포중 부분 실패 발생 시 기 성공한 배포 건도 모두 원상 복구 하는지 확인 필요 10) [배포 그룹 생성] 그룹 명에 기존 이름과 동일한 이름으로 등록 가능한지 확인 필요 테스트 케이스 후보들을 정리 수행방법 및 수행결과 예
  19. 19. 2.3 애자일 테스트 프랙티스 테스트를 통한 커뮤니케이션 분석 설계 개발 테스트분석 설계 개발 테스트 분석/설계자 SBE 고객 측 셀 리더 개발자 버스 정류장 등록할 때 기존에 존재하는 이름으로 등록되어서는 안되겠군 버스 정류장 등록 시 이름 중복 체크를 해야 합니다 A 개발자님, 버스 정류장 등록 화면 개발할 때 이름 중복 체크 해주세요. 버스 정류장 이름 중복체크 해야지. 내가 중복 체크(개발)를 했었나? 내가 요건 지시를 잘 했었나? 내가 전달을 잘 했나? 내가 낸 요건이 다 반영이 되었나? 개발팀 PASS(TC1) 이름 중복 테스트
  20. 20. 2.3 애자일 테스트 프랙티스 짝 테스트? [ 수행방식 ] 개발자와 테스트 전문인력이 같이 테스트를 수행 30분 동안 각 15분씩 Observer, Operator로 수행 ※ Observer : 테스트 대상에 대한 테스트 케이스를 구상하고 Operator에게 해당 테스트 수행 지시 Operator : 실제 화면에서 테스트를 수행하고, 결함을 보고 ※ Observer는 간단한 테스트 Charter를 작성 [ 기대효과 ] 개발자는 테스터의 테스트 방식을 짧은 기간에 습득 테스터는 개발 대상에 대한 이해도를 높임 개발자-테스터 간의 커뮤니케이션 개선
  21. 21. 2.3 애자일 테스트 프랙티스 [ 수행 시간표 사례 ] 하나의 스프린트 내에 각 개발자 별로 1회 30분씩 수행 구분 수행 일시 개발자 테스터 1 첫째 날 오전1 가개발 A테스터2 첫째 날 오후1 나개발 3 둘째 날 오전1 다개발 4 첫째 날 오전1 라개발 B테스터5 첫째 날 오후1 마개발 6 첫째 날 오후2 바개발
  22. 22. 2.3 애자일 테스트 프랙티스 짝 테스트 수행 결과(사례) (1) 입력 값에 큰 따옴표를 사용하는 경우 SQL문 실행 오류가 발생함(전체 시스템) <- 업무 특성상(게시판 본문 등) 큰 따옴표 입력은 발생하는 상황으로 SQL문 escape 문자 처리를 공통 차원에서 처리해 주지 않으면 모든 화면 단에서 별도 체크를 해야 할 것으로 보임 (2) 입력 값 중 특수문자에 대한 처리가 미흡하여 특정 특수문자 입력(HTML 태그문자)시 데이터가 다 표시되지 않는 현상이 발생 (3) 미리보기 팝업 등 공통으로 제공해 주는 영역에서의 상이한 콘트롤 흐름 확인 필요 (4) 게시글 내용 중에 XSS 공격 문자가 들어가면 업무화면에서는 이상이 없으나, 공통 팝업에서 보안 위배사항으로 데이터를 표시하지 않고 있음 ……
  23. 23. 2.3 애자일 테스트 프랙티스 짝 테스트 수행회고(사례) [ 개발자 ] - 실제 현재는 고쳤지만 테스터가 테스트한 엔터 유지, Like 검색, 특수문자, 한자 변환 등 진작 했으면 미리 고쳤을 결함이 많았다(초기에 했었으면 좋았을 텐데) - “다음에 또 안 하나요? “ [ 테스터 ] - 게시판, 단순 팝업 화면 등 어렵지 않은 화면이어서 아쉽다. 이후에는 더 중요한 결함들을 같이 찾을 수 있을 거 같다 - 개발 환경, 테스트 대상 시스템을 어느 정도 이해할 수 있었다 - 결함이 발생한 부분, 원인 들을 들을 수 있어서 이후 테스트에 많이 도움이 될 것 같다
  24. 24. 2.3 애자일 테스트 프랙티스 ※ 유의사항 . 전체 시간 30분은 조정 가능하나 너무 길게 하지 말 것 (많은 에너지가 필요한 일임) . 테스트 외적인 얘기는 가급적 지양 . 안 맞는 사람한테 무리하게 하려고 하지 말 것 . 한번에 많은 것을 얻으려고 하기 보다는 짧게 자주해서 생활화 . 대상을 배우고, 품질 마인드를 심어주는 목적이 달성되면 줄일 것 ( 시간 대비 얻는 효과가 적어지는 시점)
  25. 25. 2.3 애자일 테스트 프랙티스 전문성 있는 테스트 결과 공유 (스프린트 종료 활동)
  26. 26. 2.3 애자일 테스트 프랙티스 테스트 자동화 전략 수립 어딘가의 리더테스트 윗분들이 GUI테스트 자동화하면 고과 잘 준다고 했삼. 도입하기 바람 우린 개발 기간이 짧고 변경이 많아서 개발 기간에 GUI 자동화는 어려움. Junit에 Jenkins 물려서 그래프로 점수를 따삼.
  27. 27. 2.3 애자일 테스트 프랙티스 ※ (참고) 애자일 테스트에서 얘기하는 각 영역별 테스트 자동화의 ROI ( 초기 러닝커브가 있기는 하지만 ) 상위보다는 하위 영역의 테스트 자동화가 더 큰 효과 (투자대비 성과) 가 있다 [ An Overview of Agile Testing by Lisa Crispin ] [ 애자일 테스트 자동화 피라미드 ] 각 피라미드의 영역은 자동화했을 때 투자대비 효과를 의미하며, 이는 곧 자동화해야 하는 양을 뜻한다 아기돼지 삼형제 이야기 비유 패트릭 윌슨-윌시(Patrick Wilson-Welsh, 2008)는 테스트 자동 화의 개념을 "아기돼지 삼형제"에 비유해서 설명했다. 맨 아래 단계는 벽돌집으로 이 테스트는 견고하여 늑대가 와 서 건드려도 끄떡없다. 중간 단계는 통나무집으로 튼튼한 상태를 유지하기 위해서는 벽돌집보다는 자주 그 구조를 바꾸어줘야 한다. 맨 꼭대기 단계는 초가집으로 튼튼하게 유지하기가 어렵고 늑대가 쉽게 망가뜨릴 수 있다. 초가집보다는 벽돌집이 “고통스런 러닝커브”를 지나고 나면 큰 효과를 낸다 ROI가 가장 큰 단위테스트 자동화
  28. 28. 2.3 애자일 테스트 프랙티스 테스트 자동화 환경 구축 - Jenkins 자동화 환경 구축 - 구조화된 테스트 코드, 공통함수, 데이터 기반 테스트 등 BP 적용 Structured Test Utility Jenkins TestCoverage report Jenkins Test Result Report TestCoverage in sourcecode
  29. 29. 2.3 애자일 테스트 프랙티스 품질/테스트 관점의 개발표준 가이드 - 빈발결함 정제 - 결함 예방을 위한 개발표준 정의 등 (예외 처리, 로그처리 가이드, 기능 명세서 가이드 및 사례, 도메인 특화된 테스트 체크리스트)
  30. 30. 2.3 애자일 테스트 프랙티스 자산화 시행착오에 대한 Smart한 절차 정의 상세 가이드, 샘플
  31. 31. 애자일 테스트 조직, 운영 방식 4가지 (이슈사항) 각 스크럼 팀 별로 배정할 테스트 인력이 없으며, 스프린트 기간 내내 어떤 일을 할 지 명확 하지 않음 2.4 애자일 테스트 운용 Option 4. 별도 테스트 팀이 특정 스프린트에서 테스트 수행Option 4. 별도 테스트 팀이 특정 스프린트에서 테스트 수행 Option 1. 스크럼 팀 내 테스트 인력 배치Option 1. 스크럼 팀 내 테스트 인력 배치 스프린트 1 테스트 1테스트 1 가장 이상적이지만 인력,일정 문제가 있음 Option 2. 별도의 테스트 스크럼 팀 구성Option 2. 별도의 테스트 스크럼 팀 구성 스프린트 1 현장에서 가장 많이 보여지는 형태…스프린트 2 Option 3. 개발 스프린트와 테스트 스프린트를 운용Option 3. 개발 스프린트와 테스트 스프린트를 운용 스프린트 1 테스트 1테스트 1 현실적이지만 개발 진척이… 스프린트 2 테스트 1테스트 1 기존 방식과 차이가 없음?스프린트 1 스프린트 2 테스트 1테스트 1 스프린트 2
  32. 32. 2.4 애자일 테스트 운용 각 방식의 장/단점 방식방식방식방식 예상이슈예상이슈예상이슈예상이슈 기대효과기대효과기대효과기대효과 Option 1 (애자일애자일애자일애자일 팀내팀내팀내팀내 테스터테스터테스터테스터 운영운영운영운영) - SI 프로젝트에서 각 애자일 팀별로 테스트 인력을 구성할 수 있는 자원이 없음 - 개발자는 테스터에게 테스트를 위임해 버리고 단위테스트를 하지 않을 수 있음 - 테스트는 디버깅 수준이 될 수 있음(애자일에서는 바람직할 수도 있음) - 프로젝트 차원에서 각 애자일 팀의 결함발생, 수정 등의 품질지표 측정이 어려워 질 수 있음(절차 간소화로) (애자일에서는 바람직할 수도 있음) - 3자 테스터는 현재보다 더 많은 기술지식이 필요함(개발자와 의사소통 증가, Testability가 더 떨어지는 환경에서의 테스트 수행 등) - 테스터는 중립성, 객관성, 독립성을 잃을 수 있음 - 현재3자 테스트 조직에게는 인력자원적으로 적용하기 어려운 테스트 형태로 생각됨 - 현재 프로젝트 조기 투입 시 문제점인 의사소통 문제 및 이로 인한 잘못된 테스트 비용 발생 등을 최소화 할 수 있음 - 빈발결함 공유 등을 통해 조기 테스트의 효과를 극대화 할 수 있음 - 개발팀에 품질 마인드를 개발 초기부터 심어줄 수 있음 (품질을 생각하며 개발)
  33. 33. 2.4 애자일 테스트 운용 각 방식의 장/단점 방식방식방식방식 예상이슈예상이슈예상이슈예상이슈 기대효과기대효과기대효과기대효과 Option 2 (별도별도별도별도 테스트테스트테스트테스트 스프린트스프린트스프린트스프린트 운영운영운영운영) - 3자 테스터는 현재보다 더 많은 기술지식이 필요할 수 있음 - “테스트 스프린트”가 무의미해 질 수 있음 * 현행 프로세스와 동일하게 진행되면서 테스트 대상을 스프린트 초기에 Planning하고 테스트 수행, 배포(결과 공유), 회고 등의 활동이 유지되지 못할 수 있음. 유명무실한 테스트 스프린트 운영 - 개발팀이 개발 스프린트별로 끊어서 개발 및 테스트할 수 있는 테스트 물량 제공이 가능한지가 성공의 핵심 포인트 - 개발팀과의 Communication이 Option1에 비해 어려움 - 개발완료 후 개발팀은 신규 개발, 테스트팀은 완료 건을 테스트하기 때문에 개발팀의 결함조치가 늦어질 수 있고 개발팀은 신규개발과 결함조치가 겹쳐 개발스프린트 진행에 어려움을 겪을 수 있음 - Iterative한 테스트 수행가능 - 개발 스프린트와 테스트 스프린트가 분리 수행되어 인력적으로 부족한 외부 테스트 조직에 의한 통합된 테스트 스프린트 운영 가능성 있음 - 기존 테스트 방식보다 더 계획적인 테스트 수행 가능(스프린트별 테스트 물량 선정, 수행으로 이후 예측이 용이해지고 이에 따른 추가적인 계획이 가능해짐)
  34. 34. 2.4 애자일 테스트 운용 각 방식의 장/단점 방식방식방식방식 예상이슈예상이슈예상이슈예상이슈 기대효과기대효과기대효과기대효과 Option 3 (비정기적비정기적비정기적비정기적 테스트테스트테스트테스트 스프린트스프린트스프린트스프린트 운영운영운영운영-각각각각 개발개발개발개발 팀별로팀별로팀별로팀별로 개발대신개발대신개발대신개발대신 테스트테스트테스트테스트 수행수행수행수행) - 개발 스프린트에서는 테스트 인력이, 테스트 스프린트에서는 개발 인력이 명확히 어떤 일을 할지 명확하지 않음 - 현행 프로세스와 동일하게 진행되고 테스트 스프린트가 유명무실해 질 수 있음 - 인력이 부족한 테스트 조직에서 각 애자일 팀과의 조율을 통해 분리 수행되는 테스트 스프린트 운영 가능. - 각 개발팀에서 Testable한 묶음을 일정조정하여 각 테스트 스프린트의 입력으로 받고 테스트 수행. - 개발팀은 디버그, 회귀 테스트, 이슈 해결 등의 미흡 활동 수행 가능 - 개발팀과개발팀과개발팀과개발팀과 같이같이같이같이 테스트테스트테스트테스트 스프린트를스프린트를스프린트를스프린트를 진행하기진행하기진행하기진행하기 때문에때문에때문에때문에 의사소통이의사소통이의사소통이의사소통이 상대적으로상대적으로상대적으로상대적으로 잘잘잘잘 됨됨됨됨
  35. 35. 2.4 애자일 테스트 운용 각 방식의 장/단점 방식방식방식방식 예상이슈예상이슈예상이슈예상이슈 기대효과기대효과기대효과기대효과 Option 4 개선모델개선모델개선모델개선모델 (비정기적비정기적비정기적비정기적 별도별도별도별도 테스트테스트테스트테스트 스프린트스프린트스프린트스프린트 운영운영운영운영-개발팀은개발팀은개발팀은개발팀은 개발개발개발개발 진행진행진행진행) - 현행 프로세스와 동일하게 진행되고 테스트 스프린트가 유명무실해 질 수 있음 - 개발팀과의 Communication이 상대적으로 어려움 - 인력이 부족한 테스트 조직에서 각 애자일 팀과의 조율을 통해 분리 수행되는 테스트 스프린트 운영 가능 Option들 중 가장 현실적 적용 가능한 모델이라고 생각됨 - 각 개발팀은 테스트 조직과 일정 조정하여 Testable한 묶음을 각 테스트 스프린트의 입력으로, 테스트 팀은 테스트 수행. 개발팀은 개발 스프린트를 진행
  36. 36. 2.4 애자일 테스트 운용 A팀 (개발 스크럼) B팀 (개발 스크럼) 테스트팀 테스트 스프린트 운용 사례 - 부족한 자원을 최대로 활용하기 위해 별도의 테스트 스프린트 운용 설계,개발 스프린트 (N-1) 설계,개발 스프린트 (N) 설계,개발 스프린트 (N+1) 테스트 (N) 운영방안1 Whole Team 테스터 운영방안1 Whole Team 테스터 … 설계,개발 스프린트 (N-1) 설계,개발 스프린트 (N) 설계,개발 스프린트 (N+1) 테스트 (N) 테스트 스프린트 (N-1) 테스트 스프린트 (N-1) 운영방안2 같은 팀 다른 스프린트 운영방안2 같은 팀 다른 스프린트 운영방안3 다른 팀 다른 스프린트 운영방안3 다른 팀 다른 스프린트 … … 이상적 현실적 운영간 이슈: 테스트 팀의 비용은 누가 지불해야 할까?

×