애자일 테스팅 Part1, Part2

애자일테스팅 (리사 크리스핀, 자넷 글로고리 저)에 대한 요약 노트

1장. 애자일이란 대체 무엇인가?

애자일 가치

  • 애자일 매니페스토
    • 프로세스와 도구 보다 개인과 상호작용
    • 포괄적인 문서보다 ** 동작하는 소프트웨어 **
    • 계약 협상보다 ** 고객과의 협력**
    • 계획 준수보다 변경에 대한 응대

애자일 테스팅이란

  • 애자일 팀의 각 구성원은 비즈니스 가치를 제공하고 높은 품질의 제품을 만드는 일에 집중한다.
  • 애자일 테스터는 자신이 속한 팀이 높은 품질의 제품 제공을 보장하는 일을 한다.
  • 애자일 개발에서는 팀이 문제를 함께 해결하도록 장려한다. 모든 연관된 사람이 그들의 제품을 향상시키는 최선의 방법이 무엇인지 함께 결정한다.
  • 테스터에게 있어 무엇보다 최선은 최고의 품질을 만들어내는 데 책임을 느끼고 테스팅에 모든 것을 집중하는 사람으로 구성된 팀과 함께 일하는 것이다.
  • 이 책에서 ‘애자일 테스팅’이라고 말하는 것은 일반적으로 비즈니스 중심 테스트, 즉 비즈니스 전문가가 바라는 특징과 기능을 정의한 테스트를 의미한다.

애자일 테스팅은 어떻게 다른가

  • 애자일은 반복적이고 점증적이다. 테스터가 코드 작성의 매 증분을 완료하자마자 테스트한다는 것을 의미한다.
    • 팀의 코드의 일 부분을 빌드한 뒤 테스타하고, 제대로 작업했는지 확인하고, 그 뒤 빌드해야하는 다음 부분으로 넘어간다.
    • 스토리가 테스트 되기 전까지는 완료된 것이 아니기 때문에 프로그래머는 절대 테스터보다 앞서 진행하지 못한다.
  • 코드 작성을 염두에 두지 않고 비즈니스 분석을 이용해 만든 요구사항 문서를 가지고 테스트를 만들어내기보다는 ** 코딩이 시작되기 며칠 전 혹인 몇 시간 전에 각 스토리의 요구사항을 묘사하는 테스트**를 작성해야한다.
  • 정의된 테스트 케이스 이외에 탐색적 테스트를 통해 놓칠수 있는 부분을 테스트하고, 테스터는 각 스트리의 코드를 작성하면서 테스트케이스를 자동화하고, 다른 프로그래머와 짝을 이루어 함께 작업한다. 자동화 기능 테스트는 회귀 테스트 수트에 추가된다. **최소한의 기능을 기술하는 테스트가 완료 되었을 때, 팀은 스토리가 종료되었다고 할 수 있다. **
  • 애자일 프로젝트에서 테스터의 가장 중요한 차이점은 테스팅에서 빠른 피드백을 받는다는 것이다. 이 피드백은 프로젝트를 앞으로 나아가게 하며, 일정한 마일스톤에 이르지 못했다고 프로젝트를 차단하려는 문지기는 없다.

전체 팀 접근 방법

2장. 애자일 테스터를 위한 열가지 원칙

애자일 테스터란 무엇인가

  • 애자일 테스터는 :
    • 전문적인 테스터로 변화를 포용하고,
    • 개발자에서 관리자까지 다양한 이해관계자와의 의사소통에 능하며,
    • 요구사항을 문서화해 테스트를 사용하는 개념을 이해하고.
    • 개발을 이끄는 사람이다.

