현재 사용하고 있는 테스트 케이스 작성 방식을 기술하며, TC 작성 시 주로 확인하는 사항 및 TC 관리 방식에 대한 내용을 기술해보겠습니다 🤗
테스트 케이스(Test Case)란?
테스트 케이스(이하 TC)는 테스트의 기본 단위이고, 특정 조건이나 상황에서 시스템이 올바르게 작동하는지 확인하기 위한 절차나 기대 결과를 문서화하여 TC 내용을 기반으로 테스트를 진행합니다. TC가 있어야 체계적이고, 정상적인 테스트를 진행했다는 근거자료로 사용할 수 있고, 품질 보증에 기반이 되는 자료로 활용될 수 있습니다.
TC 구성 요소와 작성 방식
TC의 구성요소는 ID, 테스트 설명, 사전조건, 테스트 데이터, 테스트 수행 절차, 예상 결과로 나뉘어지며, 테스트를 진행하는 경우, 실제 결과, 테스트 상태가 추가될 수 있습니다. 물론 일부 항목은 다른 항목에 자연스럽게 포함하여 작성 할 수 있습니다(ex: 테스트 데이터는 수행 절차안에 포함)
아래는 간단한 로그인 동작으로 작성한 TC입니다.
ID | 테스트 설명 | 사전 조건 | 수행 절차 | 예상 결과 | 테스트 상태 | 참고 사항 |
TC001 | 정상 로그인 기능 동작 확인 | 로그인 페이지에 접근 가능해야 함 | 1. 로그인 페이지에 접근 2. 사용자 ID에 'user' 입력 3. 사용자 PW에 'password'입력 4. 로그인 버튼 클릭 |
정상 로그인 수행되며 다음 페이지로 이동 됨 | Pass | - |
TC002 | 비정상 로그인 기능 동작 확인 (비밀번호 미 입력) |
로그인 페이지에 접근 가능해야 함 | 1. 로그인 페이지에 접근 2. 사용자 ID에 'user' 입력 3. 사용자 PW 입력하지 않음 4. 로그인 버튼 클릭 |
비밀번호를 입력하라는 안내 문구 출력 | Fail | ISSUE-001 |
TC003 | 비정상 로그인 기능 동작 확인 (틀린 비밀번호 입력) |
로그인 페이지에 접근 가능해야 함 | 1. 로그인 페이지에 접근 2. 사용자 ID에 'user' 입력 3. 사용자 PW에 맞지 않은 값 입력 4. 로그인 버튼 클릭 |
사용자 정보가 맞지 않다는 안내 문구 출력 | Pass | - |
대중적인 로그인 동작에 대한 방식을 기준으로 TC를 생각하여 작성해봤습니다.
TC를 작성할 때는 항상 정상 동작만 작성하지 않습니다. 비정상 동작을 수행했을때 사용자에게 정상 안내 가이드가 표시되는지, 안내 동작을 통하여 정상 동작을 유도할 수 있는지를 확인하는 테스트 케이스도 작성합니다.
TC를 기반으로 테스트를 수행하면 테스트 상태란에 결과 값을 작성하고, Fail TC가 있다면 결함 이슈를 등록하고 링크를 연결합니다. 사내에서 활용하는 BTS(Bug Tracking System) 프로그램을 사용하여 이슈를 등록하여 개발자 혹은 기획자에게 공유합니다. 결함 등록 방식은 다른 포스팅에서 작성해보겠습니다 :)
개인적인 TC 구성 방식
제가 TC를 구성할 때 항상 확인하는 조건은 아래와 같습니다.
- 정상 동작 테스트 케이스
- 비정상 동작 테스트 케이스
- 비정상 동작에 따른 정상 동작을 유도하는 가이드 유무 확인
- 버튼 여러번 클릭 수행 동작 확인 (중복 동작 여부 확인)
- 유효성 검사 테스트 (길이 제한, 입력 제한 등)
- 해상도 변화에 따른 UI 레이아웃 정상 확인
이 외에도 탐색적 테스트시 개발자나 기획자가 생각하는 정상적인 동작을 안했을 때 어떤 방식으로 대처를 하는지를 주로 확인하고 있습니다. 사용자는 어떤 동작이든 자유롭게 수행할 수 있는 자유도를 가지고 있다고 생각하면서 테스트를 진행하고 있습니다. (물론 다른 팀은 왜 이렇게 쓰는사람이 어딨냐고 하시면서 싫어해요.. 🤣)
TC 관리 도구 알아보기
GPT의 힘을 빌려 TC 관리 도구를 알아보고 제가 주로 사용하는 도구에 대한 설명을 하도록 하겠습니다.
TC 관리하는 도구는 정말 다양하게 있습니다. 정말 가볍게 시작할 수 있는 엑셀 시트부터 JIRA, TestRail 등 다양한 도구로 TC를 관리할 수 있습니다. 아래 표는 JIRA, TestRail, TestLink, Excel로 테스트 케이스를 관리했을 때 특징을 GPT로 알아봤습니다.
특징 |
JIRA | TestRail | TestLink | Excel |
개발사 | Atlassian | Gurock Software | Open Source | Microsoft |
기본 용도 | 프로젝트 관리, 이슈 추적 | 테스트 케이스 관리 | 테스트 케이스 관리 | 일반 데이터 관리 |
유형 | 클라우드 / 온프레미스 | 클라우드 / 온프레미스 | 온프레미스 | 로컬 / 클라우드 (OneDrive, Google Drive 등) |
통합성 | 다양한 플러그인 및 API를 통한 통합 | JIRA, Jenkins, GitHub 등 다양한 도구와 통합 | 다양한 도구와의 API 통합 가능 | 다른 소프트웨어와의 통합은 수동적 |
사용자 인터페이스 | 사용자 친화적인 UI, 대시보드 및 보고 기능 | 직관적이고 사용자 친화적인 UI | 기본적인 웹 UI | 간단한 표 형식의 UI |
보고서 기능 | 강력한 보고서 및 대시보드 기능 | 상세한 보고서 및 실시간 분석 기능 | 기본적인 보고서 기능 | 수동으로 보고서 생성 필요 |
협업 기능 | 팀 협업 기능 (댓글, 알림 등) | 실시간 협업 및 커뮤니케이션 기능 | 제한된 협업 기능 | 공유 및 실시간 편집 가능 (클라우드 사용 시) |
비용 | 유료, 사용자당 과금 모델 | 유료, 사용자당 과금 모델 | 무료 (오픈 소스) | Microsoft Office 라이선스 필요 |
장점 | - 강력한 이슈 추적 및 프로젝트 관리 기능 | - 직관적인 테스트 케이스 관리 및 보고서 기능 | - 무료로 사용 가능 | - 사용이 간편하고 접근성 높음 |
- 다양한 플러그인 및 확장 기능 | - 다양한 도구와의 통합 가능 | - 커스터마이징 가능 | - 기본적인 도구이므로 누구나 쉽게 사용 가능 | |
단점 | - 초기 설정 및 학습 곡선이 있을 수 있음 | - 비용이 발생할 수 있음 | - UI가 다소 직관적이지 않을 수 있음 | - 대규모 테스트 케이스 관리에 비효율적 |
- 고급 기능 사용 시 비용이 증가할 수 있음 | - 고급 사용자에겐 기능이 부족할 수 있음 | - 유지 관리 및 업데이트 필요 | - 자동화 및 고급 기능 부족 | |
주요 사용 사례 | - 소프트웨어 개발 프로젝트 관리 및 이슈 추적 | - 소프트웨어 테스트 케이스 작성 및 관리 | - 소규모 프로젝트나 예산이 제한된 프로젝트 | - 간단한 테스트 케이스 관리 및 소규모 프로젝트 |
TestRail 간략 소개
저는 업무를 진행할 때 주로 TestRail을 사용했습니다.
TC 관리 도구로 유명하며 작년 QA 컨퍼런스에서 많은 업체에서 사용하고 있는것을 확인하였습니다.
직관성이 좋으며 프로젝트 별 케이스 관리도 용이하고 보고서도 자동 추출해주기도 합니다.
하지만 유료 정책이고, 저는 클라우드 환경을 사용하는데 간혹 딜레이가 잦게 발생하는 경우도 있었습니다.
그래도 케이스를 관리하거나 테스트 수행할 때 JIRA 연동도 가능해서 편한 점이 많았습니다.
페이지 별 폴더 트리 구조로 생성하여 TC를 관리하는 부분이나, 이전 테스트 이력을 확인하는 등 케이스 관리에 특화되어 있다고 생각합니다. 아직 폭넓은 기능을 다양하게 활용해보진 못해서 아직 공부해야 할 부분이 많습니다 🙄
테스트 케이스 작성에 대한 부분을 알아보다 길어졌는데 다음엔 위 테스트 케이스로 결함을 발견했을 때 등록했던 방식에 대해 정리해보도록 하겠습니다 :)
'QA > 업무 방식' 카테고리의 다른 글
UI/UX에 도움 되는 사이트 정리 (0) | 2024.07.07 |
---|---|
테스트 중 결함 등록 방식 공유 (0) | 2024.06.13 |
소프트웨어 개발 생명 주기 정리 및 QA의 역할 (3) (0) | 2024.06.05 |
소프트웨어 개발 생명 주기 정리 및 QA의 역할 (2) (3) | 2024.06.04 |
소프트웨어 개발 생명 주기 정리 및 QA의 역할 (1) (1) | 2024.06.04 |