소프트웨어 개발 수명 주기 전반에서의 테스트

키워드

인수 테스팅(acceptance testing), 블랙박스 테스팅(black-box testing), 컴포넌트 통합 테스팅(component integration testing), 컴포넌트 테스팅(component testing), 확인 테스팅(confirmation testing), 기능 테스팅(functional testing), 통합 테스팅(integration testing), 유지보수 테스팅(maintenance testing), 비기능 테스팅(non-functional testing), 회귀 테스팅(regression testing), 시프트-레프트(shift-left), 시스템 통합 테스팅(system integration testing), 시스템 테스팅(system testing), 테스트 레벨(test level), 테스트 대상(test object), 테스트 유형(test type), 화이트박스 테스팅(white-box testing)

---

1. 소프트웨어 개발 생명주기에서의 테스트

소프트웨어 개발 생명주기(SDLC) 모델은 높은 수준에서 소프트웨어 개발 과정을 추상화한 단어다. SDLC 모델은 개발 과정에서 수행되는 다양한 단계와 활동이 논리적/시간적으로 어떻게 진행되는지를 정의한다.
SDLC 모델의 예로는 다음이 있다.

• 순차적 개발 모델: 폭포수 모델(waterfall model 흔히 '워터폴' 방식이라고 일컫는다), V-모델
• 반복적 개발 모델: 나선형 모델(spiral model), 프로토타이핑
• 증분적 개발 모델: 통합 프로세스(Unified Process)

소프트웨어 개발 프로세스 내의 일부 활동은 더 세부적인 소프트웨어 개발 방법론이나 애자일 실천 방법으로 설명될 수 있다. 예로는 다음이 있다.

• 인수 테스트 주도 개발(ATDD)
• 행동 주도 개발(BDD)
• 도메인 주도 설계(DDD)
• 극단적 프로그래밍(XP)
• 기능 주도 개발(FDD)
• 칸반(Kanban)
• Lean IT
• 스크럼(Scrum)
• 테스트 주도 개발(TDD)

---

1-1. 소프트웨어 개발 생명주기가 테스트에 미치는 영향

테스트는 SDLC에 맞춰 조정되어야 성공할 수 있다. 어떤 SDLC가 선택되는지에 따라, 다음 요소에 영향을 미친다.

• 테스트 활동의 범위와 시기(예: 테스트 레벨 및 테스트 유형)
• 테스트 문서화의 상세 수준
• 테스트 기법과 접근 방식의 선택
• 테스트 자동화의 범위
• 테스터의 역할과 책임

순차적 개발 모델에서는 초기 단계에서 테스터가 주로 요구사항 리뷰, 테스트 분석 및 테스트 설계에 참여한다. 실행 가능한 코드는 일반적으로 후반 단계에서 생성되므로, SDLC 초기에 동적 테스트를 수행하기 어렵다.
반복적 및 증분적 개발 모델에서는 각 반복(iteration)마다 작동하는 프로토타입이나 제품 증분을 제공한다고 가정한다. 이는 각 반복에서 모든 테스트 레벨에서 정적 및 동적 테스트가 수행될 수 있음을 의미한다. 증분의 빈번한 제공은 빠른 피드백과 광범위한 회귀 테스트를 요구한다.
애자일 소프트웨어 개발은 프로젝트 전반에서 변화가 발생할 수 있음을 전제로 한다. 따라서 애자일 프로젝트에서는 경량화된 산출물 문서화와 회귀 테스트를 용이하게 하기 위한 광범위한 테스트 자동화를 선호한다. 또한 대부분의 수동 테스트는 사전 테스트 분석 및 설계가 많이 필요하지 않은 경험 기반 테스트 기법을 사용하여 수행되는 경향이 있다.

---

1-2. 소프트웨어 개발 생명주기와 우수 테스트 실천 방법

선택된 SDLC 모델에 상관없이 우수한 테스트 실천 방법은 다음을 포함한다.

• 소프트웨어 개발 활동마다 이에 상응하는 테스트 활동이 있어 모든 개발 활동이 품질 관리 대상이 된다.
• 각 테스트 레벨은 특정하고 고유한 테스트 목표를 가지고 있어 테스트가 적절하게 포괄적이면서도 중복을 피할 수 있다.
• 특정 테스트 레벨에 대한 테스트 분석 및 설계는 SDLC의 해당 개발 단계 동안 시작되어 조기 테스트 원칙을 준수한다.
• 테스터는 문서 초안이 준비되는 즉시 작업 산출물을 검토에 참여하여, 이러한 조기 테스트와 결함 검출이 시프트-레프트 전략을 지원하도록 한다.

---

1-3. 테스팅이 소프트웨어 개발을 이끄는 역할일 때

TDD, ATDD, BDD는 테스트를 개발의 지침으로 삼는 개발 접근 방식이다. 이들은 모두 조기 테스트 원칙을 구현하고 시프트-레프트 접근법을 따르며, 테스트를 코드 작성 전에 정의한다. 이 접근 방식들은 반복적 개발 모델을 지원한다.

• 테스트 주도 개발(TDD):
  • 테스트 케이스를 통해 코딩을 지시한다.
  • 테스트를 먼저 작성한 후, 테스트를 만족시키기 위해 코드를 작성하며, 이후 테스트와 코드를 리팩터링한다.
