애자일 테스팅 Part3

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

6장. 테스팅의 목적

사분면의 개요

애자일 테스팅의 사분면

  • 아래는 “More agile testing”에 소개된 그림이다.

Updated 애자일 테스팅 사분면

팀을 지원하는 테스트

왼쪽의 사분면은 제품을 개발하는 팀을 지원하는 테스트를 포함한다.

1사분면

  • 테스트 주도 개발을 나타내며 애자일 개발 실천법의 핵심이다.
  • 보통 xUnit 계열의 테스트 자동화로 자동화된다. 프로그래머 테스트, 개발자 중심 테스트 또는 기술 중심 테스트라고한다.
  • 이들 테스트를 이용하여 켄트 벡(Kent Beck)이 말한 코드 내부 품질이라 불렸던 것을 측정할 수 있다.
  • 1사분면 테스트의 주 목적은 테스트 주도 개발이나 테스트 주도 설계를 위함이다
  • 테스트는 애플리케이션처럼 동일한 프로그래밍 언어로 작성하고 자동화하며, 테스트는 자동화된 프로세스의 일부로 코드를 체크인하면서 실행하여, 내부 품질에 대한 지속적인 피드백을 받는다.

2사분면

  • 비즈니스 중심 테스트이며, 고객이 원하는 외부적 품질과 특징을 정의한다.
  • 개발주도이지만 수준이 더 높다. 2사분면의 테스트는 고객팀이 제공하는 예제에서 도출된다.
    • 테스트는 각 스토리의 상세 내용을 담으며, 기능 수준에서 실행하고 각 테스트는 비즈니스 만족 조건을 확인한다.
    • 비즈니스 도메인 언어로 이해할 수 있는 방식으로 작성된다.
  • 2사분면의 개발 팀을 지원하는 비즈니스 중심 테스트는 자동화가 필요하다.
    • 왼쪽 사분면의 테스트의 가장 중요한 목적 중 하나는 정보를 신속하게 제공하고 문제를 빨리 해결 할 수 있도록 하는 것이다.
    • 빠른 피드백을 얻도록 자주 실행될 수 있어야 한다.
    • 가능하다면 UI계층을 통하지 않고 직접 비즈니스 로직을 실행한다.
  • 또 다른 테스트는 프로토타입과 와이어프레임으로 GUI설계를 검증하도록 돕는 부분이다.
    • 이는 자동화되지 않지만 팀이 제품을 만드는 것을 지원하는 테스트이다.

팀을 지원하는 테스트 사용하기

  • 1사분면과 2사분면의 자동화된 테스트가 제공하는 빠른 피드백은 코드 변경과 추가를 수용하는 애자일 팀의 토대를 형성한다.

제품을 평가하는 테스트

3사분면

  • 비즈니스 중심 테스트를 수행해 제품을 평가할 때, 실제 사용자가 애플리케이션을 작업을 하는 방식을 평가하는 것이다.
  • 이는 사람만이 할 수 있는 수작업 테스팅이다.
    • 테스트 데이타 설정 등에 자동화의 지원을 받으나, 감각과 두뇌, 직관력을 사용해 고객이 요청한 비즈니스 가치를 제공하는 지 확인해야한다.
  • 종종 사용자와 고객이 이런 유형의 테스트를 수행한다. 인수테스트가 그 예다.
  • 사용성 테스팅을 통해 표적 집단이 애플리케이션을 사용하는 방식을 조사하고, 반응을 수집하기 위해 인터뷰도 한다.
  • 탐색적 테스팅은 3사분면의 중심이다. 가장 심각한 버그들의 다수는 이런 종류의 테스트를 통해 드러난다.

4사분면

  • 이 테스트는 기술 중심으로써, 성능,견고성, 보안성과 같은 제품 특성을 평가한다.
  • 새로운 릴리즈나 프로젝트 계획시에 3,4사분면에서 어떤 테스트가 필요한지 언제 끝내야하는지를 논의해야한다.

제품을 평가하는 테스트 사용하기

  • 제품을 평가하는 테스트 과정에서 나온 정보는 사분면의 왼편으로 흘러들어가게 해서, 개발을 지원하기 위한 새로운 테스트를 만드는데 사용돼야한다.
  • 애자일의 짧은 이터레이션은 팀이 학습을 통해 다른 테스트 사분면을 실험해볼 기회를 제공한다.

(참고) 애자일 테스팅 사분면의 다른 모습들 (“More agile testing”에서 발췌)

  • Agile testing quadrants (with Michael Hüttermann’s adaptation)

Agile testing quadrants (with Michael Hüttermann’s adaptation)

  • Gojko Adzic’s version of the agile testing quadrants

Gojko Adzic’s version of the agile testing quadrants

스토리 완료 시기 알기

  • 개발을 지원하는 기술 중심 테스트와 비즈니스 중심 테스트는 실제로 이들을 위해 작업 카드를 작성하든지, 하지 않든지 간에 애자일 개발의 중심이다. 이들 테스트는 각 스토리의 완료를 위한 최선의 기회를 팀에게 제공한다.
  • 제품을 평가하는 기술 중심테스트와 비즈니스 중심 테스트를 수행하는데 필요한 작업을 식별하는 일은 제품이 놓치고 있는 것을 배울 기회를 제공한다.
  • 네 개의 사분면 모두에서 테스트를 조합하면 팀은 각 기능이 품질과 기능에 대한 고객의 평가를 만족하는 시기를 알게 해준다.

