페이퍼요약 - 더 좋은 테스트 케이스를 작성하는 방법 by Runnels

제목: 더 좋은 테스트 케이스를 작성하는 방법(How to Write Better Test Cases)

저자: Dianne L. Runnels

문서유형: 컨퍼런스 페이퍼(총 12 페이지), 1999년

 

 

질 낮은 테스트 케이스로 인한 손실을 피하기 위해 어떻게 테스트 케이스의 품질을 개선할 수 있는지 설명한 자료

 

---

 

테스트 케이스의 요소

테스트 케이스는 시스템의 요구사항에 기반한 액션과 예상 결과의 집합으로 정의되며, 아래와 같은 요소들을 포함한다.

• 테스트의 목적 또는 어떤 요구사항이 테스트 되는지에 대한 서술
• 이 테스트 케이스가 어떻게 테스트 될 것인지 그 방법·
• 테스트를 위한 셋업: 테스트 대상 애플리케이션의 버전, 하드웨어, 소프트웨어, 운영 체제, 데이터 파일, 보안 액세스, 전제 조건(예, 선행되어야 할 다른 테스트), 테스트되는 요구사항에 관련된 기타 다른 셋업 정보 등
• 액션과 예상 결과(또는 입력과 출력)· 
• 인쇄물, 파일, 보고서, 화면 캡쳐 같은 증거물/첨부물(선택적)

 

테스트 케이스의 품질 - 좋은 테스트 케이스란

각 테스트 케이스가 그 구조적 요소(목적, 방법, 셋업, 입출력)를 포함하고 있어야 하며 또한 아래와 같은 품질 표준을 충족시켜야 한다.

• 정확성(Accurate): 테스트 케이스의 서술 부분에 테스트 하겠다고 쓴 것을 테스트 한다.
• 경제성(Economical): 테스트 케이스 목적을 위해 꼭 필요한 단계/필드 만을 가진다.  
• 반복성, 자립형(Repeatable, self-standing): 테스트 케이스가 잘 제어된 실험이다. 그걸 누가 테스트 하든지 간에 매번 동일한 결과가 나온다.
• 적합성(Appropriate): 테스트 케이스가 테스터와 테스트 환경에 알맞아야 한다. 어떤 테스트 케이스가 이론적으로는 견고하다 해도 테스터 중 누구도 갖고 있지 않은 기술을 요구한다면 그게 사용될 수 없음
• 추적성(Traceable): 해당 테스트 케이스가 어떤 요구사항을 테스팅하고 있는지 알아야 한다.
• 자기세정(Self-cleaning): 스스로 회복. 테스트 환경을 테스트 이전 상태로 스스로 되돌려 놓는다.

 

테스트 케이스의 형식(Format of test cases)

테스트 케이스의 모양이 아래의 세 가지로 나뉘며 어떤 형식이 적합한지는 상황에 따라 다르다. 종종 가장 생산적인 방식은 이 세 가지 타입의 케이스들을 모두 사용하는 것이며, 처음 두 개는 단위, 통합, 시스템 테스팅을 위해 사용하고 마지막 자동화된 스크립트는 회귀 테스팅을 위해 사용한다.

 

1. 단계별(step-by-step) 케이스가 적합한 경우

• 일회성의 테스트 케이스, 고유한 트랜잭션이나 규칙·
• 화면에서 화면으로 가는 비즈니스 시나리오·
• 많은 프로세싱 규칙들
• GUI 인터페이스
• 매트릭스로 표현하기 힘든 입력과 출력·

 