애자일 테스팅을 위한 사고방식

  • 애자일 팀은 끊임없이 최선을 다해서 최고의 성과를 얻기 위해 매진하는 팀이다
  • 창조성, 열린 생각, 어떤 일이나 역할도 받아들일 수 있는 의지, 고객 중심적 사고, 그리고 지속적으로 큰 그림을 보려는 자세
  • 테스터는 소프트웨어가 어디서 어떻게 잘못된 동작을 하게 되는지 그리고 이와 같은 오류를 추적할 수 있는 방법은 무엇인지에 대한 이해와 본능적인 감각을 가지고 있다.
  • 애자일 테스팅을 위한 사고방식은
    • 결과 중심적, 예술가적, 상호 협력적, 배움에 대한 적극성, 일정에 맞춰 비즈니스 가치를 창출하려는 열정을 필요로 한다.
  • 애자일 테스팅 마인드 셋

애자일 테스팅 마인드 셋

애자일 원칙과 가치의 적용

1. 끊임없는 피드백

  • ‘정보 제공자’라는 테스터의 전통적인 역할은 애자일 팀에서 테스터의 근본적인 가치를 뒷받침한다.
  • 제품 소유자나 고객으로 하여금 요구사항들을 예시나 테스트 형태로 이야기 할 수 있도록 도와주는 것이다.
  • 이렇게 확인된 요구사항을 팀원들과 함께 실행 가능한 테스트로 만들어 나간다.

2. 고객에 가치 제공

  • 애자일 테스터는 큰 그림에 집중해야한다. 주변 기능에 집중하면 비즈니스 요구에 진정으로 필요한 가치를 주지 못하게 된다.

3. 직접적인 의사소통

  • 3의 힘(Power of three)
    • 하나하나 기능에 대한 논의에 프로그래머, 테스터, 고객 모두가 필요하다.
  • 대면을 통한 커뮤니케이션은 다른 대안이 없다. 애자일 개발은 끊임없는 협업을 바탕으로 하고 있기 때문이다.

4. 용기

  • 실패에 대한 두려움을 이겨내야 하며, 일찍 실패를 경험함으로써 교훈을 얻을 수 있음을 알아야 한다. 실수를 받아들이는 용기또한 필요한다.

5. 단순함

  • 애자일 테스팅은 가능한 최소한의 테스트를 통해 해당 기능 요소가 포함되어 있는지 또는 고객의 품질 표준을 만족하는지를 검증하는 것을 말한다.
  • 간단함이 절대 쉽다는 뜻은 아니다.
    • 테스터들에게 간단하다는 것은 최소한의 도구와 기법을 활용한 “딱 적당한 정도의” 테스팅을 의미한다. 여기서의 최소한의 도구는 스프레드시트나 체크리스트다.
    • 빠른 피드백을 얻어내기 위해서는 회귀 테스트에 대한 자동화를 최대한 세부적인 부분까지 적용할 필요가 있다.
    • 비즈니스 중심 테스트 자동화는 스모크 테스트 정도면 충분할 수 있다.
    • 학습과 찾기 힘든 버그를 찾는 데 활용하는 탐색적 테스팅도 제한된 일정과 목적을 분명히 해야한다.

6. 지속적인 개선 실행

  • 회고하는 과정은 애자일에서 팀이 과거의 경험을 토대로 더 나은 업무 수행을 할 수 있게 해주는 핵심요소다.

… 나는 생산성을 저하시키는 항목을 모아서 ‘방해 목록’을 만들자고 제안했다. 이 목록의 첫 번째 항목으로 내가 적은 것은 테스트 환경의 느린 응답속도였다… (리사의 이야기)

7. 변화에 대응

  • 변경에 대한 대응은 애자일의 핵심가치인 동시에 테스터들에게는 가장 어려운 개념이다. 안정성이야 말로 테스터에게 있어서 가장 중요한 가치일 수 있기 때문이다.
  • 테스트 자동화가 해법의 핵심 가운데 하나이다. 수작업 테스트만 수행해서 성공하는 애자일 팀은 있을 수가 없다는 것은 분명한 사실이다. 비즈니스 가치를 적시에 제공할 수 있기 위해서는 강력한 자동화가 필요하다.

8. 자기 조직화

9. 사람 중심

10. 즐기기

  • 팀원은 자신의 일에서 즐거움을 찾을 수 있어야 한다.
  • 애자일 테스터로서 우리의 직업이 만족스러운 것은 우리가 바라보는 관점과 기술이 팀 전체에 진정한 가치를 더할 수 있도록 해주기 때문이다.

