소프트웨어 테스트 다시 시작하기: 파트 3

발행: 6일 전 (2026년 1월 2일 오후 09:57 GMT+9)

14 min read

원문: Dev.to

Source: Dev.to

아직 Part 1을 읽지 않으셨다면, 여기에서 읽으실 수 있습니다:

소프트웨어 테스트 재시작 – Part 2

“테스트 시나리오 vs 테스트 케이스: 차이점은 무엇이며 왜 중요한가?”

1. 테스트 시나리오

A test scenario는 테스트해야 할 내용을 고수준으로 설명한 것입니다.
이는 애플리케이션의 실제 사용 사례 또는 비즈니스 흐름을 나타냅니다.

예시 – 웹 애플리케이션이 있습니다.

테스트 시나리오

사용자 로그인 기능 확인

이 하나의 시나리오에서 여러 테스트 케이스를 도출할 수 있습니다:

유효한 자격 증명으로 로그인
잘못된 비밀번호로 로그인
잘못된 사용자 이름으로 로그인
빈 필드로 로그인
잠긴 계정으로 로그인

2. 테스트 케이스

테스트 케이스는 특정 기능을 수행하고 검증하는 단계별 프로세스를 상세히 설명합니다.

테스트 케이스의 핵심 구성 요소

Component	Description
테스트 케이스 ID	고유 식별자 (예: `TC001`)
테스트 설명 / 제목	테스트 대상에 대한 간단한 설명 (예: “유효한 자격 증명으로 로그인 기능을 검증한다.”)
전제 조건	실행 전에 충족되어야 하는 조건 (예: “사용자는 시스템에 등록되어 있어야 한다.”)
테스트 단계	단계별 지침 (아래 예시 참고)
테스트 데이터	테스트에 필요한 입력 데이터 (예: `username = user1`, `password = Pass@123`)
예상 결과	단계 실행 후 시스템이 수행해야 할 동작 (예: “사용자는 대시보드로 리다이렉트되어야 한다.”)
실제 결과	실제 발생한 결과 (실행 후 기입)
상태	통과 / 실패
비고	선택적 코멘트, 버그, 관찰 내용

테스트 케이스 예시

Test Case ID:      TC001
Title:             Verify login functionality with valid credentials
Preconditions:    User must be registered in the system
Test Steps:
  1. Open the login page
  2. Enter valid username (e.g., validuser)
  3. Enter valid password (e.g., validpassword123)
  4. Click the login button
Test Data:
  username = validuser
  password = validpassword123
Expected Result:  User is redirected to the dashboard
Actual Result:    (filled after execution)
Status:           Pass / Fail
Remarks:          (optional)

3. 양성 테스트 케이스와 음성 테스트 케이스

3.1 양성 테스트 케이스

양성 테스트 케이스는 유효한 입력을 사용하여 시스템이 의도대로 동작하는지 확인합니다.

예시 – 유효한 자격 증명으로 사용자 로그인 확인

단계	동작
1	로그인 페이지 열기
2	유효한 사용자 이름 입력 (예: `validuser`)
3	올바른 비밀번호 입력 (예: `validpassword123`)
4	로그인 버튼 클릭

예상 결과: 사용자가 성공적으로 로그인하고 홈페이지/대시보드로 리다이렉트됩니다.

3.2 음성 테스트 케이스

음성 테스트 케이스는 잘못된 입력을 사용하여 시스템이 오류를 정상적으로 처리하는지 확인합니다.

예시 – 잘못된 자격 증명으로 사용자 로그인 확인

단계	동작
1	로그인 페이지 열기
2	잘못된 사용자 이름 입력 (예: `invaliduser`)
3	틀린 비밀번호 입력 (예: `wrongpassword`)
4	로그인 버튼 클릭

예상 결과:

“Invalid username or password.”와 같은 오류 메시지가 표시됩니다.
사용자는 로그인 페이지에 머무르며 로그인되지 않습니다.

4. 소프트웨어 테스트에서 버그란?

버그(또는 결함)는 소프트웨어 애플리케이션에 존재하는 결함이나 편차로, 잘못되거나 예상치 못한 결과를 초래하거나 설계되지 않은 방식으로 동작하게 합니다.

예시 버그

유형	설명	기대 동작	실제 동작
UI Bug	전자상거래 사이트의 버튼에 있는 텍스트가 제대로 정렬되지 않음.	텍스트가 버튼 중앙에 위치해야 함.	텍스트가 버튼의 왼쪽으로 밀려 있음.
Functional Bug	사용자가 올바른 자격 증명을 입력해도 로그인할 수 없음.	올바른 자격 증명을 입력하면 사용자가 로그인하고 홈페이지로 리다이렉트되어야 함.	유효한 자격 증명을 제출하면 “Invalid username or password.” 오류가 표시됨.
Performance Bug	웹페이지가 제품 목록을 로드하는 데 30초 이상 걸림.	제품 페이지가 5초 이내에 로드되어야 함.	페이지 로드에 30초 이상 걸림.

5. 버그 라이프 사이클

단계

New – 버그가 식별되었지만 아직 분석되지 않음.
Assigned – 개발자 또는 팀이 버그 수정에 할당됨.
Open – 버그가 작업 중임.
Fixed – 개발 팀이 문제를 해결함.
Retest – 테스트 팀이 수정이 문제를 해결했는지 확인함.
Closed – 버그가 수정된 것이 확인되고 종료됨.
Reopened – 첫 번째 수정 후에도 문제가 지속되면 추가 조사 위해 다시 열림.

6. Common Bug Statuses

