탐색적 테스팅 – 투어 정리

탐색적 테스팅 – 투어 정리

구글은 소프트웨어를 어떻게 테스트하는가의 부록의 내용을 정리한 것으로, Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design 에 나온 투어에 대한 정리이다.

1. 쇼핑 투어

(설명) 쇼핑이란 많은 사람들의 기분전환거리이며, 구입할 만한 새로운 제품을 발견하는 곳으로 떠나는 즐거운 여행이다. 특정 도시에서의 쇼핑은 그 주된 매력 만큼 사치스러운 것이다.
* 소프트웨어에서 상업적이라는 것이 이상한 것이 아니며, 많은 프로그램이 돈을 내고 구입해야 한다. 이것은 특히 추가 컨텐트를 다운로드할 수 있게 하는 요즘에는 더욱 더 그렇다. 쇼핑 투어에는 사용자가 원활하고 효율적으로 제품을 구매할 수 있는지를 검사하기 위해 테스트 중인 소프트웨어에 사용자들을 초대한다.
* (ex) 구매/결제 관련 부분들에 대한 테스트..

2. 학생 투어

(설명) 많은 학생들이 외부에서 공부하는 기회를 통해 발전하고자 하며, 지역 자원을 이용하고 새로운 목표를 위해 그들의 전문지식 분야를 늘릴 것이다. 이러한 여행은 도서관, 자료실, 박물관 같이 여행자가 이용 가능한 모든 자원을 다 커버한다.
* 소프트웨어에서는 많은 사람들이 새로운 기술을 내놓고, 특정 주제에 대한 아해를 늘리는 연구에 이런 기술들을 사용한다. 이러한 투어는 단지 사용자가 소프트웨어를 사용하고, 정보를 구성하고 모으는 데에 도움이 되는 소프트웨어 내의 모든 기능을 테스트하고 이용할 수 있게 한다.
* (ex) 데이터를 잘 수집하고 구성하는가에 대한 테스트..

3. 국제 전화 투어

(설명) 여행 중에 집에다 전화를 거는 경험은 누구나 있을 것이다. 국제 전화 교환수와 환율, 신용카드 등에 대한 고려는 흥미로운 것들이다.
* 소프트웨어에서 사용자는 같은 기능(집에 있는 사람에게 전화)을 다른 플랫폼, 다른 권한 레벨, 다른 설정에서 다뤄 보길 원한다. 이 투어는 어디서 사용하든 원활하고 믿을 만한 경험을 보장하는 것에 초점을 맞춘다.
* (ex) 다양한 사용자 환경에서의 테스트, 다양한 권한에 대한 테스트, 다양한 네트워크 환경에서의 테스트 등

4. 랜드마크 투어

(설명) 프로세스는 간단하다. 가고자 하는 방향에서 랜드마크(나무, 바위, 절벽 등)를 찾을 나침판을 사용해서 랜드마크를 향해 나아가고, 찾고 나면 다음 랜드마크를 찾아 나가는 것을 계속하는 것이다. 모든 랜드마크가 같은 방향을 향하는 한, 산 속에서 길을 잃어도 찾아갈 수 있을 것이다.
* 탐색적 테스팅을 하는 사람들에게 랜드마크 투어는 숲을 관통하듯이 소프트웨어에 랜드마크를 설정하고 그 방향으로 나간다는 점에서 비슷하다고 볼 수 있다.
* (예) 주요 랜드마크(기능, 컴포넌트)를 중점에 두고 전체를 관통하면서 테스트를 진행하기 .. 정도

5. 올빼미 투어

(설명) 얼머나 멀리 갈 수 있는가 올빼미 투어는 관광지에서 다음 관광지로 조금만쉬거나, 아예 쉬지 않고 여행하는 것을 말한다. 이러한 투어는 체력을 테스트한다. 얼마나 버틸수 있는가? 모든 올빼미 여행자들이 살아남을 수 있을까?
* 소프트웨어서 이 투어는 테스트 중인 제품이 얼마나 긴 시간 동안 제품의 기능을 사용할 수 있는지를 알아본다. 핵심은 어느 것도 멈춰지지 않고 하나의 긴 사용자 경험을 계속하는 것이다. 이 투어는 오랜 시간 사용할 때만 발견되는 버그를 찾아 낼 수 있게 해준다.
* (예) 성능, 스트레스, 지속성 테스트..