단계	액션	예상 결과
1	새로운 이름과 주소를 입력한다. <OK>를 누른다.	화면 008(새 이름 상세 사항)이 디스플레이된다.
2	모든 빈 칸을 실 데이터로 채운다. 화면 캡쳐를 한다. <OK>를 누른다.	화면 005(유지보수)가 디스플레이 된다.
3	<Inquiry> 버튼을 클릭한다.	화면 009(질의 상세 사항)이 디스플레이 된다.
4	화면 캡쳐한 것으로 부터의 이름을 입력한다. <OK>를 누른다.	화면 010(레코드 상세 사항)이 디스플레이 된다.
5	레코드 상세 사항을 화면 캡쳐한 것과 비교한다.	모든 상세 사항이 정확하게 일치한다.

[단계별 테스트 케이스의 예]

 

 

2. 매트릭스(matrix) 또는 표 형식이 적합한 경우

• 하나의 양식이나 동일 필드를 채우는데 있어서 많은 변이가 존재
• 동일한 입력, 여러 다른 플랫폼이나 브라우저, 여러 다른 형상(configurations)
• 문자 기반 화면(Character based screens)
• 매트릭스로 가장 잘 표현되는 입력과 출력

 

일자	96/1월 이후 고용 여부	401K(은퇴연금혜택)	생명 보험	지불 계산
99/10/25	Y	1	3	$24.50
98/1/4	Y	3	1	$34.00
96/3/6	N	2	5	$48.00
96/8/15	Y	2	5	$86.25
96/8/15	N	2	5	$105.00

[매트릭스 테스트 케이스의 예]

 

3. 자동화된 스크립트(automated script)

• 자동화된 테스팅 사용에 대한 결정은 테스트 되는게 무엇인지 보다는 테스팅을 하는 프로젝트와 조직에 더 관련되어 있음
• 프로젝트 관리자는 자동화된 케이스를 작성하는 것이 수동 테스트 보다 더 오래 걸리는 점(수동 테스트가 여전히 앞서 작성되어야 하므로)을 이해해야 함
• 인터페이스가 안정적인 경우라면 테스트가 레코딩 될 수 있으며, 자동화된 테스팅의 실질적인 플레이백(재생)은 소프트웨어 생명 주기의 유지보수 단계에서 이루어짐
• 관리자는 대상 도구 언어(예, C++, Visual Basic)로 프로그램을 작성 할 수 있는 사람을 반드시 제공해야 함. 단순한 스크립트는 테스트 분석가(test analysts)에 의해 레코딩 될 수 있지만, 더 강력한 스크립트(종종 커스톰 기능과 오브젝트를 활용)는 프로그래머에 의해 작성되어야 한다. 

[자동화된 스크립트 형식의 테스트 케이스 예]

 

 

테스트 케이스의 테스트용이성(testability) 개선하기

언어적으로 테스트용이성 개선

• 단순하고 일상 대화에서 쓰이는 언어로 작성하고, 테스트 단계를 작성 시에는 능동 화법(예, ~을 한다, ~를 비교한다, ~를 누른다)으로 기술한다.
• 테스터가 뭔가를 하는건지 아니면 시스템이 이것을 하는 건지가 항상 명확해야 한다. 예를 들어, “버튼이 눌려짐”이라는 표현을 테스터가 읽게 되면, 이게 자신이 버튼을 눌려야 하는걸 의미하는 건지 아니면 해당 버튼이 눌려진 채로 시스템이 디스플레이를 하는지를 검증해야 한다는 의미인지가 혼동 될 수 있음. 즉, 테스터를 헷갈리게 만드는 가장 흔한 경우가 액션과 예상 결과가 혼합되어 있을 때인데, 테스터가 수행하는 것은 항상 ‘액션’(테스트 케이스의 좌측에 위치)이고 시스템이 수행하거나 디스플레이 하는 것은 항상 ‘결과’(테스트 케이스의 우측에 위치)라는 것을 명심해야 함
• 개발에서 대상을 아주 잘 아는 경우 동일한 것을 여러 다른 방식으로 부르기도 하는데, 테스트 언어에서는 화면, 필드, 서버, 웹 페이지, 기타 다른 테스트 오브젝트를 명명함에 있어서 세심한 주의를 기울어야 함(즉, 이름이 정확하고 일관성이 있어야 함).

 