책임 공유

  • 제품팀은 애자일 테스트 사분면의 모든 부분을 다루기 위해 광범위한 전문성이 필요하다.
    • 프로그래머는 프로그래밍을 지원하는 기술 중심 테스트를 작성해야하지만, 테스터와 데이터베이스 설게자, 시스템 관리자, 형상관리 전문가로 부터 다른 시간에 도움을 필요로 할 것이다.
    • 테스터는 주로 고객을 중심으로 한 비즈니스 중심 테스트를 책임지지만, 프로그래머는 테스트를 설계하고 자동화하는 데 참여하면서 필요에 따라 사용성과 다른 분야 전문가를 부를 수 있다.
  • 네 번째 분면은 제품을 평가하는 기술 중심 테스트를 수행하는 데 여기에는 더 많은 전문가가 필요할 것이다. 외부에서 자원을 얻을 지라도, 팀은 네 개 사분면의 모든 테스트를 완료할 책임이 있다.

기술적인 채무 관리하기

  • 기술적인 채무는 개발팀이 지름길을 선택하고 마구잡이 해결책을 내놓거나, 스트레스를 받는 상황 때문에 테스트를 작성하거나 자동화하는 일을 건너 뛸 때 만들어진다.
  • 각 사분면은 기술적인 채무를 관리 가능한 수준으로 유지하는 역할을 한다.
    • 코드 작성과 설계를 지원하는 기술 중심 테스트는 코드를 관리 가능한 상태로 유지하는 데 도움을 준다.
    • 단위 테스트를 실행하는 자동화된 빌드와 통합 프로세스는 기술적인 채무를 최소화하기 위해 꼭 필요하다.
    • 코드를 작성하는 동안 단위 수준의 결함을 잡아 내는 것은 팀에 방향을 제시하고 제품 개선을 위해 테스터가 비즈니스 중심 테스트에 집중하도록 할 것이다.
    • 시기 적절한 부하 테스트와 스트레스 테스트는 팀에게 아키텍쳐가 본업에 충실한지를 알게 해준다.

정황주도

  • 각 조직과 제품, 팀마다 고유한 상황에 처하고 각각은 개별 상황에 맞게 일해야 한다는 것을 명심해야한다.

  • 애자일 테스팅 사분면은 모든 다음과 같은 질문을 던져보고 답해보라.

    • 애플리케이션에 적합한 설계를 찾는 것을 도와주는 단위 테스트와 컴포넌트 테스트를 사용하고 있는가?
    • 신속한 피드백을 위해 자동화된 단위 테스트를 실행하는, 자동화된 빌드 프로세스를 갖고 있는가?
    • 비즈니스 중심 테스트를 수행해 고객의 기대를 만족하는 제품을 제공하도록 돕고 있는가?
    • 원하는 시스템 동작의 바른 사례(example)를 잡아내고 있는가? 더 필요한 것은 없는가? 테스트가 이러한 사례에 기반을 두고 있는가?
    • 코드를 작성하기 전에 사용자에게 UI 프로토타입을 보여주고 보고하는가? 최종 소프트웨어가 어떻게 동작할 것인지를 사용자에게 들려줄 수 있는가?
    • 탐색적 테스트를 위한 충분한 시간을 확보하고 있는가? 사용성 테스트를 어떻게 해결하고 있는가? 충분한 고객이 참여하고 있는가?
    • 성능과 보안 같은 기술적 요구사항을 개발 주기 맨 처음부터 고려하고 있는가? 테스트의 다양한 측면을 수행하는 적절한 도구를 갖고 있는가?

7장. 팀을 지원하는 기술 중심 테스트

애자일 테스팅의 기초

  • 팀을 지원하는 기술 중심 테스트가 애자일 개발과 테스팅의 기초를 형성하기 때문에 1사분면을 다뤘다. 이는 설계와 개발에 도움을 준다.

1사분면 테스트의 목적

  • 단위 테스트와 컴포넌트 테스트는 코드가 해야 할 작업을 정확히 이해하도록 개발자를 돕고 올바른 설계에 대한 안내를 제공함으로 품질을 보장한다.
  • 팀이 TDD를 적용하면, 나중에 잡아야 할 많은 버그를 최소화한다. 대부분의 단위 수준 버그는 코드 이전에 테스트를 작성함으로서 방지된다. 단위 테스트를 작성함으로써 설계를 생각해보는 것은 시스템이 고객 요구사항에 부합해 간다는 것을 의미한다.

인프라 차원의 지원

  • 견교한 소스제어, 형상관리, 지속 통합은 개발을 안내하는 프로그래머 테스트로부터 가치를 얻기 위한 핵심이다.
  • 핵심 애자일 실천법이 결여된 애자일 프로젝트는 “작은 폭포수”로 바뀌는 경향이 있다. 개발주기는 짧아 지지만, 코드는 여전히 테스트할 시간이 부족한 “벽 너머”의 테스터에게 던져지고 이 때문에 그 코드는 빈약한 품질을 갖게 된다.

왜 이런 테스트인가?