6. 장인 투어

(설명) 어떤 이들이 즐거운 여행을 하는 동안, 어떤 이들은 비즈니스를 위해 여행한다. 장인 투어는 여행자들이 새로운 목적지에서 얼마나 쉽게 비즈니스를 수행할 수 있는가를 측정한다. 그곳에 로컬 벤더가 있는가? 그곳에서 사업을 시작하려면 얼마나 번거로운 절차를 거쳐야하는가?
* 소프트웨어에서 이 투어는 얼마나 쉽게 사용자들이 테스트 중인 소프트웨어의 툴을 사용하 콘텐츠를 개발할 수 있는가를 살펴본다. 로컬 벤더와 번거로운 절차 대신 사용자는 소프트웨어가 애플리케이션에게 얼마나 많은 툴을 제공하고 얼마나 쉽게 콘텐츠를 가져오고 내보낼 수 있는지를 살펴본다.
* (예)컨텐츠를 만들고 생산하는 것에 대한 테스트

7. 나쁜 이웃 투어

(설명) 모든 도시에는 나쁜 이웃들과 우범 지역이 있어서 여행자들은 이러한 곳을 피해야한다.
* 소프트웨어에서 많은 버그를 내뱉는 부분을 나쁜 이웃이라고 한다.
* (예) 버그를 많이 있는 영역에 대한 집중 테스트.. (테스트를 진행하면서 영역이 정의될 수 있음)

8. 개인화 투어

(설명) 개인화 투어는 여행자가 그들의 여행에 대해서 많은 것을 선택할 수 있다는 것을 보여준다. 개인화의 대상은 새 선글라스, 렌트카, 가이드고용, 쇼핑 등 모든 것을 포함한다.
* 소프트웨어에서 사용자가 소프트웨어를 그들이 원하는 대로 커스트마이징할 수 있는 다양한 방법을 살펴보는 것이다.
* (예) 사용자 환경 세팅에 따른 테스트.

테스트 계획할 때 필요한 질문들 (번역)

 

테스트 계획할 때에 필요한 질문들 (The Inquiry Method for Test Planning)

>> 테스트 계획할 때에 필요한 질문들 (The Inquiry Method for Test Planning) 

 

 

애자일 테스팅 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

애자일 테스팅 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. 테스트 계획

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

다른 회사는 어떻게 QA, 테스팅을 하고 있을까? (Google, Facebook, Atlassian)

우리 회사에서의 QA와 테스팅은 어떤 모습이어야 하는지를 고민하면서, 도대체 다른 회사는 어떻게 테스팅을 하고 있을까에 대한 조사를 하면 도움일 될 것 같았다. 그래서 Google, Facebook, Atlassian의 사례를 찾아 간략하게 정리해본다.

google 1. Google

구글은 소프트웨어를 어떻게 테스팅하는가 책의 서문과 1장에 해당하는 내용 중 일부를 정리한 내용이다.

Google의 Tester

구글의 고참 디렉터이며, 테스팅 계엘의 최상급자인 Patric Copeland는 책의 서문에서 이렇게 말하고 있다.

구글은 전산학과 코딩 기술을 존중한다. 테스터가 그 클럽에 동참하려면 훌륭한 전산지식과 절묘한 코딩 기술을 갖추어야 한다.

우리나라에서 테스터로 업무를 시작한 사람들에게 패트릭이 말한 훌륭한 전산 지식과 절묘한 코딩지식을 갖추라는 조언은 숙응은 되지만, 쉽게 그 목적을 달성해내기는 쉽지 않다. 대부분의 테스팅의 업무란, 사용자에게 최상의 경험을 주기위해, 앞서 경험을 해주는 대리자의 입장이 많았기 때문인 것 같다. 경험을 미리 해주는 테스터에게는 엄청난 전산 지식도, 절묘한 코딩 스킬이 필요한 것은 아니기 때문이다.

