소프트웨어 테스트 개요

💡 핵심 용어와 포인트

• 소프트웨어: 명령어의 집합
• 소프트웨어 개발 생명주기(SDLC): 요구사항 분석 → 설계 → 구현(코딩) → 테스트 → 운영
• 테스트: 특정 대상이나 기능을 검증하기 위한 테스트 또는 테스트 활동
• 테스팅: 테스트 계획, 분석, 설계, 실행, 결과 평가 등 소프트웨어 품질을 확인하기 위한 전반적인 활동
  결함을 찾고 품질을 확인하기 위해 계획부터 수행, 결과 보고까지 진행하는 전체 프로세스
  • 결함: 요구사항과 다르게 만들어진 것
• 테스터: 품질과 리스크에 대한 정보를 제공하는 역할
• Error = 사람이 한 실수 / 결함의 원인
• Defect = 그 실수가 산출물에 들어간 잘못된 부분
• Failure = 그 결함이 실제 실행 중 문제로 나타난 현상
• Incident = 테스트 중 발견되어 추가 확인이나 조사가 필요한 상황

1. 소프트웨어란?

컴퓨터가 특정 기능이나 성능을 수행하도록 만드는 명령어의 집합

소프트웨어는 단순히 프로그램 코드만 의미하는 것이 아니라 다음과 같은 요소를 포함한다.

• 컴퓨터 프로그램
• 프로그램에서 사용하는 자료구조
• 프로그램의 사용 및 동작을 설명하는 문서

1.1 소프트웨어 분류

소프트웨어는 크게 시스템 소프트웨어와 응용 소프트웨어로 구분할 수 있다.

• 시스템 소프트웨어

  • 하드웨어와 시스템을 관리·운영하는 소프트웨어
  • ex. Windows, Linux, Android, iOS 등의 운영체제

• 응용 소프트웨어

  • 사용자의 특정 목적을 수행하기 위한 소프트웨어
  • ex. 문서 작성 프로그램, 그래픽 프로그램, 게임 등

1.2 소프트웨어 특징

대표적인 특징은 비가시성(Invisibility)이다.

소프트웨어는 물리적인 제품과 달리 내부 구조나 개발 진행 상태를 눈으로 직접 확인하기 어렵다.
이러한 특성 때문에 개발 과정에서 문제가 발생해도 즉시 발견하기 어려울 수 있으며, 이를 체계적으로 관리하기 위한 개발 프로세스와 테스트 활동이 중요하다.

2. 소프트웨어 개발 생명주기(SDLC)

SDLC(Software Development Life Cycle)는 소프트웨어 개발 과정을 일정한 절차로 관리하기 위한 과정이다.

요구사항 분석 → 설계 → 구현(코딩) → 테스트 → 운영

소프트웨어 테스팅은 개발과 완전히 분리된 활동이 아니라 SDLC 전반과 연결되어 수행된다.

테스터는 구현이 완료된 이후에만 참여하는 것이 아니라 요구사항과 설계 단계에서도 문서를 검토하고 테스트 관점을 제시하면서 문제를 조기에 발견할 수 있다. 따라서 소프트웨어 테스팅을 이해하기 위해서는 먼저 소프트웨어가 어떤 흐름으로 개발되는지 이해할 필요가 있다.

왜 개발 프로세스가 필요한가?

소프트웨어 개발은 여러 사람과 작업이 연결되어 있기 때문에 정해진 프로세스 없이 진행하면 일정 지연, 누락, 중복 작업, 품질 저하 등의 문제가 발생할 수 있다.
따라서 개발 과정을 체계적인 프로세스로 관리하여 효율적이고 효과적으로 프로젝트를 수행하고 성공 가능성을 높인다.

• 효율적(Efficient): 시간 / 자원
• 효과적(Effective): 목표 달성

테스트 프로세스도 왜 필요한가?

테스팅 역시 단순히 프로그램을 실행해서 버그를 찾는 활동이 아니다.
테스트를 계획 → 분석 → 설계 → 구현 → 실행 → 완료와 같은 체계적인 절차로 관리함으로써 한정된 시간과 인력 안에서 중요한 부분을 우선적으로 검증할 수 있다. 즉, 테스트 프로세스의 목적 역시 테스트 활동을 효율적이고 효과적으로 관리하는 것이다.

• 효율적인 테스팅: 제한된 시간과 인력으로 적절한 테스트를 수행
• 효과적인 테스팅: 중요한 결함을 발견하고 목표로 한 품질 수준을 확인

개발 프로세스가 프로젝트의 성공 가능성을 높이기 위한 체계라면,
테스트 프로세스는 품질 목표를 효율적·효과적으로 달성하기 위한 체계라고 이해하면 된다.