속도 그 이상을 추구하자

  • 속도가 애자일 개발팀의 최종 목적은 아니다. 대충하려고 한다면 기술적인 채무를 더 많이 지게 되고 어쩌면 마감일을 맞추는 것도 어렵게 될 것이다.
  • 테스트와 코드 작성이 같이 진행되고 있다는 것은 프로그래머가 스토리의 요구사항을 잘 이해했다는 것을 의미한다.
  • 대게 프로그래머들은 스토리 전체가 처음부터 끝까지 동적하는 경로 중 적어도 하나는 확인한다.
  • 이것은 우리가 테스터로서 저수준 버그를 찾는데 시간을 거의 허비하지 않도록 해준다. 프로그래머는 생각하지 않은 시나리오를 시도하고 고수준 비즈니스 기능에 시간을 쓸수 있다.

테스팅을 염두에 둔 설계

  • 테스트로 개발을 주도하는 한가지 이점은 그 코드가 테스트 통과의 의지를 담아서 작성된다는 것이다.
    • 제대로 일을 처리하는 팀은 처음부터 테스트를 실행하고 코드를 작성한 모든 스토리에 대해 테스트를 자동화할 방법에 관해 상각한다.
    • 테스트 주도 개발은 프로그래머가 코드를 작성해 테스트를 통과하도록 만들기 전에 각각의 테스트를 작성한다는 것을 의미한다.
  • 테스트가 용이한 설계의 또 다른 접근 방법의 예는 앨리스테어 콕번의 포트 및 어댑터 패턴(2005) 이다.
  • 팀에서 테스트가 용이한 설계에 대한 접근 방법을 찾을 수 있다. 비결은 테스트와 품질에 대한 전체 팀의 헌신이다. 팀이 꾸준하게 테스트를 작성하고 그 테스트를 통과할 때 깔끔하게 끝낼 방법을 찾게 된다.

시기 적절한 피드백

  • 우리 관점에서 볼 때 단위 테스트를 실행하는 지속 통합과 빌드 프로세스는 10분 내에 끝나야 한다.
  • 신속히 실행하는 빌드 프로세스 하나와 테스트를 그보다 조금 느리게 실행하는 두 번째 빌드 프로세스를 확보하도록 하라.
  • 빌드와 테스트 프로세스가 너무 오래 걸린다면 팀이게 속도가 느려지는 원인을 분석하고 빌드 주기를 더 빠르게 하는 조취를 취하게 하자

어디서 기술 중심 테스트를 멈춰야하는가

  • 단위 수준에서 묘사하기 어려운 테스트를 비즈니스 중심 테스트에서 할 수 있다.
  • 비즈니스 중심 테스트는 더 복잡한 사용자 시나리오를 다루며 최종 사용자가 좋은 경험을 하게 될 것인지를 확인한다. 가능한 한 더 낮은 수준으로 테스트를 해보라. 단위 수준에서 자동화 할 수 있는 테스트를 식별한다면, 거의 항상 투자에 비해 더 나은 이득을 돌려줄 것이다.

이들 테스트를 실행하지 않는다면

테스트가 할 수 있는 일

리사의 이야기

.. “도움을 구하라” 이것이 나를 도와준 패턴 중 하나였다. … 스토리에 대한 FitNesse테스트를 작성하도록 요청했다. .. .

  • 강력한 관리 지원은 1사분면 활동에 팀을 참여하도록 이끄는 핵심이다.

관리자가 할 수 있는 일

  • 인도 날짜를 지키기가 어렵다면 품질이 아니라 범위를 줄이게 하자. 여러분의 업무는 업무 관리자에게 최적의 비즈니스 가치를 얻도록 보장하면서 어떻게 품질을 최우선으로 삼을 것인지를 설명하는 것이다.
  • 팀에게 학습 시간을 할당하고 전문가와 직접 해보는 훈련을 제공하자
  • 테스트 관리자는 개발 관리자와 함께 일하고 테스트 용이성을 개선하고 테스터가 실행가능한 테스트를 작성할 수 있는 훈련을 장려해야한다.

팀 문제

  • 효과적인 변화 에이전트가 되는 방법을 찾는 동안 해볼만한 최선의 일은 해당 문제를 풀어내는 데 전체 팀을 포함시키는 것이다.

툴킷

소스코드제어

  • 자동화된 테스트 스크립트를 위해서도 소스코드제어를 사용한다. 향후 해당 버전에 대한 테스트를 반환해야하는 경우에 테스트에 대한 해당 코드 버전과 자동화된 테스트를 묶어 두는 것이 중요하다. 빌드에 레이블이나 태그를 달 때에 테스트 코드에도 역시 레이블이나 태그를 달았는지 확인한다.

8장. 팀을 지원하는 비즈니스 중심 테스트

비즈니스 중심 테스트로 개발 주도하기

  • 스토리는 필요한 기능의 간단한 설명일 뿐이고, 작업을 계획하고 우선순위를 정하는 목적이다.
  • 비즈니스 중심 테스트는 사례(example)에 기반을 둔 요구사항을 나타내고, 고객과 개발팀 모두가 이해할 수 있는 언어와 형식을 사용한다.
  • 2사분면의 비즈니스 중심 테스트는 코드 작성을 시작하기 전에 각 스토리에 대해 작성하는데, 이들 스토리가 팀이 어떤 코드를 작성해야하는지를 이해하는데 도움을 주기 때문이다.
  • 1사분면의 활동은 내부 품질을 보장하고 팀 생산성을 극대화하며 기술적 채무를 최소화한다. 2사분면 테스트는 외부 품질을 정의하고 확인하며 완료 시기를 알 수 있도록 도와준다.
  • 코딩을 이끄는 고객 테스트는 일반적으로 실행 가능한 형식으로 작성되고 자동화하기 때문에 팀멤버가 자주 테스트를 실행해서 기능이 바라던 대로 동작하는지 알아볼 수 있다. 이들 테스트나 이 테스트의 일부는 자동화된 회귀 테스트 수트 일부가 되어 향후 개발에서 시스템 동작을 무심코 변경하지 않게 된다.