패트릭이 주는 첫 번째 조언은 “테스터의 수를 많이 두지 말라“는 것이다. 래리 페이지(Larry Page)도 “부족함이 명석함을 만든다”고 하였다. 아웃소싱 리소스 투입을 통해서 대체 경험자의 투입의 수를 늘려, 배포 전에 이슈를 최대한 많이 잡아내려는 시도는 어쩌면 명석하지 않은 솔루션일지도 모르겠다.

구글에서 테스터의 일은 다른 엔지니어들이 하지 않는 더 좋은 테스트를 하는 사람이다. 테스터의 실제 업무는 생산성을 향상 시키는 일이고, 느슨한 개발로 인한 재작업이 늘어나는 것을 예방하는 활동이다. 구글에서는 개발자가 자신의 품질을 스스로 책임을 지기때문에 적은 수의 전문 테스터 만으로도 테스팅을 해낼 수 있다고 한다. 품질 활동의 초점은 결함을 찾는 것보다는 예방에 맞추어져 있다

image1

지금은 구글에 있지 않지만, 이 책의 저자 중 한 명인 제임스 휘태커(James Whittaker)는 이렇게 언급하고 있다.

품질과 테스트가 동치는 아니다. 하지만 품질을 이루기 위해서는 개발과 테스팅을 믹서기에 함께 넣고 구분되지 않을 정도로 섞어야 한다.

QA부서나 테스팅부서가 따로 있는 것이 주는 가장 큰 맹점이자 악효과가 바로 이것이라고 생각된다. 개발자는 개발을, 테스터는 테스트를 하는 것으로 분리하는 순간에 많은 문제가 발생힌다. 간단한 테스트로 수정하고 고쳐질 수 있는 부분이, 여런 단계와 컴포넌트 및 시스템의 통합을 거쳐 테스터가 설정한 테스트 케이스를 실행하는 순간에 발생되고 이로 인한 재작업의 비용과 시간의 손실은 너무나도 크다.

개발자가 품질을 책임진다는 말, 개발과 테스트를 분리하지 말아야한다는 말은 QA와 테스팅을 업무로 삼고 있는 입장에서는 job security와도 연관되어있는 무서운 말일 수도 있다. 하지만 배포가 임박하여 수없이 쏟아지는 버그를 정신없이 리포팅하는 것이 테스팅을 잘 하고 있음을 보여주는 것은 절대 아닌 것 같다.

Software Engineer(SWE), Software Engineer in Test(SET), Test Engineer(TE)

구글은 SWE, SET, TE로 역할이 구분되어 있다. 간략히 살펴보면 다음과 같다.

  • SWE는 개발자이다. fault-tolerant 설계, TDD, unit 테스트를 수행한다.
  • SET는 Testability 및 범용 테스트 인프라에 중점을 두며, 테스트 기능을 개발하는 개발자이다. 각 기능의 품질에 초점을 두고 개발자의 테스트를 돕는다. 모든 단계에서 테스트를 가능케 하는 사람들로 100% 코딩을 하는 역할이며, 기능 코드 작성을 하는 훌륭한 테스터이다.
  • TE는 반은 사용자 입장, 반은 개발자 입장에서 테스트한다. 엔지니어이며, 사용자인 개발자이다. 개발자가 존중하는 기술과 개발자가 알아야하는 사용자 측면의 관심영역을 조합한 직책이다. 제품전문가, 품질 조언자, 리스크 분석가이다.

조직 구조

조직 측면에서 보면 ‘생산성혁신팀’의 이름으로 독립되어 있지만, 전략적으로 테스터는 상품화팀에 배치(할당)된다. 한 제품에 대해 테스터는 약 18개월 정도 일하며, 원하면 아무 문제 없이 다른 팀으로 옮길 수 있다. 이렇게 독립 중앙 조직으로 할당되는 방식을 통해 좋은 아이디어와 모범 사례들이 퍼져나가게 한다.

테스트 유형

구글에서는 흔히 구분하는 코드 테스트, 통합 테스트, 시스템 테스트로 구분하는 대신 범위를 강조하는 방식으로 테스트 유형을 구분한다.

  • 소형 테스트
  • 중형 테스트
  • 대형/초대형 테스트
소형 테스트 중형 테스트 대형(초대형) 테스트
소형테스트 중형테스트 대형테스트