가치의 추가

  • 모든 원칙은 가치를 창출하기 위한 것이다.
  • 아무리 짧은 이터레이션이거나 릴리즈라 하더라도 고객팀의 기대와 개발팀의 산출물 사이에 차이는 쉽게 발생하기 마련이다. 이러한 차이가 발행하는 것을 말기 위해 테스트를 이용할 수 있다.
    • 애자일 테스터는 개발 초기부터 고객과 개발자 모두에게 자주 질문을 던져 올바른 테스트를 수행할 수 있도록 한다.
    • 애자일 테스터는 전통적인 폭포수 유형 개발 프로젝트에서 일하는 테스터에 비해 훨씬 통합적이고 팀 지향적인 접근을 통해 업무를 진행한다. 애자일 테스터는 기술과 경험을 팀과 프로젝트에 적합하게 도입한다. 프로그래머를 적대적으로 대하거나 앉아서 일을 기다린다거나 또는 계획에 너무 많은 시간을 소비하는 테스터는 애자일 팀에서 오래 버티기 어렵다.

위험: 당신은 “진정한” 팀원이 아닙니다.

당신이 테스터인데 기획 회의나 스탠드 업 미팅, 설계 회의 등에 초대받지 못했다면 그 프로젝트에서는 테스터와 개발팀을 따로 떼어서 생각하고 있다고 볼 수 있다. 반면 이런 회의에 참석해서 아무 말도 하지 않고 있다면 테스터가 개발팀의 일원이 아니라는 선입관에 일조하고 있는 것이다. 비즈니스 전문가가 당신의 도움 없이 스토리를 작성하고 요구사항을 정의하고 있다면 애자일 팀에서의 테스터라고 할 수 없다. **
위와 같은 처지에 있다면 당신의 팀이 위험에 처한 것이라고 볼 수 있다. 이런 상황에서 숨어있는 가정은 릴리즈 주기의 후반까지 잘 감지되지 않는다. 다른 구성요소에 대한 스토리의 파급 효과를 발견했을 때 는 이미 늦은 경우가 많다. 팀은 팀 구성원 모두의 기술을 최대한 활용하지 못하기 때문에 최고의 소프트 웨어를 만들 수 없을 것이다. 대화가 단절되면 프로그래머와 고객이 각각 무엇을 하고 있는지 파악할 수 없는 상황이 될 것이고 또한 팀은 좋지 않은 방향으로 개발자와 테스터로 나누어지며 나아가 개발팀이 고객팀으로부터 소외될 위험성이 높아진다.
어떻게 이 위험을 피할 수 있을까? 개발자와 가까운 곳에서 업무할 수 있는지 알아보자. 그것이 어렵다 면 최소한 개발팀에 자주 찾아가서 대화를 나누고 함께 테스트를 진행하기 바란다. 개발자에게 그들이 무엇을 개발하고 있는지 보여달라고 하고, 당신이 작성한 테스트 케이스들을 검토해 달라고 하자. 또 아무도 부르지 않더라도 회의에 참석해야 한다. 테스팅을 수행하고 피드백을 전달해서 당신의 가치를 알리 고 팀에서의 필요성을 확고히 하도록 하자.
**고객의 스토리 작성과 인수 시험을 도와주어야 한다. “전체 당이라는 자세를 강조하고 팀에게 테스팅 문 제를 해결하도록 요청하자
. 당신의 팀이 애자일 방법론의 도입에 어려움을 겪고 있다면 한두 개 정도 의 이터레이션에서 새로운 아이디어를 시험해 보도록 제안해 보자. 활발한 커뮤니케이션을 위해 3의 힘 (Power of Three)” 을 제안해 보는 것도 좋다. 이 책의 정보를 이용해서 테스터가 애자일 팀의 성공에 얼 마나 큰 역할을 할 수 있는지 보여주도록 하자.

3장. 문화적과제

조직문화