길이를 제어함으로써 테스트용이성 개선

• 단계별 케이스의 적절한 길이는 10~15 단계를 넘지 않아야 한다. 테스트 케이스를 짧게 유지하면 아래와 같은 여러 장점이 있다:
  - 각 단계를 테스트 하는데 더 적은 시간이 소비되고
  - 테스터가 중간에 길을 잃거나, 실수를 하거나, 도움을 필요로 하거나 할 가능성이 적어지며
  - 테스트 관리자가 테스트를 하는데 얼마나 시간이 걸릴지 정확하게 예측할 수 있고
  - 결과를 더 쉽게 추적하는게 가능해진다.
• 매트릭스 형식의 테스트 케이스는 약 20분 동안 테스트 될 수 있는 정도가 적절한 길이이다.
• 자동화된 스크립트의 경우는 그 길이가 테스트 실행의 이슈라기 보다는(대개는 순식간에 실행됨) 컨텐츠 관리, 유지보수, 결함 추적의 이슈이다. 보통 스크립트 당 하나의 비즈니스 시나리오(또는 유스케이스)이면 충분하다. 하나의 스크립트가 데이터를 로드하는데 필요한 만큼 수 차례 반복될 수 있으며 또는 다른 것들과 다양한 방식으로 조합되어 실행 될 수도 있다.

 

누적 케이스(Cumulative cases)는 실행을 위해서 이전 케이스들에 의존하는 것을 말함. 예를 들어, 테스트 #6을 실행할 수 있기 위해서는 그 전에 테스트 #1~5를 실행해야 함. 테스트용이성을 높이기 위해서는 테스트 케이스들의 순서가 비지니스 용례(예, 최종 사용자가 통상적으로 가장 먼저 하는게 뭔지)에 따라 정해져야 한다. 즉, 테스트 케이스들의 순서가 비즈니스 시나리오에 매치되어야 함

 

 

테스트 케이스 작성에 있어서 7가지 가장 흔한 실수

①    케이스를 너무 길게 만드는 것

②    불완전하거나, 부정확하거나, 또는 일관성 없는 셋업

③    단계를 일부 빠트림

④    변경되었거나 더 이상 존재하지 않는 이름의 필드

⑤    액션을 수행하는게 테스터인지 아니면 시스템인지 불분명함

⑥    무엇이 테스트 통과 결과인지(또는 실패 결과인지) 불분명

⑦    테스트 후 청소/정리(clean up)를 하는 것을 빼먹음

 

 

좋은 테스트 케이스를 얻는 데 도전이 되는 이슈

프로젝트의 갑작스런 변경은 테스트 작성을 하는데 있어 흔히 마주치게 되는 어려움이며, 이 때 최대한 품질을 유지하기 위한 대응책이 아래와 같다. 

 

요구사항 변경(Requirements changes)

• 이 경우 가장 좋은 방어는 변경을 통보 받는 것이다. 테스트 케이스를 작성하기에 앞서서 그리고 매 상태 회의 때마다 요구사항 변경에 따른 가장 큰 리스크가 어디에 있는지 알아낸다. 해당 변경에 어떤 케이스들이 영향을 받고 어떤 케이스들은 영향을 받지 않는지 파악하고, 영향이 없는 것부터 먼저 작성한다.
• 변수나 “미결정” 같은 표시를 테스트 케이스 내부에 넣어서 나중에 다시 와서 채울 것이라는 점을 나타낸다.
• 이미 작성된 테스트 케이스를 개정하는데 드는 비용에 대해 예산을 대는 사람이 확실히 알도록 한다. 케이스 당 이런 비용이 얼마인지 정량화 한다.
• 어떤 케이스들이 작성될지 또는 개정될지에 대해 프로젝트 관리자가 우선순위를 정하도록 맡긴다. 어디에 가장 큰 리스크를 가질지도 그들이 결정하도록 요청한다.
• 아직 제대로 완성되지 않은 테스트 케이스를 개정이 안된 채로 출시하고, 무엇이 변경되어야만 하는지 표시하도록 테스터에게 요청한다. 테스트를 유지보수하기 위한 시간에 더해서 각 케이스를 테스트 하기 위한 추가적인 시간 일정을 잡는다.

 