소형 테스트는 코드가 제대로 잘동하는지 확인한다. SWE에 의해 대부분 테스트는 자동화 된다.깨끗한 코드, 잘 정의된 인터페이스가 필요하다. 에러간 독립성을 보장하면서 테스트가 가능하다.하지만 서브시스템을 mock으로 만들기가 어려우며, mock/fake가 실제와 다를 수 있다는 단점은 있다.
중형 테스트는 이웃하는 기능(2-3개 정도의 인터렉션이 발생하는)이 제대로 기능하는지를 확인한다. 대형 테스트에 비해 자주/쉽게 수행가능하지만, 외부의존성으로 비결정적일 수 있다. 주로 외부 시스템의 행동을 설명한다.

대형 테스트는 3개 이상의 기능의 인터렉션으로 구성되며, 사용자 시나리오를 중심으로 확인한다.궁극적으로 중요한 내용의 테스트이지만, 외부의존성으로 인해 비결정적일 가능성도 가장 높다. 테스트 실패의 원인을 찾기 어렵고 데이터 설정에도 시간이 소요되어 비 실용적일 수 있다.

Testing type

이렇게 테스트 용어를 구분한 것은 별도의 개념을 만들기 위함은 아니다. 구글 테스터가 테스트하고자 하는 대상과 테스트 범위에 대해 공통의 용어를 사용하게 하기 위함이다. 자동/수동 테스트를 혼합하여 이 세가지 크기의 테스트에 적용하며, 자동화될 수 있고 사람의 지식과 직관을 필요로 하지 않는 문제라면 반드시 자동화한다.

코딩 프로세스

사레를 조사하면서, 어떻게 생각하면 당연할 수 있는 것에 놀랐다.

조사한 회사 모두 코드 리뷰를 하고 있으며, 코드 리뷰 시스템에는 기능에 대한 코드 뿐 아니라 해당 코드에 대한 테스트도 함께 포함된다는 것이다. 아래 간략히 그린 그림처럼 코드 리뷰시에 변경 코드와 해당 코드에 대한 테스트를 포함한다.

codingprocess_google

테스트 개선

Patric Copeland는 테스트 인증 프로그램이라는 방식을 사용하여 각 조직의 테스트 스킬과 성숙도를 높여갔다고 한다.

  • 1단계 : 준비가 된 기본상태.
  • 2단계 : 정책 세워지고 점진적 커버리지 개선이 이루어 짐.
  • 3단계 : 새로 작성된 코드를 테스트 함.
  • 4단계 : 레거시 코드의 리팩토링으로 테스트 수행력 올림.
  • 5단계 : 전체 커버리지 올려나가고, 모든 결함에 대한 테스트를 작성하며, 정적/동 테스트 툴을 사용함.

나에게 던지는 질문들

이를 정리하면서 나에게 던지는 질문을 정리해본다.

  • 코딩 능력을 어떻게 기를 수 있나? 지금이라도 코딩능력을 가져야하는 것일까?
  • 현재 개발조직의 테스트는 어떠한가?
  • 예방활동으로 하는 것이 있나?
  • 현재의 업무 배정이 적절한 것인가? (현재는 독립된 조직으로 남아 테스팅을 해준다는 느낌이 여전히 강하다.)
  • 대부분 우리가 하는 테스트는 구글의 테스트 유형으로 보면 대형테스트인데, 외부 의존성으로 인한 비결정적 문제를 어떻게 해결 할 수 있는걸까?
  • 자동화는 옵션이 아니라 필수이다. 이를 위해 어떤 전략을 가져가야할까?
  • 버그는 쉽게 등록되어야하고, 모두가 볼 수 있게 해야하는데.. 우리는 어떠한가?
  • 유지관리 모드 테스트도 필요하다. 이는 검출의 목적이 아니라 품질 모니터링의 관점. 이 부분에 자동화를 엮으면 좋다. 이런 유형의 자동화가 각 서비스의 핵심 품질을 고려하여 수행되고있는가?

참조

facebook 2. Facebook

Facebook의 QA에 대한 내용은 quora에 facebook을 재직했던 엔지니어가 답변을 적은 것을 정리했다. 2-3년 전의 내용이며, 현재 Facebook의 QA상황과는 다를 수 있지만 충분히 참고할만 한 것 같다.