품질 철학

  • 전체 팀이 품질을 책임 진다
    • 테스트와 QA에게는 품질을 책임지는 역할에서 품질을 정의하고 유지하는 참여적인 역할로 변화하는 것을 의미한다.
  • 기술과 적응력이 필요하다
    • 수작업 테스트에만 익숙한 테스터는 애자일 개발의 본질인 자동화 접근법을 이해하지 못할 것이다. 이러한 테스터에게 변화란 익숙한 영역에서 벗어나 새로운 기술을 개발하는 것을 의미하기 때문이다.
  • 애자일 접근 방법은 quality-oriented practice 를 도입하기 위한 메커니즘을 제공한다.
  • 테스터에게도 애자일에 대한 시간과 훈련이 필요하다

위험: 품질 경찰 정신

기존의 QA(품질 보증)팀에서 “품질 경찰(quality Police)”이라는 역할을 맡았다면, 그 구성원은 항상 코드를 완벽하게 검토하고 버그를 결함 추적 시스템에서 실행하고 검증해 품질을 보정하도록 강력히 주장한다. 또한 발견한 버그에 대한 측정지표를 관리하고 프로젝트를 출시할지 말 것인지를 최종 결정하는 업무도 담당한다.
한번은 프로그래머가 코딩 표준을 따르도록 하라고 개발 관리자에게 강요한 것을 성과라고 자랑하는 테 스터와 이야기를 나눈 적이 있다. 표준에 미치지 못하는 요구 사항에 대한 버그를 기록하는 데 시간을 소비하는 테스터에 대해 들어본 적도 있다. 이러한 태도는 협업하는 애자일 팀에 적합하지 않으며 대립 구조를 조장하는 행동이다.
“품질 경찰 역할의 또 다른 위험성은 팀이 이것을 품질을 구축하는 개념으로 받아들이지 않고 프로그래머가 테스터를 안전망으로 활용한다는 것이다. 팀은 결함 추적 시스템을 통해 의사소통을 시작하는데, 이는 의사소통에 있어 그리 효과적인 방법이 아니기 때문에 팀이 절대로 “결속”할 수 없다.

적정한 진행 속도 유지

  • 보통 전통적인 테스트 팀은 프로젝트 후반부에 엄청 빠르고 맹렬하게 테스팅하는 것에 익숙하다. 이는 언제나 최선의 일을 해내도록 중시하는 애자일 가치관과 상반된다.
  • 애자일에서는 일정한 개발속도를 유지하도록 권장한다.

고객 관계

조직 규모

팀에 권한 부여

테스트/ QA팀에서 애자일 채택을 가로막는 가로막는 장애물

정체성 살실

  • 자신의 QA정체성을 잃을 수 있다는 두려움
  • 개발 관리자에게 보고할 경우 지원이 끊기고 프로그래머가 우선시 될까 하는 두려움
  • 일에 대한 기술 부족으로 직장을 잃을까하는 두려움
  • 자신과 자신들의 관라지가 새로운 조직에서 적응하지 못할까하는 두려움

역할 추가

훈련 부족

  • 필요할 때에 도움을 구할 것을 두려워하지 말자. 좋은 코칭은 투자에 좋은 결과를 가져다 줄 것이다.

애자일 개념 몰이해

  • 애자일 개발을 작은 폭포수 모델로 적용하는 현상은 문제가 있다.
    • 그림은 코드작성 및 수정을 거쳐서 테스팅에 이르는 미니 폭포수 모델의 “이상적인” 형태를 보여준다. 여기서 코드 작성 다음에 오는 테스팅은 다음 이터레이션을 시작하기 전까진 완료된 것이다. 하지만 실제로 벌어지는 일은 테스팅이 이터레이션의 끝에 억지로 투입되어 보통 다음 이터레이션 때까지 끌고 간다. 프로그래머 는 충분한 수정이 이루지지 않은 상태에서 다음 이터레이션을 위한 일을 시작한다. 머지않아 일부 팀은 항상 테스팅이 밀린 상태로 이터레이션에 들어가고, 항상 그래왔던 것처럼 릴리즈 일자는 연기된다.
  • 미니 폭포수 프로세스
    • 미니 폭포수 프로세스

