문서요약 - 테스트 데이터 관리 모범 관행 by Chace

제목: 테스트 데이터 관리 모범 관행(Test Data Management Best Practice)

저자: Stephanie Chace, Meridian Technologies, Inc.

문서유형: 기술 문서(총 14페이지), 2011년

 

테스팅 수행을 위해 필요한 테스트 데이터의 개발 및 관리에 대하여 기술한 자료 

---

좋은 테스트 데이터의 중요성

• 테스트 활동은 어떤 문제가 시스템 사용자에게 영향을 주기 전에 이를 발견하려는 목적을 가지고 현실의 시스템 사용을 흉내 내도록 설계됨. 테스트가 더 포괄적이고 현실적일수록 테스팅이 더 신뢰성 있게 잘못된 동작을 예측하고 수정할 기회를 줌
• 비즈니스 애플리케이션에서 생산 단계 실패(production failures)가 큰 손해를 가져 올 수 있음(예, 수입과 고객 신뢰의 상실). 또한 소프트웨어 실패가 규제 준수에 영향을 미치는 경우는 회사가 심각한 금전적 피해(벌금)나 소송에 시달릴 수도 있음
• 데이터가 오늘날 비즈니스 애플리케이션에 중심 역할을 하므로 테스트에서도 데이터가 유사하게 중요한 역할을 하도록 보장할 필요가 있음. 테스트 팀이 시스템 동작을 제대로 테스트하고 평가하기 위해서 실제 생산 데이터와 최대한 가까운 특징을 가진 데이터가 필요함
• 어떤 데이터 집합도 완벽하지 않으며, 많은 생산 단계 실패가 데이터에 있는 이상(anomalies)에 기인함. 이 이상이 테스트 데이터에 존재해야만 발견될 수 있다.
• 테스트 데이터의 품질이 높을수록 테스트 노력의 품질도 더 높아짐

좋은 테스트 데이터의 성질

• 좋은(높은 품질의) 테스트 데이터는 생산 데이터 집합의 특징을 반영해야 함. 하지만 단순히 생산 데이터의 복사본을 사용하는 것은 현실적이거나 비용 효과적인 선택이 아님
• 리스크와 데이터 보안 준수 조치가 생산 데이터의 사용을 점차 제한하고 있고, 더 나아가 생산 크기 데이터 집합의 사용은 데이터 저장 및 관리 비용을 상승시킴. 또한 대규모 데이터 집합을 가지고 작업하는 것이 테스트 노력의 발목을 잡는 경향이 있어서 전반적인 테스트 효율성을 감소시킬 수 있음
• 근본적으로 좋은 테스트 데이터는 아래 두 가지 성질로 서술될 수 있음:
  1) 생산(현실) 데이터의 전체 범위를 올바르게 반영한다.
  2) 테스팅 요구를 지원하기에 적절한 크기이다.

테스트 데이터 요구사항 개발

앞에서 왜 좋은 테스트 데이터가 테스트 노력의 중요한 한 부분인가가 설명되었고, 이제는 특정 테스트 노력을 위한 좋은(고품질) 데이터를 어떻게 정할지에 대한 의문이 생김. 궁극적으로 좋은 데이터의 정의는 테스트 노력의 요구사항으로 귀결됨

1) 생산 데이터를 대표

좋은 테스트 데이터의 첫 번째 성질은 그게 생산 데이터를 대표해야 한다는 것임. 생산 데이터를 이해하는데 있어 데이터 프로파일링과 비즈니스 사용자와의 토론이 중요하며, 예를 들면 아래와 같은 사항들을 확인한다.

• 데이터의 품질 우려가 있는가? 데이터가 완전하고, 신뢰할만하고, 시기 적절한가?
• 무엇이 특정 데이터의 상대적 중요성인가? 어떤 데이터 없이는 그들이 살 수 없는가?
• 어떤 데이터(또는 데이터 조합)가 가장 흔히 사용되는가? 어떤 리포트가 가장 자주 런 되는가?
• 어떤 데이터(또는 데이터 조합)가 문제가 있는 경향이 있는가? 어떤 리포트가 느리거나 또는 불완전한가?