Bug statuses indicate the current state of a defect within its life cycle.

Status	Meaning
New	버그가 처음 발견되었으며 아직 검토되지 않음.
Open	버그가 검토 및 승인되었으며 개발자에게 할당됨.
Assigned	특정 개발자에게 할당됨(일부 도구에서는 “Open”과 중복).
In Progress	개발자가 수정 작업을 적극적으로 진행 중.
Fixed	개발이 수정 사항을 구현함.
Retest	QA가 수정 사항을 테스트 중.
Closed	버그가 수정된 것으로 확인되어 종료됨.
Reopened	수정이 충분하지 않아 버그가 다시 열림.

Additional Lifecycle Statuses

Status	Description
Pending Retest	수정이 테스트 환경에 배포되었으며 테스터 확인을 기다리는 중.
Verified	테스터가 버그가 성공적으로 수정되었음을 확인함.
Rejected	버그가 유효하지 않음(설계대로 동작하거나 재현 불가).
Duplicate	버그가 시스템에 이미 존재함.
Deferred	버그 수정이 향후 릴리스로 연기됨.
Not a Bug	보고된 이슈가 예상되는 시스템 동작임.
Cannot Reproduce	개발자 또는 테스터가 이슈를 재현할 수 없음.
On Hold	의존성 또는 정보 부족으로 작업이 중단됨.
Won’t Fix	버그가 인지되었지만 영향이 적어 수정하지 않음.

7. 소프트웨어 테스트에서 Bug Severity

Severity는 기술적인 관점에서 결함이 소프트웨어에 미치는 영향을 나타냅니다. 결함이 얼마나 심각한지를 측정합니다.

Bug Severity Levels

Severity	Description	Example
Critical / Blocker	시스템이 충돌하거나 사용할 수 없게 되어 테스트를 진행할 수 없습니다.	애플리케이션이 실행 시 바로 충돌; 서버 다운.
Major / High	주요 기능이 작동하지 않으며 우회 방법이 없습니다.	로그인 불가; 결제 처리 실패.
Medium / Moderate	일부 기능에 문제가 있지만 우회 방법이 존재합니다.	검색은 작동하지만 필터가 작동하지 않음.
Low / Minor	최소한의 영향을 주는 사소한 문제; 미관상 또는 UI 문제.	버튼 정렬 오류; 글꼴 불일치.

8. 소프트웨어 테스트에서 버그 우선순위

Priority는 결함을 얼마나 신속히 수정해야 하는지를 나타냅니다. 비즈니스 영향과 일정에 따라 팀이 먼저 처리할 결함을 결정하는 데 도움이 됩니다.

버그 우선순위 수준

Priority	Description	Example
High Priority	즉시 수정해야 함; 핵심 비즈니스 기능에 영향을 미침.	결제 버튼이 작동하지 않음; 체크아웃 중 앱이 충돌함.
Medium Priority	수정해야 하지만 즉시가 아님; 핵심 기능은 우회 방법으로 작동함.	프로필 업데이트는 작동하지만 경고 메시지가 표시됨.
Low Priority	나중에 수정 가능; 사용자 경험에 미치는 영향이 적음.	UI 정렬 문제.

9. 소프트웨어 테스터의 역할 및 책임

소프트웨어 테스터는 제품이 올바르게 작동하고 요구사항을 충족하며 결함이 없도록 보장합니다.

소프트웨어 테스터의 역할

품질 보증 역할 – 소프트웨어가 품질 기준과 사용자 기대에 부합하는지 확인합니다.
결함 식별자 – 버그, 오류 및 누락된 기능을 찾아냅니다.
요구사항 검증자 – 소프트웨어가 주어진 요구사항 및 사양과 일치하는지 확인합니다.
사용자 옹호자 – 최종 사용자의 관점을 고려하여 사용성 및 기능성을 보장합니다.
팀 협업자 – 개발자, 디자이너, 관리자와 긴밀히 협력하여 제품을 개선합니다.

소프트웨어 테스터의 책임

요구사항 이해 – 소프트웨어 요구사항, 설계 및 사용 사례를 신중히 검토합니다.
테스트 계획 – 테스트 계획을 수립하고 무엇을, 어떻게, 언제 테스트할지 결정합니다.
테스트 케이스 설계 – 요구사항을 기반으로 테스트 케이스와 시나리오를 작성합니다.
테스트 실행 – 수동 또는 자동 테스트를 수행하여 소프트웨어 동작을 확인합니다.
결함 보고 – 버그를 명확히 식별, 문서화하고 결함 추적 도구를 사용해 보고합니다.
회귀 테스트 – 수정 후 재테스트를 수행하여 새로운 변경 사항이 기존 기능을 손상시키지 않는지 확인합니다.
성능 및 보안 테스트 – 필요 시 속도, 안정성 및 기본 보안 측면을 점검합니다.
테스트 문서화 – 테스트 케이스, 테스트 보고서 및 테스트 결과를 유지 관리합니다.
자동화(해당되는 경우) – 자동화 테스트 스크립트를 개발하고 유지합니다.
지속적 개선 – 테스트 프로세스와 제품 품질 향상을 위한 개선안을 제시합니다.

결론

SDLC/STLC와 테스트 유형을 이해하고 결함을 식별하는 것부터, 소프트웨어 테스트는 모든 제품이 신뢰할 수 있고 사용자‑친화적임을 보장합니다. 테스터는 품질을 유지하고 개발과 사용자 사이의 격차를 메우는 중요한 역할을 합니다. 효과적인 테스트는 실제로 작동하는 소프트웨어를 제공하는 핵심입니다.