테스트케이스 작성의 기본

테스트케이스 중요도의 배경

매일 많은 SW가 사용자들에 의해 사용되고 있는 현재, 그 SW의 품질은 더욱 중요시되고 있습니다.

같은 기능을 수행하는 SW는 많으며 그것을 사용하는 사용자들의 눈높이도 매우 높아졌기 때문에 SW품질이 조금만 좋지 않아도 그것을 대체할 SW는 너무 많이 존재하기 때문에 사용자들은 쉽게 다른 SW로 넘어가게 됩니다.

더욱이 리뷰 사이트나 SNS 사용이 일상적인 현실에서 SW가 조금만 좋지 않으면 "이거 못쓰겠네", "이거 버그 많으니 다른걸로 쓰세요"라든지의 부정적인 의견들이 빠르게 확산되곤 합니다.

개발 측면에 본다면 SW의 복잡도는 날로 증가하고 있으며 이로 인해 버그가 적은 SW의 개발은 점덤 더 어려워지고 있고 테스트 또한 어려워지고 있습니다.

따라서 이러한 SW의 특징을 파악해 시장에서 높은 평가를 받기 위해 고품질 SW를 내놓을 수 있도록 하는 여러 요소 중 중요하다고 할 수 있는 것이 바로 "테스트케이스"입니다.

테스트케이스란?

테스트케이스 사양서에 대해 국제 표준규격을 정하는 IEEE Standard 829-1983에서는 다음과 같이 정의하고 있습니다.

"A test case specification documents the actual values used for input along with the anticipated outputs."

즉, 예상되는 사용자의 사용 패턴에서 필요한 테스트 요건과 순서, 구체적인 방법 등을 문장화한 것입니다.

"이러한 입력을 해서 이러한 결과가 출력되면 그 SW는 올바르게 동작하고 있다"라는 것을 기록으로 남기고 다른 담당자와 개발자 등이 확인할 수 있도록 해 두는 것이라 할 수 있습니다.

그럼 왜 테스트를 담당자 머리 속에서 작업해서 끝내지 않고 일부러 테스트케이스로써 문장화해 둘 필요가 있을까요?

테스트케이스는 왜 필요한가?

테스트케이스를 작성하는 목적은 크게 두 가지입니다.

"테스트 누락 방지"와 "테스트 투명화"

SW는 사용자에 따라 상상을 뛰어넘는 여러가지 사용 패턴과 입력 방법이 존재할 것이라는 것을 예상할 수 있습니다.

테스트 담당자 개인의 판단으로 테스트 내용을 정해버리면 테스트 항목의 누락이 발생하기 쉽고 이것은 중대 결함 발생의 요인이 됩니다.

또한 릴리즈 후에 결함이 발견된 경우 개발 공정에서 어떤 테스트를 실시했는지 파악되지 않으면 다시 처음부터 발생 원인으로 예상되는 지점의 테스트를 반복해 실시해야 하므로 일정 지연과 프로젝트 비용 증가가 발생하게 됩니다.

효율적인 테스트를 실행하기 위해서는 제3자가 보아도 알 수 있는 투명한 상태의 테스트케이스를 남겨줄 필요가 있습니다.

테스트케이스를 작성하기 먼저 알아두어야 할 것들

테스트케이스를 작성하기 위해서는 먼저 테스트 종류에 대해 알아 둘 필요가 있습니다.

일반적으로 다음과 같은 테스트 기법들이 존재합니다.

기능 테스트	요구하는 사양(목적)을 만족하는지를 검증하는 테스트
도메인 테스트	경계값 분석 등 관계성을 지닌 복수의 변수를 동시에 검증하는 테스트
사양기반 테스트	설계서 및 사양서, 매뉴얼 등과 같은 문서 상에 기술된 내용과 SW가 똑같은 기능을 지니고 있는지 확인하는 테스트
부하 테스트	최대 설계 부하와 그 이상의 부하에서 성능을 검증하는 테스트
회귀 테스트	프로그램이 변경되었을 때 그로 인해 새롭게 발생되는 결함이 없는지를 검증하는 테스트
사용자 테스트	사용자에게 실제로 사용하도록 하여 결함 여부 및 사용성을 테스트하는 기법
시나리오 테스트	예상되는 일반적인 사용 방법을 검증하는 테스트
상태전이 테스트	화면이나 설정의 전이가 올바른 조건에서 분기 및 변화하는지를 검증하는 테스트
탐색적 테스트	사전에 작성한 테스트케이스에 따르지 않고 직전 테스트 결과에 따라 다음 테스트를 실행하는 기법
랜덤 테스트	임의적으로 입력과 조작을 행하는 방법으로 수행하는 테스트

자주 있는 나쁜 테스트케이스의 예