대표적인 SDLC 모델

• 폭포수 모델(Waterfall)
• V-Model
• 애자일(Agile)
• 기타 소프트웨어 개발 생명주기 모델

2.1 요구사항

테스터가 프로젝트에 투입되었을 때 중요하게 확인해야 하는 것 중 하나가 요구사항이다.
요구사항은 가능한 한 명확하고 구체적이며 객관적으로 판단할 수 있도록 작성되어야 한다.

정성적인 표현은 사람마다 다르게 해석될 수 있으므로 가능한 한 측정 가능하고 구체적인 표현으로 작성하는 것이 좋다.

요구사항에서 확인해야 할 관점

요구사항을 확인할 때는 단순히 기능만 보는 것이 아니라 다음과 같은 관점을 함께 고려한다.

• 비즈니스 관점
• 고객의 니즈
• 기능
• 예외 상황
• 품질 및 리스크

테스터는 요구사항을 바탕으로 고객, 기획자, 개발자 등 이해관계자 사이에서 발생할 수 있는 해석의 차이나 누락된 부분을 발견할 수 있어야 한다.

3. 소프트웨어 테스팅이란?

소프트웨어가 요구사항에 맞게 동작하는지 확인하고, 결함을 발견하여 품질에 대한 정보를 얻는 과정

3.1 테스트와 테스팅

• Test: 요구사항을 기반으로 특정 대상이나 기능을 검증하기 위한 테스트 또는 테스트 활동
• Testing
  • 소프트웨어 품질을 확인하기 위해 수행하는 전반적인 테스트 프로세스
  • 테스트 계획/분석 → 설계 → 수행 → 결과 분석 → 결함 관리 → 보고

즉, Test는 개별적인 테스트 활동, Testing은 보다 넓은 범위의 테스팅 활동 전반으로 이해하면 쉽다.

3.2 소프트웨어 테스트의 목적

테스팅의 목적은 단순히 버그를 많이 찾는 것에 그치지 않는다.

• 결함 발견
• 결함 예방
• 소프트웨어 품질에 대한 신뢰 확보
• 품질과 리스크에 대한 정보 제공
• 요구사항 충족 여부 확인

즉, 테스트 결과를 통해 현재 소프트웨어의 품질 수준과 남아 있는 리스크를 판단할 수 있도록 정보를 제공하는 것도 중요한 목적이다.

3.3 소프트웨어 테스트 유형별 목적

① 개발 과정에서의 테스팅

개발 과정에서는 테스트를 통해 Failure를 발견하고, 그 원인이 되는 Defect를 식별하여 수정할 수 있도록 정보를 제공하는 것이 중요하다. 즉, 단순히 정상 동작만 확인하는 것이 아니라 다양한 조건에서 문제를 드러내어 결함을 발견하는 것이 목적 중 하나이다.

② 인수 테스팅

소프트웨어가 예상한 대로 동작하는지 확인하고 사용자의 요구사항이나 비즈니스 목적을 만족하는지에 대한 확신을 얻는 과정이다.

4. 소프트웨어 테스트 기본 용어

Error(에러, 오류)

• 사람이 만들어낸 실수로, 소프트웨어에 결함이 발생하게 되는 원인이다.
• Error가 소프트웨어나 관련 산출물에 반영되면Defect가 발생할 수 있다.

Defect (결함)

• 소프트웨어의 코드, 문서, 요구사항 등의 산출물에 존재하는 잘못되거나 누락된 부분이다.
• Error로 인해 발생할 수 있다.
• 요구사항이나 표준 등을 기준으로 결함 여부를 판단할 수 있다.
• 등록된 결함은 검토 과정에서 결함이 아닌 것으로 판단되어 Reject될 수도 있다.

Failure

• 소프트웨어를 실행했을 때 실제 결과가 기대한 결과와 다르게 나타나는 현상이다.
• 내부에 존재하던 Defect가 특정 조건에서 실행되면서 외부로 나타난 결과이다.
• 이슈

Incident

• 테스트 중 발견되어 추가적인 확인이나 조사가 필요한 상황이다.
• 결함뿐 아니라 개선사항이나 원인 확인이 필요한 이상 현상도 포함될 수 있다.

💡 Defect와 Failure의 관계

Failure는 Defect에 의해 발생할 수 있지만, Defect가 존재한다고 해서 반드시 Failure가 발생하는 것은 아니다.

특정 조건에서만 실행되는 코드에 Defect가 존재한다면 해당 조건이 실행되기 전까지는 Failure가 나타나지 않을 수도 있다.

🪺 흐름으로 이해하기