더 많이 질문할수록 더 많이 배우게 되며, 이런 정보 모두가 데이터 선택 프로세스에 도움이 됨(또한 테스트 노력의 우선순위를 정하는데도 도움이 됨). 이 프로세스 동안 수집되는 주요 정보에 아래와 같은 것들이 포함된다.

• 도메인 값(Domain values): 어떤 데이터 필드를 위한 유효하고 의미 있는 값들의 전체 범위. 예) 성별 필드를 위한 도메인 값 집합에 남성(Male), 여성(Female), 미상(Unknown), 공란(Blank)이 포함됨
• 데이터 범위와 한계(Data ranges and limits): 특히 동등 클래스 정의. 예) 특정 달러액 이상의 예금이 특별한 자금세탁방지법 프로세스를 활성화시킬 수 있음. 이 경우 이 한계치를 넘는 예금액과 못 미치는 예금액 둘 다를 포함하는 테스트 데이터가 필요함
• 날짜시간 필드(또는 순차 필드)의 중요성: 이게 간단한 인덱싱 또는 감사 필드일 수도 있지만, 이런 필드들 중 많은 것이 리포트와 프로세싱 사이클을 운전하는데 사용됨. 테스트에서 효과적이기 위해서 이와 관련 상세사항을 알 필요가 있음
• 데이터 관계(Data relationships): 이게 다양한 데이터 특징을 포함함(크로스 시스템 데이터 매핑, 도출된/계산된 데이터의 소스)
• 업스트림과 다운스트림 데이터 의존: 데이터가 어디서 오고 어디로 가는지 아는 것이 중요. 이것이 데이터를 적절한 비즈니스 맥락(business context)에 놓는걸 가능케 함. 테스팅을 직접적인 입/출력 인터페이스로 제한할 수도 있지만, 데이터 흐름에 대한 최소한 일반적인 이해 없이는 중요 테스트 케이스를 놓칠 수 있음

 

어떻게 이 모든 정보가 비즈니스 사용자에 의해 소비되는지도 이해할 필요가 있음. 조직이 정형화된 설계 프로세스를 사용하면 많은 이런 정보를 운 좋게도 기존 설계 문서에서 찾을 수 있음. 그렇지 않으면 테스터가 소매를 걷어 부치고 직접 알아내야만 할 수도 있음. 비즈니스 사용자를 알아 가고 데이터 프로파일링 도구를 어떻게 사용하는지 배우는 것이 데이터에 대한 상세한 이해를 개발하는데 궁극적으로 최선의 방법이다.

2) 테스팅 요구에 맞도록 데이터를 최적화

좋은 테스트 데이터의 두 번째 성질은 최적화된 데이터 집합을 보장하는 것인데, 데이터에 대해 더 많이 알수록 테스트 데이터 집합을 더 많이 최적화할 수 있음. 데이터를 최적화하기 위한 일차적 방법은 잘 정립된 테스팅 관행을 따르는 것이다. 특히, 초기 테스트케이스 집합(그리고 관련된 데이터 요구사항)이 아래의 다양한 표준 테스트 기법을 통해 획득될 수 있음:

• 경계값 분석 기법(Boundary value analysis)
• 동등 클래스 분할(Equivalence class partitioning)
• 쌍 테스팅(Pairwise testing)과 기타 패러미터 조합 기법
• 모델 기반 테스팅(Model based testing)

 

기초 데이터에 대해 더 많은 상세사항을 가지고 있을 수록 더 정확하게 위 기법들을 적용할 수 있고 더 정제된 테스트 데이터 요구사항이 나올 수 있음. 또한 부정적 테스트 케이스를 위한 데이터도 잊지 말아야 함(예, 특수 문자 데이터, 유효하지 않은 형식, 가짜 필드 값). 창의성을 발휘하여 가장 이색적이고 발생 가능성이 낮은 데이터를 찾으려 노력해야 함

 

끝으로 테스트 데이터가 사용될 전체 맥락(context)을 고려할 필요가 있음. 아래 표는 테스트 데이터 요구사항을 완전하게 하기 위해 물어봐야 할 질문들을 일부 식별하여 나열하고 있음