진퇴양난에 빠진 요구사항

  • 스토리 스스로 원하는 기능에 관해 많은 상세한 내용을 제공하지는 못한다. 스토리는 보통
    • 누가 그 기능을 원하는지
    • 그 기능이 무엇인지
    • 그 기능을 원하는 이유를 나타내는 문장이다
  • 스토리는 비즈니스 전문가와 개발팀 간에 진행되는 대화의 시작점으로서만 의미를 가지기도 한다. 팀 멤버가 고객이 해결하려는 문제가 무엇인지를 이해한다면 이들을 사용과 구현을 더 단순하게 만들 수 있는 대안을 제시할 수 있다.
  • 애자일 팀은 고객과 개발자 간에 대화에서 적절한 코드를 작성하기에 충분한 정보를 얻을 때까지 스토리를 확장한다. 테스터는 각 스토리에 대한 사례와 맥락을 이끌어내는 데 도움을 주며 고객에게 스토리 테스트를 작성하도록 도와준다.
  • 요구사항 구조
    • 그림 8-3 요구사항 구조
  • 스토리에는 고객이 진술한 요구사항 이상을 포함해야한다. 사후 조건과 시스템에 전체적으로 끼치는 영향력, 다른 시스템과의 통합에 대한 테스트를 해야한다. 우리는 위험을 식별하고 필요에 따라 테스트로 위함을 완화시킨다. 이들 모든 인자가 코드 작성의 길잡이 노릇을 한다.

  • (참고) Guiding development with examples (from “More Agile Testing”)

Guiding development with examples

  • (참고) Given_when_then template

Given_when_then template

  • (참고) The key process patterns of Specification by Example (from “Specification by Example”)

The key process patterns of Specification by Example

요구사항 이끌어 내기

  • 질문하기
    • 테스터는 다양한 질문을 던지는데 특히 재능이 있다고 할 수 있다. 왜냐하면 항상 머릿속에 큰 그림을 염두에 두고 있고 스토리의 비즈니스 측면과 기술적인 측면을 알고 있으며, 항상 최종 사용자의 경험을 생각하기 때문이다.
    • 질문의 유형은
      • 이 스토리가 문제를 해결하는가?
      • 그렇다면 해결하려는 문제는 어떤 것인가?
      • 문제를 해결하지 못하는 솔루션을 구현하고 있지는 않은가?
      • 해당 스토리로 어떻게 비즈니스 가치를 더할 것인가
      • 이 기능의 최종 사용자는 누구인가?
      • 그 기능에서 어떤 가치를 얻고자 하는가?
      • 그 기능을 사용하기 전후로 사용자는 뭘 할 것인가?
      • 이 스토리를 다 처리했는지 어떻게 알까?
  • 사례 사용하기
    • 가장 중요한 것은 고객에게 해당 기능이 어떻게 동작해야하는지에 대한 사례를 요청하는 것이다.
    • 우리의 도전은 실행 될 수 있는 테스트로서 비즈니스 도메인 언어로 표현될 수 있는 사례를 수집 하는 것이다.
  • 여러가지 관점 고려하기
  • 고객과의 의사소통

명확성 증진

  • 고객팀이 조직의 서로 다른 부서의 사람들로 구성되면 특정 스토리가 의도하는 것이 정확히 무엇인지에 관해 그들 가운데 충돌이 일어날 수 있다.

만족조건

  • 고객 팀의 요구사항을 이해하는 최고의 방법은 고객과 대면해 대화하는 것이다. 모든 사람이 요구사항과 씨름하기 때문에, 고객팀이 각 스토리를 통해 도움을 얻을 수 있는 도구가 있다. 만족 조건은 스토리가 제공하는 기능 뿐만 아니라 더 큰 시스템에 주는 영향도 포함해야한다.

파문 효과

  • 각 이터레이션에서 작은 수의 스토리에 집중할 때 큰 그림을 놓치기 쉽다.
  • 각 스토리가 제공하는 중심 가치를 식별하고 그 스토리를 개발하는 점진적인 접근 방법을 알아내는 데 시간을 들이자

얇은 조각, 작은 덩어리

  • 더 큰 애플리케이션에 끼치는 영향을 염두에 두면서 이들 작은 증분 조각을 정의하기 위해 고객 테스트를 작성한다.
  • 개발을 안내하는 고객 테스트를 작성하는 점진적인 접근 방법은 한 쪽 끝에서 다른 쪽 끝을 잇는 주 경로를 따르는 ‘얇은 조각’으로 시작한다. 이 수준에서 전체적인 아키텍처를 확인할 때 이 조각을 사용한다. 이 강철 쓰레드라 불리는 이것은 모든 컴포넌트를 연결한다. 그리고 견고해진 후에는 기능이 추가될 수 있다.
  • 테스트 할 수있는 가장 꼭 필요한 기능의 얇은 조각으로 시작하자. 이것은 요주의 경로가 될 수도 있다.
  • 얇은 조각이 잘 작동하면, 다음 조각 또는 기능 계층에 대한 고객 테스트를 작성하고, 그 테스트를 통과하게하는 코드를 작성할 수 있다.

