테스트 케이스 개선 방법
소프트웨어 개발 분야에서 유능한 소프트웨어 개발자는 코딩의 효율과 품질을 개선하는 코딩 단계 전에 기능 요구 사항을 기반으로 항상 유닛 테스트 케이스를 작성한다. 이와 같이 소프트웨어 테스터는 소프트웨어 개발 수명주기(Software life Cycle)의 초기 단계에 테스트 케이스를 작성해야 하는데 소프트웨어 요구 사항 취합 단계에 작성하는 것을 권장한다. 테스트 매니저 또는 품질보증 매니저는 아래 목록에 따라 가능한 문서를 준비하고 취합해야 한다.
1 테스트 케이스 작성을 위한 문서 취합
1.1 사용자 요구 사항(User Requirements)
유저 요구 사항 문서는 비즈니스 절차, 사용자 프로파일, 사용자 환경, 다른 시스템과 호환성, 존재하는 시스템과의 교체 및 대체성, 기능 요구 사항, 비기능 요구 사항, 성능 요구 사항, 요구 사항의 권한 제약, 보안 요구 사항, 사용성 등을 말한다.
1.2 비즈니스 사용 사례(Business Use Case)
비즈니스 사용 사례 문서는 소프트웨어 적용 업무 관점에서 기능 요구 사항의 사용 사례 시나리오를 자세히 기술한 문서를 말한다. 이 문서는 요구 사항의 범위 내에서 적용 업무 관점의 사용자 동작이나 시스템 동작, 목표, 사전 조건, 사후 조건, 기본 동작 흐름, 대체 동작 흐름, 선택 사항, 시스템적인 업무 흐름에 대한 모든 예외사항을 포함한다.
1.3 기능 요구 사항(Functional Requirements)
요구 사항 범위 내에서 시스템의 각각의 특징에 대한 기능 요구 사항을 자세히 기술한 문서를 말한다. 일반적으로, 기능 요구 사항 문서는 개발팀이나 테스트팀에게 공통 백과사전과도 같은 정보로, 고객을 포함한 프로젝트 의사결정자에게는 공식적인 요구 사항으로 어떤 소프트웨어 개발사항보다 가장 중요한 정보를 제공한다.
1.4 소프트웨어 프로젝트 계획서 (선택사항)
소프트웨어 프로젝트 계획 문서는 프로젝트, 목적, 우선순위, 주요 단계, 전반적인 활동, 조직 구조, 전략, 진척 관리, 위험도 분석, 의존도, 제약사항, 교육 제반사항 사용자 준수 사항, 프로젝트 일정 등을 자세히 설명한다.
1.5 테스트 계획서
테스트 계획서는 품질관리 시스템, 문서 표준, 변경 관리 장치, 위험도 높은 모듈과 기능들, 형상 관리 시스템, 테스티 활동 계획, 결함 추적, 승인 조건을 기술한다. 이 문서는 테스트 되어야 하는 특성과, 테스트 되지 않아야 하는 특성을 판단하는데 사용되고, 테스트팀의 업무할당과 상호 협업, 자원 요구사항, 테스트 일정, 테스트 범위, 테스트 작성 기법, 테스트 산출물, 테스트 수행 필수 요소, 결함 보고 와 결함 추적 기법, 테스트 매트릭스 등이 포함된다.
2 샘플 테스트 케이스 작성하기
아래 예제와 같이 익숙하고 간단한 'Login' 화면에 대해 효율적인 테스트 케이스를 작성해 보자. 더 위험도 높은 특성을 가진 복잡한 화면이라도 테스팅 접근 방법은 대부분 비슷하다.
2.1 모든 테스트케이스 절차의 첫 번째 접근 방법은 위와 같이 초기화면에 도입하는 것이 될 것이다. 하지만 개발 초기 단계에서는 시험용 디자인 우선순위나 다른 기능들로 인해 접근되지 않을 수도 있다. 소프트웨어 요구 사항 명세서가 프로젝트팀에게 전달되었다면, 대부분의 시험용 화면은 프로젝트 팀에 의해 만들어진다. 시험용 화면은 테스터의 업무를 간소화하고 테스트케이스의 효율을 높인다.
2.2 기능 요구 사항 명세서는 조직 프로세스에 따라 다양한 문서들 중 활용되는 문서가 달라진다. 사용자 요구 사항, 기능 요구 사항 명세서 또는 소프트웨어 요구사항 명세서 등 사용되는 문서 등 테스트 케이스 작성을 위해 활용도가 높은 문서를 참고하여 테스트 대상에 대해 완벽한 기능 동작 흐름을 파악할 수 있는 문서를 판단하여 활용한다.
2.3 먼저 시험용 화면과 기능 명세서가 확보되면, 테스트팀은 아래와 같은 접근법과 기준으로 테스트케이스를 작성해야 한다.
- UI 테스트 케이스: UI 테스트 케이스는 사용자에게 보이는 컨트롤러나 영역을 대상으로 한다. 동적인 컨트롤러와 정적인 컨트롤러의 보이는 부분이 테스트 대상이 되는데 위 로그인 화면을 예를 들면 '아이디', '비밀번호', 글자 같은 것들이 정적인 컨트롤러로 사용자와 상호작용을 하지 않고 보이기만 하는 컨트롤러이다.
- 기능 테스트 케이스: 반면에 로그인 버튼과 하이퍼 링크('일회용 로그인', '아이디 찾기')와 같이 사용자가 컨트롤러를 클릭한 후에 어떤 동작이 되는 부분이 동적인 영역이다. 기능 테스트 케이스는 동적인 영역을 대상으로 한다.
- 데이터베이스 테스트 케이스 - 먼저 사용자는 아이디와 비밀번호를 입력한다. 테스트 케이스는 관련된 데이터베이스를 대상으로 하는데, 아이디와 패스워드가 데이터 베이스와 테이블에 올바르게 있는지 확인하고, 테스트 중 해당 아이디가 접근 권한이 있는지를 확인한다.
- 프로세스 테스트 케이스 - 화면에 보이는 컨트롤러와 관련된 동작이 아닌 특성과 기능관련된 프로세스 영역을 대상으로 한다. 예를 들어, '아이디찾기'를 클릭하면 신분 확인 및 Email이 발송 되는데 이와 관련된 일련의 과정이 적절한 절차로 확인이 가능한지를 확인한다.
2.4 마지막으로 BAOE 법칙을 상기한다. BAOE란 1) 기본 흐름, 2) 대체 흐름, 3)선택 사항, 4) 다양한 상황의 예외사항. 모든 관점에서 긍정적이고 부정적인 테스트케이스가 적용되어야 한다.
BAOE 접근법에 대해 위의 로그인 화면을 예로 들면 아래와 같다.
- 기본 흐름: 임의의 브라우저에서 로그인 URL을 입력하고 요구되는 정보를 입력하고 로그인한다.
- 대체 흐름: 모바일 기기에 어플을 설치하고 요구되는 정보를 입력하고 로그인한다.
- 선택 사항: 로그인 화면으로 접속할 때 가능한 다른 방법으로 확인한다. 예를 들면, 로그인 후에 로그아웃을 하면 다시 로그인 화면으로 이동되는지, 또는 로그인 접속 시간이 초과 되었을 때 다시 로그인 화면으로 돌아오는지 확인한다.
- 예외사항: 해당 테스트 케이스의 부정적인 테스트케이스를 확인한다. 예를 들면, 로그인 화면에 잘못된 기호를 입력 후에 해당 동작이 되지 않거나 오류 메시지가 출력된다.
참고 가능한 모든 정보를 활용해 문서 전면 커버 등을 포함한 로그인 화면에 대한 테스트 케이스를 정해진 형식으로 설계해 보자.
테스트케이스의 논리적인 순서와 사리에 맞는 번호 정의는 테스트 케이스 내용 및 내역을 빠르게 식별하는데 도움이 된다.
3 샘플 테스트 케이스
3.1 테스트 케이스 전면 페이지 예제
테스트 케이스 열은 테스트 대상에서 요구되는 테스트 매트릭스에 따라 우선순위, 테스트 목적, 에러 스크린샷 등과 같은 항목이 더 추가될 수 있다.
3.2 테스트 케이스 예제
문서를 단순화하고 가독성을 좋게 하기 위해서 아래와 같이 로그인 화면에 대한 테스트 케이스에 재현 절차, 기대 동작과 실제 동작을 작성한다.
3.3 테스트 데이터 수집
테스트케이스가 작성되어 질 때, 다른 테스터에게 가장 중요한 업무는 테스트 데이터 수집이다. 테스트 케이스에서 수행되어야 하는 테스트에 대한 샘플 데이터나 덤프 파일 같은 것들을 많은 테스터들이 미리 확보하지 않고 넘어가는 경우가 많다. 그러다 요구되어 지거나 수행할 때가 돼서야 데이터를 구하는데 이 부분은 심각한 오해이다.
테스트 케이스를 작성하는 시기에 테스트 케이스 문서에 데이터가 없거나 업데이트 되지 않는 다면, 테스트를 수행하는 시간에 테스터는 테스트 데이터를 구하느라 비효율적인 시간을 소비하게 된다. 테스트 데이터는 기능적인 흐름 관점에서 긍정적인 테스트 케이스와 부정적인 테스트 케이스에 대해 준비되어야 한다. 비즈니스 사용 사례 문서는 이런 상황에서 매우 유용하다. 소프트웨어와 사용자, 시스템 상호작용이 비즈니스 케이스 문서에 잘 정의되어 있다면 테스트팀은 비즈니스 사례 문서에 가능한 동작의 모든 관점을 고려하여 테스트 케이스와 관련된 테스트 자료를 작성하기 쉬울 것이다.
테스트 수행 시간에 효율적으로 테스트 데이터를 제공할 아래 샘플 테스트 데이터 문서에서 위에 작성된 테스트 케이스를 위한 데이터를 찾아라.
4 결론
테스트 케이스의 효율성 개선이라는 것은 간단하게 정의된 용어가 아니지만 지속적인 테스트케이스 작성 연습, 테스트 수행의 과정과 성숙된 프로세스를 거쳐서 테스트케이스를 개선할 수 있다. 소프트웨어가 더욱 복잡해지고 중요한 부분을 차지하면서 테스트팀은 완벽한 테스트 도구를 만들기 위한 노력과 개선을 하는데 게을러지면 안된다.
소프트웨어 개발 분야에서 유능한 소프트웨어 개발자는 코딩의 효율과 품질을 개선하는 코딩 단계 전에 기능 요구 사항을 기반으로 항상 유닛 테스트 케이스를 작성한다. 이와 같이 소프트웨어 테스터는 소프트웨어 개발 수명주기(Software life Cycle)의 초기 단계에 테스트 케이스를 작성해야 하는데 소프트웨어 요구 사항 취합 단계에 작성하는 것을 권장한다. 테스트 매니저 또는 품질보증 매니저는 아래 목록에 따라 가능한 문서를 준비하고 취합해야 한다.
1.1 사용자 요구 사항(User Requirements)
유저 요구 사항 문서는 비즈니스 절차, 사용자 프로파일, 사용자 환경, 다른 시스템과 호환성, 존재하는 시스템과의 교체 및 대체성, 기능 요구 사항, 비기능 요구 사항, 성능 요구 사항, 요구 사항의 권한 제약, 보안 요구 사항, 사용성 등을 말한다.
1.2 비즈니스 사용 사례(Business Use Case)
비즈니스 사용 사례 문서는 소프트웨어 적용 업무 관점에서 기능 요구 사항의 사용 사례 시나리오를 자세히 기술한 문서를 말한다. 이 문서는 요구 사항의 범위 내에서 적용 업무 관점의 사용자 동작이나 시스템 동작, 목표, 사전 조건, 사후 조건, 기본 동작 흐름, 대체 동작 흐름, 선택 사항, 시스템적인 업무 흐름에 대한 모든 예외사항을 포함한다.
1.3 기능 요구 사항(Functional Requirements)
요구 사항 범위 내에서 시스템의 각각의 특징에 대한 기능 요구 사항을 자세히 기술한 문서를 말한다. 일반적으로, 기능 요구 사항 문서는 개발팀이나 테스트팀에게 공통 백과사전과도 같은 정보로, 고객을 포함한 프로젝트 의사결정자에게는 공식적인 요구 사항으로 어떤 소프트웨어 개발사항보다 가장 중요한 정보를 제공한다.
1.4 소프트웨어 프로젝트 계획서 (선택사항)
소프트웨어 프로젝트 계획 문서는 프로젝트, 목적, 우선순위, 주요 단계, 전반적인 활동, 조직 구조, 전략, 진척 관리, 위험도 분석, 의존도, 제약사항, 교육 제반사항 사용자 준수 사항, 프로젝트 일정 등을 자세히 설명한다.
1.5 테스트 계획서
테스트 계획서는 품질관리 시스템, 문서 표준, 변경 관리 장치, 위험도 높은 모듈과 기능들, 형상 관리 시스템, 테스티 활동 계획, 결함 추적, 승인 조건을 기술한다. 이 문서는 테스트 되어야 하는 특성과, 테스트 되지 않아야 하는 특성을 판단하는데 사용되고, 테스트팀의 업무할당과 상호 협업, 자원 요구사항, 테스트 일정, 테스트 범위, 테스트 작성 기법, 테스트 산출물, 테스트 수행 필수 요소, 결함 보고 와 결함 추적 기법, 테스트 매트릭스 등이 포함된다.
2 샘플 테스트 케이스 작성하기
아래 예제와 같이 익숙하고 간단한 'Login' 화면에 대해 효율적인 테스트 케이스를 작성해 보자. 더 위험도 높은 특성을 가진 복잡한 화면이라도 테스팅 접근 방법은 대부분 비슷하다.
2.1 모든 테스트케이스 절차의 첫 번째 접근 방법은 위와 같이 초기화면에 도입하는 것이 될 것이다. 하지만 개발 초기 단계에서는 시험용 디자인 우선순위나 다른 기능들로 인해 접근되지 않을 수도 있다. 소프트웨어 요구 사항 명세서가 프로젝트팀에게 전달되었다면, 대부분의 시험용 화면은 프로젝트 팀에 의해 만들어진다. 시험용 화면은 테스터의 업무를 간소화하고 테스트케이스의 효율을 높인다.
2.2 기능 요구 사항 명세서는 조직 프로세스에 따라 다양한 문서들 중 활용되는 문서가 달라진다. 사용자 요구 사항, 기능 요구 사항 명세서 또는 소프트웨어 요구사항 명세서 등 사용되는 문서 등 테스트 케이스 작성을 위해 활용도가 높은 문서를 참고하여 테스트 대상에 대해 완벽한 기능 동작 흐름을 파악할 수 있는 문서를 판단하여 활용한다.
2.3 먼저 시험용 화면과 기능 명세서가 확보되면, 테스트팀은 아래와 같은 접근법과 기준으로 테스트케이스를 작성해야 한다.
- UI 테스트 케이스: UI 테스트 케이스는 사용자에게 보이는 컨트롤러나 영역을 대상으로 한다. 동적인 컨트롤러와 정적인 컨트롤러의 보이는 부분이 테스트 대상이 되는데 위 로그인 화면을 예를 들면 '아이디', '비밀번호', 글자 같은 것들이 정적인 컨트롤러로 사용자와 상호작용을 하지 않고 보이기만 하는 컨트롤러이다.
- 기능 테스트 케이스: 반면에 로그인 버튼과 하이퍼 링크('일회용 로그인', '아이디 찾기')와 같이 사용자가 컨트롤러를 클릭한 후에 어떤 동작이 되는 부분이 동적인 영역이다. 기능 테스트 케이스는 동적인 영역을 대상으로 한다.
- 데이터베이스 테스트 케이스 - 먼저 사용자는 아이디와 비밀번호를 입력한다. 테스트 케이스는 관련된 데이터베이스를 대상으로 하는데, 아이디와 패스워드가 데이터 베이스와 테이블에 올바르게 있는지 확인하고, 테스트 중 해당 아이디가 접근 권한이 있는지를 확인한다.
- 프로세스 테스트 케이스 - 화면에 보이는 컨트롤러와 관련된 동작이 아닌 특성과 기능관련된 프로세스 영역을 대상으로 한다. 예를 들어, '아이디찾기'를 클릭하면 신분 확인 및 Email이 발송 되는데 이와 관련된 일련의 과정이 적절한 절차로 확인이 가능한지를 확인한다.
2.4 마지막으로 BAOE 법칙을 상기한다. BAOE란 1) 기본 흐름, 2) 대체 흐름, 3)선택 사항, 4) 다양한 상황의 예외사항. 모든 관점에서 긍정적이고 부정적인 테스트케이스가 적용되어야 한다.
BAOE 접근법에 대해 위의 로그인 화면을 예로 들면 아래와 같다.
- 기본 흐름: 임의의 브라우저에서 로그인 URL을 입력하고 요구되는 정보를 입력하고 로그인한다.
- 대체 흐름: 모바일 기기에 어플을 설치하고 요구되는 정보를 입력하고 로그인한다.
- 선택 사항: 로그인 화면으로 접속할 때 가능한 다른 방법으로 확인한다. 예를 들면, 로그인 후에 로그아웃을 하면 다시 로그인 화면으로 이동되는지, 또는 로그인 접속 시간이 초과 되었을 때 다시 로그인 화면으로 돌아오는지 확인한다.
- 예외사항: 해당 테스트 케이스의 부정적인 테스트케이스를 확인한다. 예를 들면, 로그인 화면에 잘못된 기호를 입력 후에 해당 동작이 되지 않거나 오류 메시지가 출력된다.
참고 가능한 모든 정보를 활용해 문서 전면 커버 등을 포함한 로그인 화면에 대한 테스트 케이스를 정해진 형식으로 설계해 보자.
테스트케이스의 논리적인 순서와 사리에 맞는 번호 정의는 테스트 케이스 내용 및 내역을 빠르게 식별하는데 도움이 된다.
3 샘플 테스트 케이스
3.1 테스트 케이스 전면 페이지 예제
테스트 케이스 열은 테스트 대상에서 요구되는 테스트 매트릭스에 따라 우선순위, 테스트 목적, 에러 스크린샷 등과 같은 항목이 더 추가될 수 있다.
3.2 테스트 케이스 예제
문서를 단순화하고 가독성을 좋게 하기 위해서 아래와 같이 로그인 화면에 대한 테스트 케이스에 재현 절차, 기대 동작과 실제 동작을 작성한다.
3.3 테스트 데이터 수집
테스트케이스가 작성되어 질 때, 다른 테스터에게 가장 중요한 업무는 테스트 데이터 수집이다. 테스트 케이스에서 수행되어야 하는 테스트에 대한 샘플 데이터나 덤프 파일 같은 것들을 많은 테스터들이 미리 확보하지 않고 넘어가는 경우가 많다. 그러다 요구되어 지거나 수행할 때가 돼서야 데이터를 구하는데 이 부분은 심각한 오해이다.
테스트 케이스를 작성하는 시기에 테스트 케이스 문서에 데이터가 없거나 업데이트 되지 않는 다면, 테스트를 수행하는 시간에 테스터는 테스트 데이터를 구하느라 비효율적인 시간을 소비하게 된다. 테스트 데이터는 기능적인 흐름 관점에서 긍정적인 테스트 케이스와 부정적인 테스트 케이스에 대해 준비되어야 한다. 비즈니스 사용 사례 문서는 이런 상황에서 매우 유용하다. 소프트웨어와 사용자, 시스템 상호작용이 비즈니스 케이스 문서에 잘 정의되어 있다면 테스트팀은 비즈니스 사례 문서에 가능한 동작의 모든 관점을 고려하여 테스트 케이스와 관련된 테스트 자료를 작성하기 쉬울 것이다.
테스트 수행 시간에 효율적으로 테스트 데이터를 제공할 아래 샘플 테스트 데이터 문서에서 위에 작성된 테스트 케이스를 위한 데이터를 찾아라.
4 결론
테스트 케이스의 효율성 개선이라는 것은 간단하게 정의된 용어가 아니지만 지속적인 테스트케이스 작성 연습, 테스트 수행의 과정과 성숙된 프로세스를 거쳐서 테스트케이스를 개선할 수 있다. 소프트웨어가 더욱 복잡해지고 중요한 부분을 차지하면서 테스트팀은 완벽한 테스트 도구를 만들기 위한 노력과 개선을 하는데 게을러지면 안된다.
댓글
댓글 쓰기