얼마나 많은 데이터가 필요한가?	² 데이터가 너무 적으면 테스팅이 비효과적 ² 너무 많은 데이터는 비용(저장과 유지보수)이 들고, 종종 테스트 비효율성으로 이어짐
어떤 데이터가 필요한가?	² 데이터 요소의 잠재적인 값과 비즈니스 관련성을 이해한다. ² 비지니스 관련성이 리스크를 결정하고, 이는 다시 테스트 우선순위를 결정함
언제 데이터가 필요한가?	² 데이터가 시간 경과에 따라 변질됨 ² 테스트 일정과 리프레시 사이클이 적절히 맞춰질 필요가 있다.
어디에서 데이터가 필요로 될 것인가?	² 데이터 리프레시와 환경 가용성을 모든 영향을 받는 팀들과 조정한다.
데이터가 어떻게 보호될 것인가?	² 생산 데이터 소스를 활용할 때 민감한 정보를 일부러 애매하게 만들거나(obfuscated) 감출(masked) 필요가 있음
어떤 의존성이 있는가?	² 참조 무결성, 크로스시스템 통합, 애플리케이션에 특정한 요구사항
누가 데이터를 필요로 할 것인가?	² 정보가 공유될 수 있는가, 또는 데이터가 전용으로 될 필요가 있는가?
어떤 타입의 테스팅을 위해 데이터가 사용될 것인가?	² 수동 테스팅은 높은 정도의 가변성(variability)에 적응할 수 있는 반면 자동화는 안정성과 예측가능성이 높은 데이터 집합을 요구함 ² 성능 테스트는 데이터가 생산 규모이거나 또는 생산 배급의 대표성을 띌 것을 요구함
데이터가 어떻게 관리될 것인가?	² 데이터를 생성하고 유지보수하기 위한 프로세스를 개발한다. ² 시장 추세를 이해하고, 미래 데이터 요구사항과 시스템 요구(예, 용량)에 대비한 계획을 한다. ² 접근을 통제하고, 데이터 프라이버시 우려사항을 다루기 위해 테스트 데이터 관리 도구를 활용하고, 사용 다툼 이슈를 해결한다.

데이터 이해하기(Understanding Your Data)

테스트 데이터 요구사항을 개발해 나가는 동안 대답할 많은 질문이 생기고, 이 정보를 구성하고 분석하기 위한 체계적인 방법이 필요함. ‘테스트 데이터 관리 프레임워크’는 데이터에 대한 정보를 구성하는 것뿐만 아니라 이 정보를 시간 경과에 따라 유지보수 하는데도 도움이 됨. 이 프레임워크를 구축하는데 있어 아래의 데이터 특성(속성)을 고려하는 것이 도움이 된다.

• 데이터 분류(Data classifications)
• 데이터 소스(Data sources)
• 데이터 선정 규칙(Data selection rules)

1) 데이터 분류

데이터를 분류하는 방법이 아주 많지만 테스트 데이터 관리를 위한 목적에서는 아래 세 가지로 분류됨

• 환경 데이터(Environmental Data): 애플리케이션 운영 환경을 정의하고, 테스트의 실행 환경을 수립. 시스템 구성(운영체제, 데이터베이스, 애플리케이션 서버, 하드웨어 구성 등), 사용자 허가/인증/자격(사용자 ID, 패스워드, 일반/역할기반/테스터 계정을 위한 시스템 접근 수준), 구성 옵션(방화벽 포트 설정, 애플리케이션 서버 설정, 머신 리소스 할당 등)이 포함됨. 테스트 팀이 잘못된 환경(또는 부적절하게 구성된 환경)을 사용하는 경우 테스트 결과가 무효가 되어버리는 리스크가 존재
• 기준선 데이터(Baseline Data): 테스팅을 위한 의미 있는 시작점을 확립하고, 예상 결과 집합을 확립하려는 두 가지 근본 목적을 가짐. 일차 기준선(또는 시작점)이 테스트케이스 전제조건(pre-requisites)에 의해 확립되고, 통상적으로 (적절한 환경에 전개된) 의미 있는 비즈니스 데이터 집합을 포함한다. 정확한 데이터는 데이터 특징과 수행할 테스팅 타입 양쪽 모두에 달려 있음
• 입력 데이터(Input Data): 시스템이 주어진 입력에 어떻게 반응하는지 평가하기 위해 테스터가 테스트 대상 시스템으로 입력하는 데이터. 동작의 정확성을 판단하기 위해 관측된 동작(실제 결과)을 예상 결과와 비교함. 일반적으로 입력 데이터가 테스트케이스 자체의 한 컴포넌트이다.