• 인수 테스트 주도 개발(ATDD):
  • 시스템 설계 과정의 일부로서 인수 기준에서 테스트를 도출한다.
  • 테스트를 먼저 작성하고, 해당 테스트를 만족시키는 애플리케이션 부분을 개발한다.
• 행동 주도 개발(BDD):
  • 이해관계자가 쉽게 이해할 수 있는 자연어 형식(보통 Given/When/Then 포맷)을 사용하여 애플리케이션의 원하는 동작을 표현한다.
  • 테스트 케이스는 실행 가능한 테스트로 자동 변환된다.

위의 모든 접근 방식에서 작성된 테스트는 자동화된 테스트로 유지되어, 향후 코드 품질을 보장한다.

---

1-4. DevOps와 테스트

DevOps는 개발(테스트 포함)과 운영 간의 협력을 통해 공동 목표를 달성하고 시너지를 창출하는 조직적 접근법이다.  개발과 운영 간의 간극을 줄이고 두 기능에 동등한 가치를 부여하기 위해 조직 내 문화적 변화가 요구된다.

DevOps는 팀 자율성, 빠른 피드백, 통합된 도구 체인, 지속적 통합(CI) 및 지속적 배포(CD)와 같은 기술적 실천을 촉진한다. 이를 통해 팀은 DevOps 전달 파이프라인을 통해 고품질 코드를 더 빠르게 구축, 테스트 및 릴리스할 수 있다.

테스트 관점에서 DevOps의 주요 이점은 다음과 같다.

• 코드 품질과 변경 사항이 기존 코드에 미치는 영향을 빠르게 피드백 받을 수 있다.
• CI는 개발자가 컴포넌트 테스트와 정적 분석을 통해 고품질 코드를 제출하도록 장려하며, 시프트-레프트 접근법을 촉진한다.
• CI/CD와 같은 자동화된 프로세스는 안정적인 테스트 환경을 구축하는 데 기여한다.
• 비기능 품질 특성(예: 성능, 신뢰성)에 대한 시야를 넓힌다.
• 전달 파이프라인을 통한 자동화는 반복적인 수동 테스트의 필요성을 줄인다.
• 자동화된 회귀 테스트의 규모와 범위로 인해 회귀 리스크가 최소화된다.

그러나 DevOps에도 위험과 과제가 있다.

• DevOps 전달 파이프라인을 정의하고 구축해야 한다.
• CI/CD 도구를 도입하고 유지해야 한다.
• 테스트 자동화에는 추가 자원이 필요하며, 구축과 유지가 어려울 수 있다.

DevOps에서는 높은 수준의 자동화된 테스트를 수행하지만, 사용자 관점에서의 수동 테스트는 여전히 필요하다.

---

1-5. 시프트-레프트 접근법

조기 테스트(early test, 얼리 테스트) 원칙은 시프트-레프트(shift-left)로도 불리며, SDLC 초기에 테스트를 수행하는 접근법을 의미한다. 시프트-레프트는 개발 단계의 앞부분에서부터 테스트가 수행되어야 한다는 것을 뜻하지만, SDLC 후반의 테스트 또한 소홀히 해서는 안 된다.

시프트-레프트를 실현하는 몇 가지 우수 실천 방법은 다음과 같다.

• 테스트 관점에서 명세를 검토한다. 명세 검토는 모호성, 불완전성, 불일치와 같은 잠재적 결함을 발견하는 데 도움을 준다.
• 코드를 작성하기 전에 테스트 케이스를 작성하고, 코드 구현 중 테스트 하네스에서 코드를 실행한다.
• 지속적 통합(CI) 및 지속적 배포(CD)를 활용하여 소스 코드 제출 시 빠른 피드백과 자동화된 컴포넌트 테스트를 제공한다.
• 동적 테스트 이전 또는 자동화된 프로세스의 일부로 소스 코드의 정적 분석을 수행한다.
• 가능한 경우, 컴포넌트 테스트 단계에서 비기능 테스트를 시작한다.

시프트-레프트 접근법은 초기 단계에서 추가 교육, 노력 및 비용이 필요할 수 있지만, 이후 단계에서 노력과 비용을 절약할 수 있다.

---

1-6. 회고 및 프로세스 개선

회고(레트로스펙티브)는 프로젝트나 반복(iteration)이 종료되거나 릴리스 마일스톤에서, 또는 필요 시 개최된다. 회고에서 참가자들은 다음을 논의한다.

• 성공적이었던 점과 유지해야 할 점은 무엇인가?
• 성공적이지 않았고 개선이 필요한 점은 무엇인가?
• 개선 사항을 통합하고 성공 요소를 유지하기 위해 무엇을 해야 하는가?

회고 결과는 기록되어 테스트 완료 보고서의 일부가 된다. 회고는 지속적 개선을 성공적으로 구현하는 데 필수적이며, 권장된 개선 사항을 추적하는 것이 중요하다.

테스트에 대한 전형적인 이점은 다음과 같다.

• 테스트 효과성/효율성 증가(예: 프로세스 개선 제안 구현)
• 테스트웨어 품질 향상(예: 테스트 프로세스를 공동 리뷰한 결과)
• 팀 결속력 및 학습 증진(예: 문제를 제기하고 개선 사항을 제안할 기회 제공)
• 테스트 베이시스 품질 향상(예: 요구사항의 부족한 부분 해결)
• 개발과 테스트 간 협력 개선(예: 협업을 정기적으로 리뷰 및 최적화)