Facebook의 QA

별도로 독립된 QA Team은 없다. ‘Test engineering team’이 있었으나 이 팀은 Test infrastructure를 구축하고 유지보수 하는 업무이다. 앞서 살펴본 회사들과 마찬가지로 개발자들이 직접 테스트를 작성하고 실행 및 유지보수를 한다. 개인 또는 팀이 하는 테스트보다 도그푸딩(dog-fooding)을 한다. 출시 전에 일주일 정도는 임직원들이 미리 변경을 경험하고 버그를 올릴 수 있으며, 수동 테스트 보다 자동화 테스트를 한다. 또한 릴리즈 24시간 전에 beta facebook에 미리 반영하여, 이에 대한 버그도 리포트 받고 있으며, 페이스북 베타테스터 프로그램도 운영하고 있다.

실제로, Facebook 채용 사이트를 살펴봐도 Google과는 달리 Test 및 QA 엔지니어가 별도로 나와있지 않은 것을 보면, 현재도 QA나 테스팅 엔지니어로 구분된 역할은 Facebook에 없는 것 같다.

테스트 유형

Facebook의 테스트는 다음과 같은 유형으로 정리된다.

  • PHP 코드 테스트
  • 브라우져 기반 테스트
  • UI기반 테스트 (Site behavior 테스트)
  • Javascript 테스트
  • 백본 테스트

PHP 코드 테스트는 PHPUnit 테스트 프레임워크를 사용하여 수행한다. 코드 베이스에 대해서 Unit 테스트는 상시 수행한다. 코드 커버리지 데이터는 수행해야할 테스트를 파악하기 위해 사용되며, 테스트결과는 코드리뷰 툴에 포함된다. 코드 리뷰 툴에는 변경 대상인 PHP 또는 Javascript뿐 아니라 이에 대한 테스트 결과도 포함되어 있다. 브라우져 기반 테스트는 Watir 프레임워크를 이용한다. 여기서는 개인정보 부분에 중점을 두고 테스트한다(예를 들어, ‘X가 어떤 항목 Y를 작성할 경우, Z에서 보여져야(혹은 안보여져야) 한다’ 와 같은 시나리오). 이와 같은 부분은 facebook에서 매우 중요한 부분(critical factor)이기에, PHP 코드 테스트에도 포함되어 있지만 중복으로 테스트를 수행한다.

UI기반 테스트는 UI 흐름에 의한 테스트로, Watir로 자동화되어있다. 조금 더 최신의 글을 보면 Site behavior 테스트도 소개되고 있는데 이는 Webdriver를 이용하여 자동화를 만들어 수행한다. 사용자가 사용하는 것과 같게 시나리오를 구성하고, 비동기적(asyncronous) 테스트를 만든다. Javascript 테스트는 jsspec을 이용하여 테스트한다. StackShare에 공유된 것을 보면 현재는 jsspec이 아닌 Jest를 사용하는 것 같다.

백본 테스트는 서비스에 따라 다양한 테스트 프레임워크를 사용한다. Boost 테스트 클래스, JUnit 및 자체 C++로 구현된 테스트 프레임워크를 사용한다. CI와 빌드시스템에 통합되어 있어 지속적으로 테스트가 수행된다.
이렇게 QA/Test Engineer를 두지 않고 서비스를 배포 운영할 수 있는 데에는 무책임하게 사이트에 변경을 반영하는 것을 매우 부끄럽게 여기는 문화가 중요한 역할을 한다고 한다. 나쁜 코드에 Clowntown 태그를 붙여두어 개발자들이 실수를 반복하지 않도록 하기도 한다 (참고).

또한 견고한 Lint 프로세스가 있다. anit-pattern, 알려진 성능 킬러, bad style 등을 걸러내며 PHP, JS, CSS 등 모든 변경이 Lint를 거친다. 성능 지표를 얻는 프레임워크를 통해 성능 이슈를 걸러내고 있다.

자동화

최근의 내용을 보면, GTAC2104 – Never Send a Human to do a Machine’s Job: How Facebook uses bots to manage tests에서 Facebook의 테스트 자동화에 대한 이야기를 들을 수 있다. 규모가 커지면서 발생한 문제들을 테스트 자동화로 극복한 것을 설명하며 10000여개 정도의 테스트가 수행된다고 한다. 또한 사람의 개입을 최소화하면서 테스트를 지속적으로 수행하면서 실패 테스트 비율을 줄여나가고 있음을 말하고 있다.
facebook_automation