2) 데이터 소스

데이터가 다양한 소스로부터 오며, 그 형식(format)도 생각할 수 있는 거의 모든 형식을 찾아 볼 수 있음. 데이터 소스를 간단히 구분하면 아래 세 개 범주로 나뉨

• 시뮬레이션된 데이터 또는 수작업 데이터(Simulated or hand crafted data): 생산 데이터 집합이 테스트에서 관심을 갖는 값들을 포함하지 않는 경우 유용(예, 사용자 인터페이스 수준 이하에서의 결함 삽입과 에러 체킹). 신규 시스템(또는 과거나 현재에 동등한 생산 데이터가 없는 데이터 필드 집합)과 작업할 때 손으로 만든 데이터가 필요할 수 있음. 보통 단위 테스팅이나 다른 화이트박스 테스팅 활동에는 수작업 데이터의 사용이 적절한 것으로 여겨지는 반면 통합, 단-대-단 테스팅, 기타 복잡한 타입의 테스팅을 위해서는 비용 효과적이기에는 시간 소모가 너무 큼
• 생산 데이터 집합의 복사 또는 파생물(Copies or derivatives of production data sets): 테스트에서 사용되는 테스트 데이터의 대부분을 형성. 생산 특징을 가진 데이터를 얻기 위한 최고의 소스. 하지만 완전한 생산 복사물(full production copies)의 사용은 피하는 편이며, 데이터 보안 위반의 리스크를 최소화하기 위해 데이터 집합이 적절히 청소된다(sanitized). 종합적인 데이터 요구사항 집합이 이 데이터를 최적화하고 안전하게 하는데 필요한 기준을 수립함(동시에 우리의 테스팅 요구를 충족시키는 고품질 데이터가 가용하도록 보장)
• 라이브 생산 데이터(Live production data): 오늘날 이게 생산 환경에 주는 리스크(데이터 보안 우려와 규제 준수 요구사항) 때문에 테스팅에 드물게 사용됨. 여전히 라이브 데이터로 테스팅 하는 것이 적절한 몇몇 시나리오가 존재하는데, 가장 흔한 경우가 생산 설치 검증(production install validation). 이런 타입의 테스팅을 위해서 검증을 위해 필요한 테스트 데이터가 생산 환경에 심어진다. 테스트 팀은 실제 고객 데이터 또는 기타 비즈니스 데이터에 우발적인 영향을 미치지 않도록 자신들이 정확히 어떤 데이터를 가지고 작업하는지 인지할 필요가 있다.

3) 데이터 선정 기준

테스트 데이터 요구사항 프로세스의 출력물은 데이터에 대한 상세한 이해와 테스트에 특정한 요구들의 집합이다. 아래는 테스트에 특정한 요구(test specific needs)의 예를 보여줌

• 보통 예금(savings account)과 당좌 예금(checking account)의 명세서 프로세싱이 두 개의 독립적인 시스템을 통해 수행된다.
  - 기준선 데이터 집합이 당좌 예금 계정의 예와 보통 예금 계정의 예 둘 다를 포함할 필요가 있다.
  - 입력 데이터 집합도 이 두 가지 타입의 계정을 위한 예금 거래(deposit transactions)를 포함할 필요가 있다.
• 사내 공급자와 사외 공급자를 위한 비용이 다른 규칙을 사용해 계산된다.
  - 기준선 데이터 집합이 사내 공급자와 사외 공급자 둘 다를 반드시 포함해야 한다.
  - 입력 데이터 집합이 사내 공급자와 사외 공급자 양쪽에 대한 요청을 포함해야 한다.
• 성별 필드의 유효 도메인 값: 남성(Male), 여성(Female), 미상(Unknown), 공란(Blank)
  - 기준선 데이터 집합이 유효 필드 값 각각을 가진 적어도 한 개의 고객 레코드를 포함해야 한다.
  - 입력 데이터 집합 옵션이 가용한 입력 메커니즘에 의해 정해짐. 예를 들어, GUI가 오로지 위 옵션들만 포함하는 드랍다운 리스트를 제공할 수도 있음(유효하지 않은 입력을 아예 불가능하게 만듬). 만일 데이터가 텍스트 파일을 통해 입력된다면, 적절한 시스템 에러 핸들링을 보장하기 위해 유효하지 않은 값을 쉽게 포함시킬 수 있음
  - 입력 데이터 집합이 성별에 특정한 프로세싱을 트리거하는 다른 시나리오를 포함할 필요가 있을 수도 있음(예, 의료 시스템에서 산부인과 방문을 위한 요청이 남자 환자에 의해 제출되면 에러가 제기되는가?)