• Error = 사람이 한 실수
• Defect = 그 실수가 산출물에 들어간 잘못되거나 누락된 부분
• Failure = 그 결함이 실제 실행 중 외부로 나타난 현상
• Incident = 테스트 중 발견되어 추가 확인이 필요한 상황

Error(사람의 실수) → Defect(잘못 만들어진 부분) → Failure(실행 중 실제 문제)

위 흐름은 개념을 쉽게 이해하기 위한 대표적인 관계이다. Incident는 위 흐름의 단계라기보다, 테스트 중 발견된 "확인이 필요한 상황"으로 이해하면 쉽다..!

5. 소프트웨어 테스트의 일반적인 원리

소프트웨어 테스트에는 기본적으로 이해해야 하는 7가지 원리가 있다.

① 테스팅은 결함이 존재함을 밝히는 활동

• 테스트를 통해 결함이 존재한다는 것은 확인할 수 있지만, 결함이 없다는 것은 증명할 수 없다.
• 테스트가 모두 통과했다고 해서 소프트웨어에 결함이 하나도 없다는 의미는 아니다.
• 테스트한 범위와 조건 안에서 결함이 발견되지 않았다는 의미에 가깝다.

② 완벽한 테스팅(Exhaustive Testing)은 불가능

• 모든 입력값, 실행 경로, 환경, 타이밍을 전부 테스트하는 것은 현실적으로 불가능하다.
• 따라서 제한된 시간과 비용 안에서 위험도와 중요도가 높은 부분부터 테스트하는 Risk-based Testing이 필요하다.

③ 테스팅은 개발 초기에 시작 (Early Testing)

• 테스트는 개발이 모두 끝난 이후에만 수행하는 활동이 아니다.
• 요구사항과 설계 단계에서도 문서를 검토하거나 Test Case를 작성하면서 문제를 발견할 수 있다.
• 결함은 늦게 발견할수록 영향을 받는 범위와 수정 비용이 커질 수 있으므로 가능한 한 개발 초기에 발견하는 것이 중요하다.

④ 결함 집중(Defect Clustering) ★

• 소프트웨어의 모든 영역에서 결함이 동일하게 발생하는 것은 아니다.

• 일부 기능이나 모듈에 많은 결함이 집중될 수 있다.
  결함이 집중될 가능성이 높은 영역의 예는 다음과 같다.

  • 새롭게 적용한 기술
  • 복잡한 로직
  • 변경이 자주 발생한 기능
  • 과거에 결함이 많이 발생한 기능

  따라서 결함 발생 가능성이 높은 영역을 파악하여 테스트 우선순위에 반영할 수 있다.

⑤ 살충제 패러독스(Pesticide Paradox) ★

• 같은 테스트 케이스만 반복하면 새로운 결함을 발견하기 어려워질 수 있다.

• 따라서 기존 테스트 케이스를 지속적으로 검토하고 새로운 테스트 관점을 추가해야 한다.

  • 새로운 Test Case 추가
  • 기존 Test Case 수정
  • 새로운 입력값과 데이터 추가
  • 사용자 행동 관점 추가
  • 경험 기반 테스트 활용

  즉, 테스트 역시 동일한 방법을 반복하는 것에 그치지 않고 지속적으로 개선할 필요가 있다.

⑥ 테스팅은 정황(Context)에 의존적

• 모든 소프트웨어를 동일한 방법과 강도로 테스트할 수는 없다.

• 소프트웨어의 성격과 사용 환경에 따라 적절한 테스트 전략이 달라질 수 있다.
  다음과 같은 조건에 따라 테스트 전략이 달라질 수 있다.

  • 서비스의 목적
  • 사용자
  • 사용 환경
  • 장애 발생 시 영향도
  • 비즈니스 중요도
  • 관련 법규나 안전 요구사항

  ex. 일반적인 쇼핑몰과 의료 시스템은 오류 발생 시 영향도가 다르기 때문에 동일한 수준의 테스트를 적용할 수 없다.

⑦ 오류-부재의 궤변

• 결함이 없거나 적다고 해서 반드시 좋은 소프트웨어라고 할 수는 없다.
• 소프트웨어가 오류 없이 동작하더라도 사용자의 요구사항이나 실제 사용 목적을 만족하지 못한다면 좋은 품질의 제품이라고 보기 어렵다.
• 즉, 결함이 없는 것과 사용자의 요구를 만족하는 것은 다른 문제이다.

따라서 테스트에서는 발견한 결함의 개수만 보는 것이 아니라 프로젝트에서 요구하는 품질 기준과 사용자 요구를 충족하는지도 함께 확인해야 한다.