테스트 개선의 방향

테스트 프로세스의 튜닝은 엔지니어의 효율을 극대화하며, 테스트의 수행을 기다리는 시간을 최소화하는 방향으로 이뤄진다. Facebook에서는 테스트 속도를 어떻게 높일수 있을지, 중요한 부분에 대해 테스트하도록 테스트 대상을 어떻게 선정할지, 의사결정에 도움을 주기위해 테스트결과를 어떻게 통합할지를 고민하면서 계속적으로 테스팅 프로세스를 개선해 나간다.

나에게 던지는 질문

  • 사내 베타 테스트를 위해, 전체 서비스가 통합된 베타 환경이 있어야하는 건 아닌가?
  • 이제 코드리뷰가 필수 문화가 되어갈텐데, 우리도 변경 코드 뿐 아니라 테스트도 함께 포함되도록 해야하는 건 아닐까?

참조

Atlassian 3. Atlassian

Atlassian 블로그의 QA 시리즈 포스트를 요약하여 정리한다.

Atlassian의 QA

Atlassian의 테스팅 및 QA의 목표는 “높은 품질의 소프트웨어를 빠르게 배포하는 것”이다.

인력구성은 다음과 같다.

  • 개발 및 Team Lead (78)
  • 제품 관리자 (Product Manager) (10)
  • UX(UI) 디자이너 (6)
  • Tech writer(3)
  • QA 엔지니어(6)

QA는 역할은 테스터가 아니며, 실제 수동테스트를 포함한 모든 테스트는 개발자가 수행한다. Atlassian의 대표 제품인 JIRA에 대한 QA 프로세스는 아래와 같다.

JIRA QA Process

QA는 각 단계에서 피드백을 주는 데, Demo 단계에서는 실제 코드 레벨까지 보면서 미팅을 수행하기도 한다. Demo 이후 단계인 ‘개발자 테스트’는 옵션이다. 내가 속한 현실에서는 보통 앞 단계의 피드백은 주지 못한 채, 오픈 전 테스트는 필수로 하고 있는데 이런 방식은 조금 충격적이다. 테스팅을 하는 QA 엔지니어가 테스트 안해도 된다는 판단을 내려주는 것이다. 이는 단순한 판단이 아닌 전문가적인 판단이 필요한 영역이다. QA 엔지니어는 테스팅 의사 결정을 내리는데에 도움을 줄 수 있는 역량을 가지고 있어야 하는데, Atlassian에서는 아래와 같이 정리하고 있다.

  • 코딩 지식
  • 테스팅 스킬
  • 제품 지식
  • 유저 중심의 마인드 셋
  • 버그 히스토리에 대한 지식

이렇게 하는 이유는 최대한 빠른 릴리즈를 지원하기 위해 버그로 인한 재작업을 줄일 수 있도록 지원하고자 함이다. QA 엔지니어는 시니어 기술 스킬을 갖고 있는 전문가로, 시니어 개발자에게 조언(advice)를 할 수 있는 수준이어야 한다. 때문에 Altlassian에는 주니어 QA 엔지니어가 없다.

구글과 마찬가지로 QA와 테스팅의 목표는 결함 찾기가 아니라 예방에 초점을 맞추며, 화이트박스 테스트와 테스트 의사결정에 중점을 둔다. 결함 분석을 할 때에도 기존의 버그 DB를 뒤지면서 분석한다.

조직의 측면을 보면, Atlassian은 제품에 따라 서브팀이 있을 뿐, 직무에 따른 서브팀은 없다. 모든 QA는 실제로 다른 팀에 소속되어 일을 한다. 이 부분도 구글과 같다. ‘나는 테스팅을 한다’라는 목표보다는, 실제 제품팀에 속하여 ‘나는 제품을 만든다’는 느낌으로 업무를 수행한다.