테스터가 테스트 기반을 구축해 나감에 따라 긴 목록의 테스트 데이터 기준을 개발하게 되며, 이 프로세스 동안 아래를 고려해야 한다.

• 긍정과 부정의 테스팅 시나리오
• 가능한 겹치기와 중복: 이것들을 제거하거나 또는 이것들이 적절한지 확인함
• 데이터의 인구학적(Demographic) 또는 통계적(statistical) 특징
• 디폴트 조건(Default conditions)
• 교차 프로젝트 의존성(Cross-project dependencies)

테스트 데이터 구축하기(Building Test Data)

(시간 제약이나 완전한 정보의 부재 등으로 인해) 완전한 요구사항 집합을 개발할 수 없다면 테스트 데이터 구축에 있어 더 일반적인 접근 방법을 취해야 할 수도 있음. 예를 들어, 아래의 일반 타입 옵션 중 하나를 택해야 할 수도 있다.

• 적절히 청소된 생산 데이터 완전 복사본
• 생산 데이터의 5% 샘플링
• 플로리다 주에 있는 사무실/시설을 위한 모든 데이터
• 계획 A, B, C를 위한 모든 데이터

이 일반 데이터가 이후 테스트에 특정한 요구를 충족시키기 위해 증강되거나 커스토마이징 된다(수동으로 데이터를 편집하거나 또는 커스톰 스크립트로 프로세스를 자동화함). 다양한 테스팅 그룹의 요구를 충족시키기 위해 일반 데이터 집합과 테스트에 특정한 데이터 집합의 조합이 사용되기도 함. 이런 접근 방법에 상관없이 테스팅을 위한 데이터를 구축하는데(생성하는데) 아래의 세 가지 방법이 존재함

• 시스템 인터페이스(예, GUI, 배치 파일)를 통한 직접 데이터 입력: 요구되는 테스트 데이터 양이 작거나, 테스트 팀이 데이터 저장 시스템에 접근이 제한(또는 불가)될 때 흔히 사용됨. 테스터가 데이터의 완전 통제를 할 수 있는 장점이 있지만, 대규모 데이터를 요구하는 테스트를 위해 크기를 쉽게 늘리지 못함
• 복사와 편집: 구현하기가 상대적으로 쉽고 생산 데이터의 활용을 허용함. 만약 테스팅을 위해 특정 데이터가 요구된다면, 이 데이터가 통상적으로 표준 편집 인터페이스(예, SQL 클라이언트, 텍스트 에디터)를 통해 커스토마이징 됨. 대개 기초 데이터에 대한 높은 정도의 지식을 요구함. 관계형 데이터베이스나 복잡한 관계를 가진 데이터 집합과 작업할 때는 주의를 요함(한 위치에서의 변경이 데이터 집합에서 영향을 받은 모든 영역으로 제대로 전파될 필요가 있는데, 이걸 수동으로 하기가 매우 어려울 수 있음). 데이터 보안을 위해서는 완전한 생산 데이터 집합이 복사되고, 선정된 필드들이 민감한 정보를 가리기 위해 편집된다(또는 감추어짐).
• 전문 테스트 데이터 관리 솔루션: 테스트 데이터 집합을 최적화하는 도구. 대개의 경우 생산 데이터의 완전 복사본은 필요치 않으며, 적절히 간소화된 데이터 부분 집합(민감한 정보는 감춰짐)이 전반적인 테스트 효율성을 높이면서 동시에 필요한 커버리지를 제공함. 하지만 이 부분 집합을 얻는 것이 어렵고 복잡한 프로세싱을 요구할 수도 있음(특히 분산된 이종 환경에 있는 데이터와 작업할 때). 이 문제를 효과적으로 해결하기 위한 전문 테스트 데이터 관리 솔루션이 시장에 나와 있음. 예, Meridian의 AcceleTest