Scripted Testing
프로세스 및 기법 관련
Scripted Testing(스크립트 기반 테스트)는 마치 정교한 대본을 따라가는 배우와 같은 방식의 테스팅입니다.
소프트웨어를 테스트하기 위해 사전에 구체적인 테스트 케이스와 시나리오를 작성하고, 그 대본에 따라 테스트를 수행하는 체계적인 방법입니다.
즉, “무엇을 테스트하고, 어떻게 테스트하며, 어떤 결과를 기대할지” 모든 것이 미리 정의된 상태에서 진행됩니다.
Scripted Testing이란?
Scripted Testing은 사전 계획된 테스트 케이스를 기반으로 소프트웨어를 검증하는 과정입니다.
• 정해진 절차에 따라 테스트를 수행하며, 예기치 않은 상황보다는 명시된 요구사항을 충족하는지 확인하는 데 초점이 맞춰져 있습니다.
• 이 방법은 요구사항이 명확하고 반복적인 검증이 필요한 상황에서 특히 유용합니다.
예를 들어,
1. 회원가입 기능을 테스트한다면, 아래와 같은 테스트 케이스를 미리 작성해둡니다.
• 입력값: 이름: “홍길동”, 이메일: “user@example.com”, 비밀번호: “P@ssw0rd123”.
• 테스트 절차: 이름, 이메일, 비밀번호를 입력하고 “회원가입” 버튼을 클릭.
• 기대 결과: “가입 완료” 메시지가 표시되고, 사용자 데이터가 저장됨.
테스터는 이 계획된 절차를 따라 결과를 확인하고, 기대 결과와 일치하지 않을 경우 결함을 보고합니다.
Scripted Testing의 주요 특징
1. 사전 계획 필수
• 테스트 케이스와 시나리오가 사전에 작성되고, 이를 기준으로 테스트가 진행됩니다.
• 예: “로그인 기능 테스트”의 경우 올바른 자격 증명을 입력했을 때, 홈 화면으로 이동해야 한다는 테스트 케이스가 작성됩니다.
2. 구체적이고 반복 가능
• 정해진 절차에 따라 테스트를 수행하므로, 누구나 동일한 테스트를 반복 가능합니다.
3. 요구사항 중심
• 소프트웨어가 요구사항을 정확히 충족하는지 검증하는 데 초점이 맞춰져 있습니다.
• 예: “사용자가 8자 이하 비밀번호를 입력할 경우, ‘비밀번호가 너무 짧습니다’ 메시지가 표시되는가?”
4. 문서화된 결과 제공
• 테스트 진행 과정과 결과가 문서화되며, 품질 보증의 추적 가능성을 확보할 수 있습니다.
Scripted Testing은 마치...
Scripted Testing은 요리 레시피를 그대로 따라 하는 요리사와 같습니다.
• 레시피에는 필요한 재료, 조리 순서, 조리 시간이 모두 명시되어 있습니다.
• 요리사는 레시피를 따라 요리를 완성하며, 결과는 대체로 예상한 대로 나옵니다.
하지만, 레시피를 벗어나 새로운 시도를 하거나 재료를 바꿔보는 창의적인 접근(Exploratory Testing)은 제한됩니다.
대신 안정적이고 예측 가능한 결과를 보장받을 수 있습니다.
Scripted Testing의 실제 사례
사례 1: 전자상거래 웹사이트
• 테스트 시나리오: 상품 검색 기능 테스트
• 입력값: “노트북” 검색어 입력
• 테스트 절차
1. 홈페이지로 이동한다.
2. 검색창에 “노트북”을 입력하고 검색 버튼을 클릭한다.
• 기대 결과
• 노트북 관련 상품 리스트가 표시된다.
• 상품 가격과 이미지가 제대로 나타난다.
사례 2: 모바일 뱅킹 앱
• 테스트 시나리오: 이체 기능 테스트
• 입력값: 송금 금액: 100,000원, 수취인: 홍길동
• 테스트 절차
1. 로그인 후 “송금” 메뉴를 클릭
2. 송금 금액과 수취인을 입력하고 “확인” 버튼을 클릭
• 기대 결과
• “송금이 완료되었습니다” 메시지가 표시되고, 잔액이 업데이트된다.
Scripted Testing의 장점
1. 체계적이고 예측 가능
• 사전에 계획된 절차를 따르므로 테스트 결과의 예측 가능성이 높습니다.
2. 반복 가능
• 동일한 테스트를 여러 테스터가 수행하더라도, 일관된 결과를 얻을 수 있습니다.
3. 문서화 용이
• 테스트 케이스가 문서화되어 있어, 테스트 진행 상황과 결과를 추적하고 관리하기 쉽습니다.
4. 요구사항 검증에 효과적
• 명시된 요구사항이 충족되는지 확인하는 데 적합합니다.
Scripted Testing의 단점
1. 창의력 제한
• 사전에 정의된 절차를 따르므로, 예상치 못한 결함을 발견하기 어렵습니다.
2. 요구사항 변경에 취약
• 요구사항이 변경되면 테스트 케이스를 수정해야 하므로, 유지보수 비용이 증가할 수 있습니다.
3. 초기 작성 시간 소요
• 테스트 케이스를 처음 작성하는 데 많은 시간이 필요합니다.
4. 비정형 결함 탐지 어려움
• 예상하지 못한 오류나 비정형적인 시나리오를 발견하기 어렵습니다.
Scripted Testing vs. Scenario Testing
Scripted Testing vs. Scenario Testing1. Scripted Testing
테스트 초점
• 시스템의 개별 기능을 세밀하게 테스트
• 예를 들어, 로그인 페이지에서
- 올바른 이메일과 비밀번호 입력 시 로그인이 성공하는지,
- 잘못된 비밀번호 입력 시 오류 메시지가 출력되는지,
사용 목적
• 기능 단위의 정확성을 검증하고 결함을 발견
2. Scenario Testing
테스트 초점
• 실제 사용자 시나리오를 기반으로, 소프트웨어의 전체적인 흐름이 적절하게 작동하는지 검증
• 예를 들어, 전자상거래 사이트에서
1. 사용자가 상품을 검색
2. 상품을 장바구니에 추가
3. 결제 정보를 입력하고 주문 완료
사용 목적
• 단순히 개별 기능을 검증하는 것이 아니라, 사용자의 여정 전체가 매끄럽고 결함이 없는지 확인
Scripted Testing vs. Scenario Testing의 비유
Scripted Testing은 마치...
레고 블록을 하나하나 맞춰보는 과정입니다.
• 각 블록(기능)이 정확히 맞물리는지 확인
• 각 조각은 완벽하지만, 조립 후 전체 결과물(사용자 경험)은 보장하지 못함.
Scenario Testing은 마치...
레고로 만든 완성품(예: 자동차)을 굴려보는 과정입니다.
• 자동차가 실제로 잘 굴러가는지, 각 부분이 잘 연결되어 목적을 달성하는지 확인
• 블록 하나의 결함은 놓칠 수 있지만, 전체 결과물의 사용 가능성을 보장
Scripted Testing vs. Scenario Testing 실제 사례
(전자상거래 앱의 테스트)
1. Scripted Testing
• 목표: 로그인 기능 테스트
• 테스트 절차
1. 올바른 이메일과 비밀번호 입력 → 로그인 성공
2. 잘못된 비밀번호 입력 → 오류 메시지 출력
• 결과: 개별 로그인 동작이 제대로 작동함을 확인
2. Scenario Testing
• 목표: 사용자의 쇼핑 흐름 테스트
• 테스트 절차
1. 사용자가 상품 검색 → 결과 목록이 표시됨.
2. 상품을 장바구니에 추가 → 장바구니에 정상 추가됨.
3. 결제 버튼 클릭 → 결제 완료 메시지 출력
• 결과: 사용자가 쇼핑 흐름 전체를 문제없이 완료할 수 있음을 확인
각 테스트의 장단점
Scripted Testing vs. Scenario Testing• Scripted Testing은 개별 기능의 정확성을 검증하기 위한 기본 도구입니다.
• Scenario Testing은 사용자 관점에서 소프트웨어의 전체 흐름을 확인하는 데 초점을 맞춥니다.
Scripted Testing과 주니어 QA의 연결점
1. 체계적인 테스트 학습
• 사전 정의된 테스트 케이스를 따라가며 QA 프로세스를 체계적으로 익힐 수 있습니다.
2. 요구사항 이해와 분석
• 요구사항 문서를 기반으로 테스트 케이스를 작성하며 분석 능력을 키울 수 있습니다.
3. 문서화 역량 강화
• 테스트 케이스를 작성하고 결과를 기록하며, 명확한 문서화 능력을 배울 수 있습니다.
4. 자동화 테스트로 확장 가능
• 작성된 테스트 케이스는 자동화 테스트 스크립트로 발전할 수 있어, 자동화의 기초를 다질 수 있습니다.
5. 협업 경험 제공
• 테스트 케이스를 기반으로 개발자와 협력하며, 팀워크와 커뮤니케이션 능력을 강화할 수 있습니다.
이 둘은 상호보완적인 관계로, Scripted Testing으로 개별 기능을 철저히 검증한 후, Scenario Testing으로 사용자의 경험을 재현하고 확인하는 방식으로 함께 사용하면 가장 효과적입니다.