일정 변경(Schedule changes)

• 테스팅 일자가 앞당겨지면 어떻게 테스트 케이스가 영향을 받을지에 대한 선택에 관리자를 참여시킨다. 요구사항 변경의 경우 처럼 어떤 리스크를 감수할 것인지를 관리자들이 선택하도록 맡긴다.
• 신규 인력이 생산적이 되기에 앞서 1~2주의 교육을 할 시간 여유가 허용되고 이들의 작업을 지도하고 검토할 누군가가 있는 경우에만 새로운 직원을 추가한다.
• 먼저 테스트 되는 것들이 먼저 작성이 되도록 하기 위해서 케이스를 작성하는 순서를 바꾼다.
• 테스트 케이스가 목적, 어떤 요구사항이 테스트 되는지, 셋업 만 포함하도록 내용을 바짝 줄일 수도 있다. 이게 임시 테스팅(ad hoc testing) 만큼 질이 떨어지지는 않지만 제대로 완성된 케이스의 경우 만큼 결과가 신뢰할 수준은 아님을 관리자가 알아야 한다. 이런 종류의 테스트 케이스를 테스트 하기 위해서는 더 많은 시간을 일정으로 잡아야 하며, 테스팅 후에 케이스를 끝내기 위한 시간도 잡아야 한다.
• 작성자가 테스팅을 하면서 동시에 작성도 하도록 권한다. 테스팅을 하는데 그리고 테스팅 후에 작성을 마치는데 더 많은 시간이 주어지도록 일정을 잡는다. 

 

직원 변경(Staff turnover)

• 새 직원이 케이스를 작성을 하는데 있어서 가능하면 현 테스팅 프로젝트의 목적, 일정, 조직을 이해할 필요가 있다. 구두 안내 교육(Verbal orientations)이 무심결에 등한시 될 수 있다.
• 새 직원이 소프트웨어의 비즈니스 용례, 요구사항, 프로토타입을 배우는데 집중해야 한다. 이들이 작성하는 케이스의 수가 많지 않을지언정 그것을 올바르게 작성해야 한다.
• 새 직원이 표준을 어떻게 적용하는지 많은 실제 예를 가지고 직접 해 보는 훈련을 받아야 한다. 이들의 작업물이 먼저 세심하게 체크되어야 한다.
• 새 직원과 그가 작성하게 될 케이스가 기술/스킬 측면에서 잘 맞아 떨어지는 곳에 인력을 배치한다.

 

 

테스트 케이스 자산(test case assets) 보호하기