완료 시점 판단하기

  • 이들 테스트는 주 경로로 시작해 그 스토리가 의도하는 필요성을 만족하는지 보여준다. 이들 테스트는 다양한 사용자 시나리오를 다루고 시스템의 다른 부분이 부리한 영향을 받지 않는지를 확인한다. 이러한 테스트를 실행하고 테스트를 통과한다. 그럼 이제 끝난 걸까?
  • 진정한 테스트는 소프트웨어 사용자가 그 스토리가 가정하는 동작을 수행할 수 있는지 여부다. 탐색적 테스트와 사용성 테스트, 성능 테스트 같은 3사분면과 4사분면의 활동은 우리가 찾아내야할 것을 도와준다.

테스트를 통한 위험 완화

  • 애자일 개발은 비즈니스 가치를 작고 테스트된 인도 가능한 단위로 만들어, 우선 순위를 정하고 고객을 증분 단계마다 인수에 참여 시킴으로써 위함을 완화한다. 하지만 잠재적인 사건과 그 사건이 일어날 가능성, 사건이 일어난 경우 조직에 끼치는 영향애 대해 여전히 자유롭게 의견을 모아야 정확한 완화 전략을 구사할 수 있다.
  • 주경로만 테스트하고 싶진 않겠지만, 주 경로 테스트는 좋은 출발점이다. 주경로를 파악한 후 나쁜 결과 뿐만 아니라 일어날 가능성이 높은 사례인 더 높은 위험 시나리오를 정의할 수 있다.
  • 잠재적인 영향과 위험 영역을 프로그래머들과 다른 팀 멤버의 논의로 적절한 테스트 활동을 계획할 수있다.
  • 또 다른 위험이 있다. 상세한 테스트 케이스를 작성하는 데 너무 몰입해서 나무만 보다가 숲을 보지 못하는 경우가있다. 즉 상관없는 부분을 입증하려고 상세한내용에 집중하는 동안 큰그림을 잊어버릴 수가 있다.

… 각 개별 스토리가 시스템에 다른 부분에 어떤 영향을 주는지를 항상 고려하라.. 스토리 간의 차이를 찾아내기 위해 탐색적 테스트를 사용하자. 최종 목적과 큰 그림을 기억하자

  • 각 이터레이션을 완료한 후에 사전에 더 상세한 내용이 도움이 될 것인지를 평가하는 시간을 갖자
  • 리사의 팀은 코드를 작성하기 전에 고 수준 스토리 테스트를 작성하고 일단 코드 작성을 시작했을 대에는 자세한 테스트케이스를 작성하고 난 다음, 팀에게 더 자세한 정보를 제공하고 필요한 조정에 도움을 주기위해 해당 코드가 제공되는 대로 탐색적 테스트를 수행하는 것이 최선이라는 것을 알았다.

테스트 용이성과 자동화

  • 테스트를 중심으로 일한다는 것은 모두가 테스트를 더 쉽게 하기 위해 코드를 설계하는 최선의 방법에 관해 생각한다는 의미다. 2사분면의 비즈니스 중심 테스트는 자동화된 테스트다 이들 테스트는 이해를 명확히 하고 실행을 쉽게 해주며 빠른 피드백을 제공하는데 필요하다.
  • 애자일 팀은 개발을 이끌어 내는 비즈니스 중심 테스트를 작성하고 자동화하는 프로세스를 찾아야 한다.

9장. 팀을 지원하는 비즈니스 중심 테스트를 위한 툴킷

비즈니스 중심 도구 전략 소개

(리사의 이야기)
.. 시행착오를 통해 우리는 원하는 동작 / 원하지 않는 동작의 몇 가지 예와 결합한 고수준 테스트가 프로그래머들이 어떤 코드를 작성해야 할 것인지를 알려주는 최선의 방법이라는 것을 깨달았다.

사례와 요구사항을 이끌어내는 도구들

  • 스토리는 원하는 동작에 관한 장기적인 대화에 대한 유일한 출발점이다.
  • 우리는 마이크 콘이 (2004)에서 다음처럼 묘사한 사용자 스토리에 대한 “역할, 기능, 비즈니스 가치” 패턴을 좋아한다.
    • (역할)로써 (비즈니스 가치)를 얻기위해 (기능)을 원한다.
  • 사례를 통해 원하는 동작을 설명하도록 도와주고 잠재적인 구현 사항들과 파급효과를 브레인스토밍하며 요구사항을 테스트로 전환하는 도구에는 다음과 같은 것들이 있다.
    • 체크리스트
    • 마인드 맵
    • 스프레드시트
    • 모형
    • 흐름도
    • 소프트웨어 기반도구

사례에 기반을 둔 테스트 자동화를 위한 도구

GUI와 API 하부에서 테스트하는 도구

  • 단위 수준 테스트 도구
    • JUnit
    • NUnit
    • BDD 도구: 자바플랫폼용 esayb와 JBehave, .Net용 NBeahave와 NSpec, Ruby용 RSpec이 있다.