과거 경험과 자세

역할 간 문화 차이

  • 다른 행둥을 취하는 사람들에게 무엇이 필요한지 파악하고 제공할 방법을 안내하도록 하라.
    • 고객은 개발을 어떻게 진행하는지 또는 고객의 만족 조건에 부합하는지 알 수 있는 방법이 필요하다. 개발자는 비즈니스 우선순위와 요구사항을 알아야 한다. 테스터는 사례를 찾고 그것을 테스트로 변환하는 방법이 필요하다. 모든 팀원은 일류 팀의 구성원이고 가치가 있다고 느끼길 원한다. 각 팀 구성원은 이슈를 제기하고 새로운 아이디어를 시도하는데 있어 편하고 자유로와야 한다. 각 역할의 관점을 이해하면 전환시 팀에게 도움이 된다.

변화의 도입

두려움에 대해 이야기하라

  • 두려움은 변화에 따른 공통적인 반응이다. 사람들에게 강제로 원치 않는 것을 하도록 하는 것은 긍정적인 변화에 해가 될 수 있다. 본보기가 되어 이끌어야 한다.

리사의 이야기

….자넷과 나는 각자 처음으로 XP 팀에 합류했다. 그 당시 많은 XP 실천가들은 XP 팀에서 테스터를 위한 권리 장전은 거의 본 적이 없을 때였다. XP는 “고객 권리 장전”과 “프로그래머 권리 장전을 갖지만, “테스터의 권리 장전은 분명히 빠져 있었다. 팁 하우스(TIP Hou뚀)와 나는 애자일 팀의 성공을 위해 테스터를 지원하고 격려할 고유한 “테스터 권리 장전”을 내놓았다. 지난 수년간 많은 테스터들이 우리에게 와서 이 권리 장전이 그들에게 얼마나 도움이 되었는지, 또 다른 팀 구성원과 테스터가 함께 작업하는 방법을 익히는 데 얼마나 도움을 주었는지에 대해 이야기했다. 나는 규칙이 너무 많은 것은 좋아하지 않지만, 팀이 문화적 장벽을 극보 하고 새로운 방식으로 일하는 방식을 이해하도록 도외줄 수 있다면 유용할 수 있다.다음 목록은 “테스터 권리 장전”이다. 테스터와 애자일 팀을 통합하기 위해 아래의 내용을 사용해보자.

  • 테스트 권리 장전
    • 테스터는 테스팅과 품질, 프로세스와 관련된 이슈를 언제든지 제기할 권리가 있다.
    • 테스터는 고객과 프로그래머, 다른 팀 구성원에게 질문하고 적시에 답변을 받을 권리가 있다.
    • 테스터는 프로그래머와 관리자, 고객 등 어느 누구에게든지 도움을 요청하고 받을 권리가 있다.
    • 테스터는 테스팅 작업을 추정하고 스토리 추정에 포함시킬 권리가 있다.
    • 테스터는 시기적절한 방법으로 테스팅 작업을 수행하는 데 필요한 도구를 사용할 권리가 있다.
    • 테스터는 혼자가 아니라 전체 팀이 품질과 테스팅에 책임이 있음을 기대할 권리가 있다.

팀에게 주인의식 심어주기

  • 주인 의식을 가지고 접근 방식을 조정하는 능력이 있느냐에 대한 것이다.

성공을 축하하기

  • 제대로된 변화를 원한다면 인정하는 행위가 중요하다.
  • 지원을 제공하는 QA관리자에게 지속적으로 보고하도록 하면서 테스터를 개발팀으로 통합하는 것이 애자일 개발로의 전환을 쉽게 하는 방법 중 하나다

관리자의 기대