세상 모든 것이 그렇지만 테스트케이스에도 좋은 테스트케이스와 그렇지 않은 것이 있습니다.

| 불필요한 테스트 패턴이 많은 테스트케이스

"누락 없는 테스트케이스"를 지향하기 위해 모든 테스트 항목을 망라하여 작성한 결과 테스트케이스를 너무 방대하게 만들어 일어나는 사태입니다. 시스템과 SW의 모든 동작에 대한 조합을 테스트하려고 하면 경우에 따라서는 천문학적인 조합 수가 만들어지게 됩니다.

물론 품질 향상을 위해 테스트 항목을 누락없이 만드는 것도 중요한 요소이지만 개발 공정 상 테스트에 부여된 시간은 한정되어 있기 때문에 불필요한 항목은 테스트케이스에서 빼는 결단도 필요합니다.

| 이상 상태 테스트케이스 부족

상상을 해 보면 알 수 있습니다. 사양서나 매뉴얼대로 써진 대로만 사용하는 사용자를 본 적이 있나요?

실제로 시스템과 SW를 사용하는 사용자 관점에서 작성하지 않으면 생각치 못한 결함이 발생할 수 밖에 없습니다. 테스트케이스를 작성할 때에는 개발자 관점에서 사용자 관점으로 변환하여 작성하는 것이 중요합니다.

| 애매모호한 표현

테스트케이스의 표현이 명확하지 않으면 테스트 담당자는 매우 괴로워집니다. 

만약 테스트케이스 작성자가 아닌 제3의 담당자가 "여긴 어떻게 테스트하는 거예요?"라고 물어오는 경우라면 시간 손실만으로 끝나는 문제이지만, "음..여긴 대충 이렇게 하라는 소리겠지"라고 판단해서 잘못 테스트를 하면 올바른 결과를 얻지 못할 수도 있습니다.

좋은 테스트케이스의 작성 방법

그럼 테스트케이스를 어떻게 만들어야 하는지를 알아볼 차례입니다.

테스트케이스 전제 조건으로 "몇 번을 할지, 몇 명이 이용할지"와 같은 것이 있습니다.

즉, 그 테스트케이스에 따라 테스트하면 누구든지 똑같은 공정을 밟아 같은 결과를 얻지 않는다면 문장으로써 남기는 의미가 없습니다.

"애매모호한 곳이 없는지"가 좋은 테스트케이스의 포인트입니다.

예를 들어 "구인 정보를 검색"하는 테스트 케이스를 작성한다고 할 경우 아래와 같이 구별해서 보면 한 눈에 그 차이를 알 수 있습니다.

위에서 알 수 있듯이

- 입력과 예상 결과를 구체적으로 작성할 것

- 간결 명료한 문장으로 작성할 것

두 가지가 중요 포인트이며 이것은 "어디에 무엇이 있는지", "무엇을 입력하면 무엇이 출력되는지"를 구체적으로 명시하여 테스트의 일관성을 확보할 수 있습니다.

| 효율적인 테스트케이스 작성 포인트

일반적으로 하나의 SW에 잠재되어 있는 모든 결함을 100이라고 했을 때 75가 발견되면 그 테스트는 성공적이다라고 할 수 있습니다. 한정된 시간 내에 모든 결함을 발견하는 일은 불가능하기 때문에 테스트케이스 작성에 있어 효율적으로 결함을 발견하기 위한 작성을 할 필요가 있습니다.

그 중 하나의 방법이 바로 "결함 분석"입니다. "80%의 결함은 20%의 코드에서 나온다"라는 말처럼 결함은 일정한 규칙성이 있는 경우가 존재합니다. 따라서 발견한 결함의 규칙성을 바탕으로 추측하여 테스트케이스를 작성하는 것이 중요한 포인트입니다.

또한, 테스트를 효율적으로 진행하기 위해서는 편리한 툴을 이용하는 것도 하나의 방법입니다.

관리 시스템 중에 Redmine과 Jira와 같은 BTS(Bug tracking system)으로도 활용 가능한 툴이 있습니다. 이러한 툴을 이용하면 프로젝트 관리는 물론 결함 추적도 매우 편리해져 프로젝트 공정을 단축할 수 있습니다.

대규모 프로젝트/ 비교, 검증 테스트 / 그 외 프로젝트 QA에 대한 QA Service 지원 및 기타 관련 아웃소싱 업무가 필요한 경우 아래 연락처나 이메일로 연락 주시면 성실히 대응 하겠습니다. 

---

Contact US

Address

서울특별시 금천구 가산디지털1로 19 
대륭테크노타운 18차 20층

2018.12.27 | 지도 크게 보기 ©  NAVER Corp.

Phone
02-6190-7296

E-mail
qa_partner@infrawaretech.com

Homepage
http://infrawaretech-qa.tistory.com/