행위주도개발
… 우리가 새로운 애자일 팀에게 받은 가장 흔한 질문 두 가지는 “문서는 어떻게 해야하나요?”라는 질문과 “두 주간의 이터레이션에서 개발을 계속하면서 어떻게 자동화를 테스트할 수 있나요?”라는 질문이었다. 고객과 개발팀 모두가 이해하는 특정 도메인 언어를 사용해 실행가능한 문서를 만들 수 있는 easyb와 같은 도구들이 그 질문에 대답이 될 것이다.

  • API계층 기능 테스트 도구
    • Fit와 FitNesse
    • 웹서비스 테스트 : Ruby Test::Unit, soapUI
  • GUI를 테스트하는 도구
    • 레코드/리플레이 도구
    • 애자일 오픈 소스 테스트 도구
      • Ruby / Watir
      • Selenium
      • Canoo WebTest
  • 자가 제작 테스트 자동화 도구

테스트 작성 전략

  • 테스트 도구는 테스트의 명세를 아주 쉽제 작성할 수 있게 해주지만 적절한 시간에 올바른 테스트의 명세를 작성하는 지는 여러분에게 달려있다.

테스트를 점진적으로 구축하라

  • 프로그래머가 코드 작성을 시작할 대상을 알 수 있도록 고수준 인수 테스트를 정의한 다음 스토리의 나머지를 정교화 할 수 있다.
  • 가장 확실한 유스케이스는 동작이 우선임을 기억하자. 단순하게 작성하고 해당 코드를 보여주는 주경로 테스트 자동화는 가장 필요한 기본적인 작업을 해낸다.
  • 각 테스트는 하나의 비즈니스 규칙이나 조건에 국한하도록 하라
  • 우리가 권한 얇은 조각이나 강철 쓰레드 패턴을 따른다면 테스트의 첫 번째 집합은 얇은 조각 전체를 입증해야한다. 자동화된 테스트를 통과하면 이들 테스트를 회귀 수트에 추가해 주기적인 빌드 프로세스에서 실행한다.

계속해서 테스트를 통과하도록 유지하라

  • 테스트 통과 후에도 해당 테스트는 요구사항이 변경되지 않는 한 실패하지 않아야 한다. 실패가 일어난다면 그 테스트는 해당 코드가 고쳐지기 전에 업데이트되어야 한다.

적절한 테스트 디자인 패턴 사용하기

  • 테스트를 설계하기 전에 필요한 테스트를 식별해야한다. 피에르 베라겐(Pierre Veragen)은 테스트 발생 패턴(test genesis patterns)이라는 용어를 만들어 테스트에 관해 생각하는 데 도움을 주는 패턴들을 기록했다. 사례와 유스케이스가 테스트 발생 패턴에 반영되었다.
    • 빌드/작동/검사 (설정/실행/검증)
    • 시간기반, 활동, 이벤트 패턴 : 시간기반 절차 패턴은 종종 더 나은 비즈니스 상황을 반영한다.
    • 더 배울 것
      • 비즈니스 로직과 알고리즘은 사용자 인터페이스나 배치 스케줄링 프로세스를 통하지 않고도 테스트 픽스쳐로 액세스할 수 있어야 한다. 이것은 테스트 주도 개발을 가능하게 하고 테스트 가능한 아키텍처를 만들어낸다.

(참고) Simple Rules to Live By for Automating Tests (from “More Agile Tesitng”)

Simple Rules to Live By for Automating Tests

테스트 용이성

코드 설계와 테스트 설계

  • 테스트 가능한 코드 설계 없이 테스트를 작성할 수 없고, 요구사항을 명확하게 전달해서 시스템 아키텍쳐와 호환이 되도록 잘 설계된 테스트 없이 코드를 작성할 수 없다.

자동화 vs. 수작업 2사분면 테스트

  • 초기에 시나리오를 프로그래머들과 공유했다면 수작업 테스트 시나리오로 프로그래밍을 이끌어 낼 수도 있다.
  • 전체 시나리오나 스프링보드에 관해 일부 자동화가 가능할 수도 있지만, 지능적인 인간이 이들 테스트를 자세히 처리하는 탐색적 테스트 세션으로 생각하는 편이 좋다.
  • 간단한 접근 방법으로 시작해서 어떻게 동작하는지를 살펴본 뒤 그 방법으로 만들어보자. 중요한 것은 제품을 개발할 때 팀을 지원하는 비즈니스 중심 테스트 작성을 시작하는 것이다.

테스트 관리

  • 테스트를 자동화 한다면, 아직은 실행 가능하지 않더라도 자동화 프레임워크에서 이들 테스트를 나타내는 것이 좋다. 모든 개발 팀원이 모든 테스트에 접근이 가능하도록 하고 모든 고객이 이해할 수 있는 방안을 원한다. 심지어 자동화 되지 않는 것 조차도 그런 방안을 필요로 한다.
  • 소스 코드 제어에 테스트를 포함시켜야 어떤 버전의 테스트가 어떤 버전의 코드와 진행되는지를 추적할수 있다.

10장. 제품을 평가하는 비즈니스 중심 테스트

소개

  • 이제는 일부 모호하거나 흥미로운 버그들을 찾아내는 일만 남았다.
  • 제품을 평가하는 비즈니스 중심 테스트는 사람의 지적 능력과 경험, 본능에 의지하기 때문에 자동화하기는 어렵다. 하지만 자동화된 도구들을 사용하면 테스트 데이터 설정처럼 3사분면 테스트의 여러 측면을 도와 줄 수 있다.
  • 1사분면과 2사분면을 자동화하지 않았다면, 3사분면 테스트를 해볼 시간은 갖지 못할 것이다.
  • 제품을 평가하거나 비평하는 일은 테스트 아래에서 시스템을 조정하고 최종 사용자의 실제 경험을 재 창조하는 일에 관한 것이다.