관리자에 대한 문화적 변화

  • 애자일에서는 단계의 끝을 나타내는 서명은 없으며, 프로젝트의 “완성도”를 단계별로 측정하지도 않는다. 의미가 있는 지표는 각 프로젝트 팀이 결정한다.
  • 저수준으로 팀의 활동을 관리하기 보다는 애자일 팀의 관리자는 팀 구성원이 최선을 다할 수 있도록 장애물을 제거하는 것에 초점을 맞춰야한다.
  • 대부분의 경우 관리자는 높은 역량의 애자일 팀으로 전환하는데 걸릴 오랜 기간 동안 많은 인내가 필요하다. 필수 자원을 제공하도록 보장하고 모든 개인이 높은 질의 작업을 위한 방법을 배울 수 있도록 지원하는 것이 그들의 일이다.
  • QA관리자라면 순차적인 테스팅 단계를 빠른 속도의 이터레이션으로 이동시켜 언제든 다양한 작업을 폭넓게 수행하게 함으로써 테스터의 불만을 극복하는데 도움을 제공하자. 또 테스팅이 더 이상 개발 후에 발생하는 별개의 활동이 아니라 테스팅과 코딩 작성이 통합된 활동이라는 생각을 받아들이도록 도와야 한다.

변화는 쉽지않다

  • 애자일 개발은 빠른 속도를 가진 것 처럼 보이지만, 변화는 더디다

인내하라

고통을 느끼게 두라

신뢰를 쌓아라

  • 공개된 버그 보고서 말고 직접 발견한 문제들을 가지고 그들에게 다가가서 그들이 코드를 체크인하기 전에 먼저 검토해달라고 요청해 보자. 실제로 여러분이 가치에 기여한다고 판단하면 여러분의 생각을 기끼어 들으려고 할 것이다.

개발의 전문성

  • 책이나 신문 기사를 읽거나, 컨퍼런스에 참석하고 새로운 도구나 스크립팅 언어를 배우자 기술을 향상 시키려는 노력을 존중하게 될 것이다.

품질경찰 정신을 주의하라

  • 집행자가 아닌 협력자가 되자. 프로그래머가 코딩 표준을 준수하지 않아 여러분을 괴롭힐 수 있지만 그들이 그렇게 하는 것을 확인하는 것은 여러분의 몫이 아니다.
  • “이 사람들이 행동하도록 만들자”보다는 “제발 해결책을 찾도록 나를 도와줘”라는 식이어야 한다.

불만을 표출하라

4장. 팀 전략

팀 구조

  • 애자일 팀에서 별개의 기능 그룹을 만들면 삶이 고달파진다. 지속적인 의사소통은 애자일 팀의 생명과 같다.
  • 팀 구성원은 물리적인 위치의 멀고 가까움에 관계없이 업무 진행에 있어 서로 밀착되어야 한다.

독립된QA팀

  • QA팀이 개발팀과 별개로 유지되어야하는 이유
    • QA팀의 독립적인 확인 및 참관역할이 매우 중요하다
    • 제품의 품질에 대한 객관적이고 제 3자적인 관점을 제공할 수 있다.
    • 테스터와 개발자가 가까우면 테스터가 개발자처럼 생각하게 되고, 고객 관점을 잃게 된다.
    • 테스터와 개발자가 같은 사람에게 보고하는 경우 테스트 완료된 코드가 아니라 어떤 코드라도 인도하기만 되면 된다는 식으로 갈 수 있다.
  • 테스터를 따로 관리하는 것에서 나아가 이러한 테스트 팀을 하나의 커뮤니티로 발전시켜 나가는 것에 대해 생각해볼 수 있다.

  • 교육 조직을 따로 두어 테스터로서의 커리어 개발을 돕고 구성원간의 아이디어를 나누고 서로 도울 수 있도록 한다.
  • 우리는 테스터를 프로젝트 팀에 통합한다고 해서 그들이 일을 더 잘할 것이라고는 생각하지는 않는다. 애자일 팀에서 일하는 테스터는 고객을 대변하는 것이 자신의 역할이라고 굳게 믿고 팀원들에게 품질 측면에서 생각하는 자세를 심어줄 수 있다고 생각한다.