• 테스트 케이스의 가치를 보호하기 위한 가장 중요한 활동은 그것을 테스트가 가능한 상태로 유지보수 하는 것이다. 테스터가 소프트웨어에서 뿐만 아니라 테스트 케이스에서도 결함을 발견하게 될 것이므로 각 테스팅 사이클 후에 테스트 케이스가 유지보수되어야 한다.
• 테스팅 일정이 생성될 때, 프로그래머가 애플리케이션의 버그를 수정하는 동안에 테스트 분석가(또는 작성자)가 테스트 케이스를 손 볼 수 있는 시간이 할당되어야 한다. 테스트 케이스가 수정되지 않은 경우 테스터와 케이스 작성자가 다음 테스팅 사이클에서 테스트 케이스에 에러가 있는건지 아니면 소프트웨어에 에러가 있는건지 알아내느라 시간을 낭비하게 된다.
• 좋지 않은 버전화(versioning)나 저장(storage)으로 인해 소실되거나 훼손된 테스트 케이스는 그걸 재사용 가능하게 만들려는 목적 자체를 완전히 무너뜨린다. 케이스의 형상 관리(Configuration Management)는 테스트 관리 보다는 조직 또는 프로젝트에 의해서 다루어져야 한다. 만약 조직이 이런 수준의 프로세스 성숙도를 가지고 있지 않다면, 테스트 관리자 또는 테스트 작성자가 이걸 제공할 필요가 있다.
• 프로젝트 관리자(또는 테스트 관리자)가 다음과 같은 형상 관리 표준을 가지고 가치 있는 테스트 케이스 자산을 보호해야 한다:
  - 이름 주기와 번호 붙이기 관례(Naming and numbering conventions)
  - 형식, 파일 타입(Formats, file types)
  - 버전 붙이기(Versioning)
  - 케이스가 필요로 하는 테스트 오브젝트(예, 데이터베이스)
  - 읽기 전용의 저장(Read-only storage)
  - 제어된 액세스(Controlled access)
  - 현장 외 백업(Off-site backup)
• 테스트 관리자는 모든 테스트 케이스들의 색인을 가지고 있을 필요가 있다. 만일 형상관리에 의해 이런게 제공되지 않는다면, 스스로 이걸 생성한다.

 

 

테스트 케이스 체크리스트(Test Case Checklist)

품질 속성(Quality Attributes)

• 정확성(Accurate): 서술에서 테스트 하겠다고 말하는 것을 실제 테스트 한다.
• 경제성(Economical): 목적에 꼭 필요한 단계들 만을 가지고 있다.
• 반복성, 자립형(Repeatable, self-standing): 누가 테스트 하든지 간에 같은 결과가 나온다.
• 적합성(Appropriate): 현재 테스터와 향후 테스터 모두에게 적합하다.
• 추적가능성(Traceable): 요구사항으로 추적 가능하다.
• 자기세정(Self-cleaning): 테스트 환경을 깨끗한 상태로 되돌린다.

 

구조와 테스트용이성(Structure and testability)

• 이름과 번호를 가지고 있다.
• 어떤 요구사항이 테스트되고 있는지를 포함한 테스트 목적이 명시되어 있다.
• 테스팅의 방법을 기술하고 있다.
• 셋업 정보(환경, 데이터, 선행 테스트, 보안 액세스)를 명세하고 있다.
• 액션과 예상 결과를 가지고 있다.
• 어떤 증거(예, 보고서, 화면 캡쳐)가 저장될 필요가 있는지를 명시하고 있다.
• 테스팅 환경을 깨끗한 상태로 남겨둔다.
• 능동 화법의 언어를 사용한다.
• 15 단계를 초과하지 않는다.
• 매트릭스 형식의 케이스를 테스트 하는데 20분 이상 걸리지 않는다.
• 자동화된 스크립트에 목적, 입력, 예상 결과가 코멘트로 달려 있다.
• 가능하면 셋업이 선행 테스트의 대안을 제공한다.
• 이 테스트 케이스가 다른 테스트들과 정확한 비즈니스 시나리오 순서로 되어 있다.

 

형상 관리(Configuration management)

• 관례에 따른 이름 주기와 번호 붙이기를 사용하고 있다.
• 명시된 형식과 파일 타입으로 저장되어 있다.
• 테스트 대상 소프트웨어에 맞춰서 버전이 붙여져 있다.
• 케이스가 필요로 하는 테스트 오브젝트(예, 데이터베이스)들을 포함하고 있다.
• 읽기 전용으로 저장되어 있다(Stored as read-only).
• 저장물에 접근 제어가 걸려 있다(Stored with controlled access).
• 네트워크 백업이 운영되는 곳에 저장되어 있다.
• 현장 외부 장소에 기록보관(아카이브) 되어 있다.