데모

  • 이터레이션 데모의 마지막에는 비즈니스 사용자와 도메인 전문가에게 이터레이션에서 나온 결과물이 무엇인지 확인하고 우선순위를 변경할 기회를 제공한다.
  • 애자일 개발의 점진적이고 반복적인 본질은 여러분에게 제품을 만들어내고 출시하기 전에 비즈니스 가치를 보여줄 기회를 제공한다.

시나리오 테스팅

  • 비즈니스 사용자는 최종 사용자 행동을 모방할 수 있는 타당한 시나리오와 워크플로를 정의하는 데 도움을 줄 수 있다.
  • 팀이 비즈니스와 사용자 필요를 이해하는데 도움을 주는 한 가지 좋은 기법이 한스 부왈다(Hans Buwalda)가 만든 용어인 “드라마 테스트”다.
    • TV드라마가 행동과 감정을 다소 과장하고 일련의 사건을 빠르게 압축하는 방식과 유사하게 실생활에 기반을 둔 시나리오를 과정하는 것이다. 다음과 같은 질문을 해보라. “일어날 수 있는 최악의 일은 무엇이며 그런일이 어떻게 일어났을까?”
  • 테스터로서 우리는 종종 테스트 데이터를 만들지만 이들은 대게 단순해서 결과를 쉽게 검사할 수 있다. 다른 시나리오를 테스트할 때 데이터와 흐름 모두는 현실적이어야 한다.

탐색적 테스팅

  • 탐색적 테스팅은 애자일 세계에서 테스팅에 대한 중요한 접근 방법이다. 이것은 조사 도구로서 스토리 테스트와 자동화된 희귀 수트에 중요한 보조 수단이다.

탐색적 테스팅이란
….볼턴과 제임스 바흐는 탐색적 테스팅을 “테스트 설계와 테스트 실행, 학습을 동시에 수행하는 것”이라고 정의했다. 카너는 탐색적 테스팅을 “개발 테스터의 자유와 책임을 강조하는 테스팅 방식이며 프로젝트 동안 동시에 계속하는 활동으로써 학습과 테스트 설계, 테스트 실행, 테스트 결과 해석을 처리함으로써 일의 가치를 지속적으로 최적화 하는 것”이라고 더 명시적으로 정의했다. …. 테스트 활동을 탐색적으로 만드는 것은 무엇일까? 해답은 테스터의 인지적 참여에 있다. 즉 테스터가 지속적으로 바뀌는 상황에 반응하는 방법에 달렸다. ….. 사람은 누가 알려주지 않아도 상황을 인식하는 놀라운 능력이 있다. 하지만 그로 인해 때로는 산만해지고 샛길로 빠지기도 한다. 그러나 우리는 새로운 정보를 배우고 놀랄 만큼 빠르게 적용해 그 정보의 원인과 효과를 조사할 수 있다.

  • 탐색적 테스팅은 기능의 어떤 측면을 탐색할 것인지를 선언함으로 시작한다. 여기서는 비판적 사고와 결과에 대한 해석, 기대 시스템이나 비슷한 시스템과의 결과 비교를 필요로 한다.

기술: 탐색적 테스팅과 정보 평가

각 개발주기 초기에 다음의 내용을 기반으로 탐색적 테스팅을 고려해보자.
* 위험(분석) : 여러번과 고객/ 사용자가 생각하는 중요한 부분이 사람들을 불행하게 만들 잠재적인 문제가 될 수 있거나 잘못을 범할 수 있다.
* 소프트웨어가 어떻게 동작할지에 대한 모델
* 개발팀이 알려주는 것
* 가장 중요한 것 : 테스트하면서 여러분이 배우고 (보고 관찰하는) 것. 애자일 팀에서 테스터의 업무 중 가장 큰 부분은 제품과 팀, 고객에 관해 끊임없이 배우는 것이다. 배우면서 고객의 필요나 팀이 범할 지도 모르는 공통의 실수, 제품의 좋은 특징이나 나쁜 특징 같은 것에 기반을 두고 신속하게 확인해야한다.

탐색적 테스팅의 가장 중요한 측면은 테스트를 하는 동안 두뇌를 활발히 회전시키면서 재미있거나 예상치 못한 것, 새로운 것을 찾는 것으로 이는 자동화 테스트가 놓치는 것들이다.

세션 기반 테스팅

  • 세션 기반 테스팅은 책임 추적성과 탐색적 테스팅을 합쳐 놓은 것이다.
  • 세션 기반 테스팅에서 미션이나 차터를 만든 뒤 세션에 시간대역을 정해 중요한 것에 집중할 수 있다.
  • 세션은 테스트 설계와 실행, 버그조사와 보고, 세션 설정의 세 가지 종류의 작업으로 나뉜다.

자동화와 탐색적 테스팅

  • 좋은 테스터란
    • 체계적이지만 일관성이 없는 특이한 조각들을 찾아내서 계속 “냄새”를 맡는다.
    • 여러가지 조언 장치(문제를 인식하는 원칙이나 메커니즘)을 사용해 문제를 인식하도록 배운다.
    • 주제나 역할 또는 사명 선언을 선택해 테스트에 집중한다.
    • 세션과 짧은 일탈을 시간 대역으로 제한한다.
    • 전문가나 초보자가 하는 일에 생각해본다.
    • 도메인 전문가와 함께 탐구한다.
    • 유사 애플리케이션이나 경쟁 애플리케이션을 검토한다.