애자일 프로젝트와 테스터의 융화

  • QA팀을 없애고, 테스터를 프로젝트 그룹 소속으로 일하도록 했을 때에, 하나 이상의 조직에서 대부분의 테스터가 팀 에서 자신의 업무가 무엇인지에 대한 혼란을 겪다가 그만두는 상황이 벌어지는 것을 경험했다.
  • 테스터에게 짝 테스팅, 불완전하거나 계속해서 변경되는 요구사항에 대처하는 방법, 자동화 등의 다양한 기법에 대한 습득이 필요하다는 사실을 모르는 조직들이 많다. 테스터들에게 이러한 영역에 대한 교육과 지도가 매우 중요하다.
  • 테스터가 새로운 프로세스에 익숙해지는 데에 보통 6개월 정도가 소요된느 것을 알게되었다.

리사의 이야기

… 곧 테스팅 작업 목록이 코딩 작업과 함께 나란히 표기되기 시작했고, 테스팅이 완료되기 전에는 그 어떤 스토리도 완료처리 되지 않도록 조치되었다. …

  • 전체 팀 접근법에 근간한 테스팅은 각 반복과 배포주기의 마지막에 모든 테스팅 작업이 완료되는 것을 보증하기 위한 멀고먼 여정이라고 할 수 있다.
  • 회고회의에서는 테슽가 새로 배속된 애자일 팀에 잘 융화 되기 위해 필요한 기술 및 제반 사항에 대한 평가가 이루어질수 있어야한다.

애자일 프로젝트 팀

  • 소속이 다양한 구성원들이 단순히 담당하는 업무 분야를 대변하는 것이 아니라 프로젝트 팀이 존속하는 한 진정한 소속 팀원으로써 업무에 임해야한다.
  • 전통적인 기능별 팀구조와 애자일 팀 구조의 비교
    • 그림 4-1 전통적인 기능별 팀구조와 애자일 팀 구조의 비교
  • 대규모 프로젝트 또는 동시에 많은 수의 프로젝트가 진행되는 경우 매트릭스 형태의 구조가 적합하다. 다양한 분야의 사람들로 이루어진 가상의 팀을 구성하되 각 구성원들은 여전히 소속된 개별 조직으로 업무 보고하는 체계를 유지하도록 한다.

자원

테스터-개발자 비율

  • 테스팅을 담당하는 팀은 지속적으로 필요한 전문적인 기술 수준이나 능력에 대한 목표를 제시하고 발전해 나가야한다.

애자일 테스터 채용

팀 구축

자기 조직화 팀

타 팀과의 공조

모든 팀원에 동등한 가치 부여

  • 팀의 모든 구성원은 동일한 가치를 갖는다.
  • **테스터는 도움을 요청할 권리가 있다. **테스터인 여러분이 자동화와 관련한 문제에 막혀 발을 동동 구르고 있다면, 주저하지 말고 다른 팀원의 도움을 요청할 수 있는 용기가 있어야 한다. 도와줄 수 있는 사람이 바쁠 수 있지만 반드시 도와줄 것이며 또한 그래야한다. 관리자라면 이런 협력이 잘 이뤄지도록 해야한다.

성과와 보상

  • 개발팀은 항상 비즈니스 요구를 염두해 두고 있어야 한다. 비즈니스에 도움이 되는 방향으로 목표를 설정하고 결과적으로 더 나은 수익을 창출한다면 고객 만족도를 더욱 높여 갈 수 있다. 비즈니스 관계 부서와의 거리를 가깝게 유지해 여러분의 프로젝트 성공이 회사 전체의 성공에 확실하게 기여할 수 있도록 하자
  • 아무리 작은 성공이라도 모두 기념하고 축하하는 것이 좋다.

당신이 할 수 있는 것

  • 2장의 열가지 원칙을 따르면 된다. 그러러면 무엇보다 용기가 필요하다.
  • 자리에 일어나서 사람들과 이야기를 나누고, 여러분이 무엇을 도와줄 수 있는지 물어보자.
  • 함께 일하는 팀원들과 직접적인 소통을 이루어 내고, 장애물을 인지하면 팀이 함께 그것을 해결할 수 있도록 도움을 요청하기도 해야한다.