초기 QA를 세팅한 Andrew Prentice은 다음에 기초하여 QA가 만들어졌음을 Introducing Atlassian QA 포스트에서 설명한다.

  1. 테스팅 능력은 태생적으로 갖게 되는 것이 아니다. 마법도 아니다. 배울 수 있고 가르칠 수 있는 기술(skill)이다.
  2. 개발자가 테스팅의 주체(Master)이다. 팀의 효율과 능력을 높이는 것 뿐 아니라 높은 품질의 소프트웨어를 만드는 것도 개발자의 몫이다.
  3. 테스팅은 결함을 찾을 뿐 아니라, 품질 문제의 근본 원인(root cause)를 해결하는 데에 초점을 둔다.
  4. 개발자가 좋은 테스터(good tester)가 되도록 돕는다. Quality Assurance를 하지 않는다. 다만 Quality Assistance를 한다.

나에게 던지는 질문들

  • 우리 조직의 목표는?
  • 전문적인 테스팅에 대한 의사결정을 내릴 수 있어야 하는 데, 이렇게 하려면 필요한 건 무엇일까?
  • 단지 버그 등록 – 수정 확인 – 재 테스트 후 이슈 종료에 급급한 상황은 아닌지 되물어 보게된다. 버그의 근본원인을 파악하려고 하는 노력이 필요한 것이 아닐까? (이것도 예방의 한 차원일 수 있겠다.)
  • 궁극적으로는 개발/제품팀에 실제로 소속되어 일하는 것이 필요한 것 아닌가?

참조

4. 비교

구분 google facebook Atlassian
QA 업무 분류 개발 개발 개발
별도 직무로 존재? SET – 범용 테스트 인프라에 중점을 두며, 테스트 기능을 개발하는 개발자임 별도 존재하지 않음 QA (주니어는 없고, 시니어만 있음)
TE – 엔지니어이며, 사용자인 개발자이다. 개발자가 존중하는 기술과 개발자가 알아야하는 사용자 측면의 관심영역을 조합한 직책임
조직 생산성혁신팀(Engineering Productivity)으로 독립 별도 팀 없음 별도 팀 없음
제품팀에 속하여(배정)되어 일함. (18개월 정도) 제품팀에 속하여 일함.
목표 및 초점 (모든 엔지니어가 테스트는 하지만) 더 좋은 테스트하기 높은 품질의 s/w를 빠르게 배포하는 것
근본원인 파악 및 예방에 중점 (동일) (동일)
테스팅이 혁신과 개발의 뒷덜미를 잡지않도록 함 엔지니어의 효율 극대화 및 테스트 수행 대기 최소화를 목표 테스팅 스킬을 가르쳐서 개발자가 Good Tester가 되도록 도움
단계별로 QA는 피드백을 주며 테스트 의사결정에 도움을 줌
테스트 유형 소형/중형/대형/초대형 테스트 PHP/Javascript 테스트 DEMO 진행 후 개발자테스트는 선택임
브라우져기반 핵심영역 테스트
UI / Site Behavior 테스트
백본 테스트
개발자의 테스트 정도 소형테스트의 주체 모든 테스트를 개발자가 실행 및 유지보수 모든 테스트를 개발자가 실행 및 유지보수
중형은 SET, (초)대형은 TE가 테스트 주체 개인/팀보다는 출시 전 도그푸딩 수동테스트도 개발자가 진행
코드 리뷰 리뷰 시스템에 변경 코드 및 테스트 결과도 포함 (동일) (동일)
자동화 사람의 직관이 필요하지 않은 모든 부분 자동화 테스트 유형별로 자동화 수행 (별도 언급 없음)
제품팀별로 알맞은 테스트 프레임워크를 이용하여 수행 PHPUnit, Jest, Watir, Webdriver 등 사용 (개발자테스트는 자동화로 수행되는 듯)
10000개 정도의 테스트 수행됨. (GTAC2104에서 발표)
프로세스 카나리아-개발-테스팅-(베타)-릴리즈 계획 – 개발 – 데모 – 개발자 테스팅 – 완료
사내 베타 단계 중 ‘테스팅’ 단계는 사내 임직원이 사용할 수 있는 수준으로 배포됨 릴리즈 일주일전에 pre-release 버전을 임직원 대상 배포 (별도 언급 없음 )
외부에 beta facebook안드로이드 베타 프로그램 운영 |