사용성 테스팅

  • 두가지 유형의 사용성 테스팅이 있다.
    • 프로그래밍에 도움을 주는 와이어 프레임 같은 도구를 사용해 사용자 경험 전문가들이 사전에 수행한 테스팅이다. 이는 2사분면 테스트에 속한다.
    • 제품을 평가하는 테스팅은 페르소나와 같은 도구와 직관을 이용해 최종 사용자가 생각하는 제품을 살펴보는 데 도움을 얻는다.

사용자 요구와 페르소나 테스팅

  • 페르소나를 사용하는 접근 방법 중 하나는 다른 경험 수준과 요구를 대표하는 몇 명의 다른 사용자를 만들어 내는 것이다.

탐색

  • 탐색은 사용성 테스팅의 또 다른 측면이다. 탐색은 링크를 테스트하고 탭 순서가 합리적인지를 확인하는 중요한 부분이다.

경쟁 제품 확인

  • 애플리케이션의 사용성을 평가할 때에 유사한 다흔 애플리케이션을 고려해보라

GUI 뒷단

API 테스팅

웹서비스

문서화

탐색적 테스팅에 도움을 주는 도구

  • 테스트 설정 도구
  • 테스트데이터 생성 도구
  • 모니터링 도구
  • 시뮬레이터
  • 애뮬레이터

11장. 제품을 평가하는 기술 중심 테스트

비기능은 무엇인가

  • 제품을 평가하는 기술 측면의 테스트는 기능적 요구사항 보다 비기능 요구사항과 더 관련이 있다.
  • 비기능 요구사항은 설정이슈, 보안, 성능, 메모리 관리, ~성(안정성, 상호운용성 등), 복구, 심지어 데이터 변환까지 포함한다.
  • 프로젝트를 계획할 때 이 부분의 위험에 대해서 생각하고, 테스트에 포함시키고, 테스팅하는 데 필요한 도구와 지원을 프로젝트 계획에 포함시켜야 한다.
  • 도구는 4사분면 테스팅에 성공에 필수적이다.

~성 테스트

보안

유지보수성

  • 전통적인 프로젝트의 유지보수성은 전체 코드 검토나 검사를 이용해 수행한다. 애자일 팀은 지속적인 코드 검토인 짝 프로그래밍을 이용한다.
  • 우리는 애플리케이션 코드, 테스트 프레임워크, 자체적인 테스트에서 개발 표준과 가이드라인을 따르도록 했다.
  • GUI개발에 대한 표준 역시 테스터가 어떤 동작이 옳고 그른지 알 수 있기 때문에 애플리케이션의 테스트와 유지 보수를 더욱 쉽게 해준다.

상호운용성

  • 상호운용성은 다양한 시스템과 조직의 함께 작업하고 정보를 공유하는 역량과 관련있다.

호환성

신뢰성

  • 소프트웨어의 신뢰성은 일반적인 상황 뿐아니라 예상치 못한 상황에서도 시스템의 기능이 수행되고 유지되는 능력과 관련이 있다.
    • 첫 실패까지의 평균시간 (mean time to failure)
    • 실패 사이의 평균시간 (mean time between failures)
  • 인수테스트는 “기능 X는 24시간 주기로 최소 3일 동안 10,000번 수행되어야 한다”와 같이 상세할 수 있다.
    • 고객 팀에게 가능한 형태의 안정성 기준을 요구하자

설치 용이성

~ 성 요약

  • 어떤 ~ 성 테스트가 필요하든지 점증적인 접근방법을 이용하자. 특정 품질 영역의 고객 팀 목표에 대한 요구사항과 예제를 이끌어내는 것으로 시작하자.

부하유형테스트

확장성

  • 확장성 테스팅은 애플리케이션에 더 많은 사용자가 추가되었을 때에도 여전히 신뢰할 수 있는지를 검증하는 테스팅이다.

성능과 부하테스팅

  • 성능 테스팅은 시스템의 병목 현상을 식별하거나 이후 테스팅의 기준선을 수립하기 위해 사용된다.
  • 부하 테스팅은 동시간에 시스템에 점점 더 많은 사용자가 접근할 때 시스템 동작을 평가한다. 스트레스 테스팅은 예상치보다 높은 부하를 이용해 애플리케이션의 견고성을 평가한다.

성능테스팅과 부하 테스팅 도구

  • 단위 테스트 수준에서는 JUnitPerf, httperf
  • 오픈 소스 도구로는 Apache JMeter, The Grinder, Pounder, ftptt, OpenWebLoad
  • 상용도구로는 NeoLoad, WebLoad, eValid LoadTest, LoadRunner, SOATest
  • JProfiler
  • JConsole
  • PerfMon
  • NetScout

(참고) “More Agile Testing” 에서 참고할 만한 그림들

1. Levels of detail (precision) for planning

Levels of detail (precision) for planning

2. Levels of precision of planning at the team level

Levels of precision of planning at the team level

3. The 7 Product Dimensions

The 7 Product Dimensions

4. Automation pyramid

Automation pyramid

5. Test automation pyramid with JavaScript complexities

Test automation pyramid with JavaScript complexities

Advertisements

답글 남기기

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

WordPress.com 로고

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

Twitter 사진

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

Facebook 사진

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

Google+ photo

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

%s에 연결하는 중