5장. 전통적인 프로세스 전환하기

가벼운 프로세스 찾기

  • 애자일은 모든 것이 새롭다고 하는 것은 어불성설이다. 진행사항을 측정하거나 결함을 추적하거나 테스팅을 계획하는 방법은 여전히 필요하다.
  • 중요한 점은 제시간이 가치를 전달할 수 있도록 이런 프로세스를 가볍게 유지하는 것이다.

측정지표

린 측정

  • 근본적인 린 측정은 “개념에서 현금으로”, 즉 고객의 요구사항이 소프트웨어로 가는 데 걸리는 시간이다. 이것에 대한 측정 값을 “사이클 타임” 이라고 한다. 가장 중요한 것은 새로운 비즈니스 가치를 만드는 팀의 “반복성과 신뢰성”이다.
  • 린 측정 지표가 좋은 이유는 비즈니스 가치를 전달하고자 하는 목표와 일치하기 때문이다.

측정지표의 필요성

  • 측정 지표는 팀이 정해진 길을 벗어 날 때 이정표 역할을 하거나 바른 방향에 대한 피드백을 제공하는 데 사용된다.
  • 무엇을 측정할지 결정하기 위해서는, 첫번째로 풀고자 하는 문제가 무엇인지 이해해야한다. 그것을 알아 냈다면 목표를 설정할 수 있다. 목표는 측정 가능해야한다.
  • 측정 지표가 아닌 목표에 집중하자

측정 지표로 하지 말아야 할일

  • 측정 가능한 목표는 좋은 것이다. 어떤 방법으로도 측정할 수 없다면 달성했다고 말할 수 없다.
  • 반면에 개인이나 팀의 성과를 측정하는데 측정지표를 사용하는 것은 위험하다. 스스로 통계의 해석을 왜곡하고 해로운 방법으로 사용할 수 있기 때문이다.

결함추적

결함 추적 시스템을 사용하는 이유

  • 편리함
  • 지식저장소
    • DTS에 보관하는 편이 좋은 버그는 간헐적으로 발생하거나 추적하는데 너무 오래 걸리는 버그다.
  • 규모가 크거나 분산된 팀
  • 고객 지원
  • 측정 지표
  • 추적성

결함 추적 시스템을 사용하지 말아야하는 이유

  • 의사소통 도구
  • 시간과 인벤토리 낭비
    • 테스트가 그냥 프로그래머와 직접 대화하면서 발견한 것을 보여주고 개발자가 바로 결함을 수정하는 것이 훨씬 쉽지 않을까?
    • 린 원칙에 따르면 이러한 결함 인벤토리는 낭비다. 팀 차원에서 이러한 낭비를 줄일 수 있는 방법을 생각해야한다.

초점 유지하기

  • 결함을 보고하고 추적하는 작업에 대한 결정은 중요하지만 주요 목표의 추적을 잃지 말아야한다. 가능한 최고의 품질을 제품에 만들어내고 시기적절한 방법으로 비즈니스에 가치를 제공하는 것이 초점이다
  • 결함이 많다면 문제의 원인을 조사하자

테스트 계획

테스트 전략 vs. 테스트 계획

  • 애자일 프로젝트에서는 테스터가 필요로하는 것이 무엇인지에 대한 의사소통을 위해 많은 문서에 의존하지 않는다. 테스터는 나머지 팀과 함께 작업하고 테스팅 업무는 작업 카드 형태로 모두가 볼수 있다. 그래서 “여전히 테스트 계획이 필요합니까?”라는 질문을 자주 던진다.
  • 이해 관계자에게 정말로 필요한 정보가 무엇인지 생각해보자. 얼마나 자주, 그리고 사용되는 목적이 무엇인지 생각하자
  • 테스트 전략은 장기적인 활동 계획이다.
  • 테스트 계획은 프로젝트를 시작하기 전에 위함과 의존성, 큰 그림에 대해 생각해 보기 위함이다.
Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중