QA 테스팅/ISTQB Syllabus

2장 소프트웨어 개발수명주기(SDLC)와 테스팅

시계속세상은아직돌아가는중 2024. 8. 13. 14:35

2.1. 소프트웨어 개발수명주기(SDLC)에서의 테스팅

소프트웨어 개발수명주기(SDLC) 모델은 상위 수준에서 소프트웨어 개발 프로세스를 추상화해서 표현한 것이다.

 

소프트웨어 개발수명주기(SDLC) 모델은 개발 프로세스의 여러 단계와 활동 유형이 논리적, 시간 상으로 서로 어떻게 연관되는지 정의한다. 소프트웨어 개발수명주기(SDLC) 모델의 예로 순차적 개발 모델 (예: 폭포수 모델, V-모델), 반복적 개발 모델(예: 나선형 모델, 프로토타이핑), 점진적 개발 모델(예: 통합 프 로세스) 등이 있다.

 

소프트웨어 개발 프로세스 내 일부 활동을 구체적인 소프트웨어 개발 방법과 애자일 실천법으로 설명하 기도 한다. 예를 들면, 인수 테스트 주도 개발(ATDD), 행위 주도 개발(BDD), 도메인 주도 설계(DDD), 익스 트림 프로그래밍(XP), 기능 주도 개발(FDD), 칸반(Kanban), 린(lean) IT, 스크럼(Scrum), 테스트 주도 개발 (TDD) 등이 여기에 해당한다.

 

2.1.1. 소프트웨어 개발수명주기(SDLC)가 테스팅에 미치는 영향

(K2)소프트웨어 개발수명주기(SDLC)가 또는 선택된 소프트웨어 개발수명주기가 테스팅에 미치는 영향을 설명할 수 있다

-> 이해

 

 

 

테스팅의 성공을 위해 소프트웨어 개발수명주기(SDLC)에 맞는 조정이 필요하다.

소프트웨어 개발수명주 기(SDLC) 모델의 선택은 다음에 영향을 미친다

 

• 테스트 활동 범위 및 시기(예: 테스트 레벨 및 테스트 유형)

• 테스트 문서 상세화 수준

• 테스트 기법 및 테스트 접근법 선택

• 테스트 자동화 범위

• 테스터의 역할과 책임

 

일반적으로 순차적 개발 모델에서 테스터는 초기 단계에서 요구사항 리뷰, 테스트 분석과 설계에 참여 한다. 실행 가능한 코드는 보통 개발 후반에 생성되므로, 동적 테스팅은 소프트웨어 개발수명주기(SDLC) 초기에 수행하기 어려운 경우가 많다.

 

애자일 소프트웨어 개발에서는 프로젝트의 어느 시점에도 변화가 생길 수 있다고 가정한다. 따라서 애자일 프로젝트는 리그레션 테스팅을 수월하게 하는 가벼운 작업 산출물과 테스트 자동화를 선호하게 된다. 또한, 수동 테스팅도 사전 테스트 분석과 설계가 필요하지 않은, 경험 기반 테스트 기법으로 진행하는 경향이 있다.

 

2.1.2. 소프트웨어 개발수명주기(SDLC)와 우수한 테스팅 프랙티스

(K1)  모든 소프트웨어 개발수명주기(SDLC)에 적용되는 좋은 테스팅 프랙티스를 상기할 수 있다 -> 암기

 

• 모든 소프트웨어 개발 활동에 상응하는 테스트 활동을 두어, 모든 개발 활동이 품질 제어의 대상이 되게 한다.

• 테스트 레벨(2.2.1 참조)마다 구체적이면서 독립적인 테스트 목적을 설정해, 중복은 피하고, 적절 하면서 포괄적인 테스팅이 가능하게 한다.

• 특정 테스트 레벨을 위한 테스트 분석과 설계를 소프트웨어 개발수명주기(SDLC)의 상응하는 각 개발 단계에서 시작해, (테스팅 원리 중) 조기 테스팅 원칙을 준수할 수 있게 한다.

• 테스터가 문서 초안이 가용한 즉시 작업 산출물 리뷰에 참여하도록 해서, 시프트-레프트 전략 지원을 위한 조기 테스팅과 결함 발견이 가능하도록 한다.

 

2.1.3. 소프트웨어 개발 주도를 위한 테스팅

(K1)  개발에서 테스트 우선 접근법의 예를 들 수 있다 -> 암기

 

테스트 주도 개발, 인수 테스트 주도 개발, 행위 주도 개발은 서로 유사한 개발 접근법으로 개발 방향 결정을 위한 수단으로 테스트를 정의한다.

 

이런 접근법은 코드 작성 전에 테스트를 정의하므로, 조기 테 스팅 원리(1.3 참조)를 구현하고 시프트-레프트 접근법(2.1.5 참조)을 따르게 한다.

 

테스트 주도 개발(TDD) (광범위한 소프트웨어 설계 대신) 테스트 케이스를 통해 코딩 주도(Beck 2003)
테스트를 먼저 작성하고, 이를 충족하도록 코드를 작성한 다음, 테스트와 코드를 리팩토링
인수 테스트 주도 개발(ATDD) 시스템 설계 프로세스 중 인수 조건에서 테스트 도출(Gärtner 2011)
테스트는 해당 테스트를 만족해야 할 애플리케이션 영역을 개발하기 전에 작성
행위 주도 개발(BDD) 애플리케이션의 기대 동작을 이해관계자가 이해하기 쉽도록, 간단한 자연어로 작성해 테스트 케이스로 표현 - 일반적으로 Given/When/Then 형태를 사용(Chelimsky 2010)

이후 테스트 케이스는 자동으로 실행 가능한 테스트로 변환

 

위의 모든 접근법에서 테스트는 향후 적용/리팩토링 시 코드 품질 보장을 위해 자동화 테스트로 유지 가능

 

2.1.4. 데브옵스(DevOps)와 테스팅

(K2)  DevOps가 테스팅에 미치는 영향을 요약할 수 있다 -> 이해

CI/CD 구축 및 버그 발생 시 Slack등과의 연동으로 알림을 받던 개발 과정도 기억해보자

 

데브옵스는 개발(테스팅 포함)과 운영이 협력해 공통된 목표를 달성하도록 시너지 창출을 목표로 하는 조직 차원의 접근법

데브옵스는 개발(테스팅 포함)과 운영이 가진 생각의 차이를 줄임과 동시에 각 자 하는 일의 가치를 서로 동등하게 보도록 조직문화의 변화가 필요하다.

데브옵스는 팀의 자율성, 빠른 피드백, 통합 도구 체인, 지속적 통합(CI)과 지속적 배포(CD)와 같은 기술 실천법을 장려한다. 팀은 데브 옵스 배포 파이프라인(pipeline)을 통해 높은 품질의 코드를 더 빠르게 빌드/테스트/릴리스할 수 있다

 

테스팅 관점 • 코드 품질, 그리고 변경사항이 기존 코드에 악영향을 미치는지 여부에 대한 빠른 피드백을 제공한다.

• 지속적 통합은 개발자가 컴포넌트 테스트 및 정적분석과 함께 높은 품질의 코드를 제출하도록 장려함으로써 시프트-레프트 테스팅 접근법(2.1.5 참조)을 장려한다.

• 안정적인 테스트 환경 구축을 촉진하는 지속적 통합(CI)/지속적 배포(CD)와 같은 자동화 프로세스를 장려한다.

• 비기능 품질 특성(예: 성능, 신뢰성)의 가시성을 높여준다.

• 배포 파이프라인을 통한 자동화로 반복적인 수동 테스팅의 필요성을 줄여준다.

• 자동 리그레션 테스트의 규모와 범위가 늘어나 리그레션 발생 리스크가 최소화된다.
리스크 및 어려움 • 데브옵스 배포 파이프라인을 정의하고 설정해야 한다.

• 지속적 통합/지속적 배포 도구를 도입하고 유지보수해야 한다.

• 테스트 자동화를 위한 추가 자원이 필요하며, 그것을 설정 및 유지보수하기가 어려울 수 있다.

 

데브옵스는 높은 수준의 테스팅 자동화를 동반하지만, 수동 테스팅 또한 (특히 사용자 관점에서) 여전히 필요하다.

 

2.1.5. 시프트-레프트 접근법

(K2)  시프트-레프트 접근법을 설명할 수 있다 -> 이해

 

잠재적으로 값 비싼 지연 또는 에스컬레이션을 피하기 위해 활동을 작업 소스에 더 가깝게 이동하는 데 중점을 둔 작업 관리 방법이다.

 

조기 테스팅 원리(1.3 참조)는 테스트를 소프트웨어 개발수명주기(SDLC) 초기에 수행하도록 하는 접근법 이기 때문에 시프트-레프트라고 지칭한다.

 

시프트-레프트는 테스트를 더 일찍 수행해야 한다는 것을 의미하지만(예: 코드가 구현되거나 컴포넌트가 통합될 때까지 기다리지 않고), 그렇다고 소프트웨어 개발수명주기(SDLC) 후반의 테스트를 무시해도 된다는 의미는 아니다.

 

• 테스팅 관점에서 명세를 리뷰한다.

이런 명세 리뷰 활동을 통해 모호성, 불완전성, 불일치 등 잠 재적인 결함을 발견하는 경우가 많다.

 

• 코드를 작성하기 전에 테스트 케이스를 작성하고, 코드 구현 중 코드를 테스트 하네스(test harness)에서 실행한다.

 

• 빠른 피드백을 제공하고, 코드 저장소에 소스 코드를 저장할 때 자동 컴포넌트 테스트를 함께 제출하도록 하는 지속적인 통합, 가능하다면 지속적인 배포까지 적용한다.

 

• 동적 테스팅 전 또는 자동화된 프로세스의 일부로 소스 코드의 정적분석을 완료한다.

 

• 가능한 한 컴포넌트 테스트에서부터 비기능 테스팅을 수행한다.

비기능 테스트는 완성 시스템 과 실제 환경을 대변하는 테스트 환경이 가용한 소프트웨어 개발수명주기(SDLC) 후반에 수행하 는 경향이 있으므로, 이는 일종의 시프트-레프트가 된다.

 

2.1.6. 회고 및 프로세스 개선

(K2)  프로세스 개선을 위한 방법으로 회고의 사용을 설명할 수 있다

프로젝트진행 당시 프로젝트 진행 중 매 주 중간평가 및 코드리뷰/회고와 종료 이후 KPT회고를 진행했던 것을 기억해보자. Keep(유지해야할 것) Problem(문제) Try(해결책 및 시도할 것) 이 원리와 다르지 않다.

또한 회고를 통한 의견 나눔은 팀원간의 결속 또한 증가한다.

 

회고(“프로젝트 종료 후 회의” 또는 프로젝트 회고라고도 함)는 프로젝트나 반복 주기가 끝날 때, 릴리스 마일스톤에서, 또는 필요시 진행할 수 있다. 회고의 시기와 구성은 사용 중인 소프트웨어 개발수명주기 (SDLC) 모델에 따라 달라진다. 이 회의에서 참가자(테스터 외에도 개발자/설계자/제품 소유자/비즈니스 분석가 등)는 다음에 대해 논의한다

 

• 무엇이 성공적이었고, 유지해야 할 것은 무엇인가?

• 무엇이 부족했고, 개선할 수 있는 점은 무엇인가?

• 향후 개선 사항을 도입하고 성공 요소를 유지하려면 어떻게 해야 하는가?

 

결과는 기록해야 하며, 이를 테스트 완료 보고서(5.3.2 참조)에 포함하는 경우가 많다. 회고는 지속적인 개선을 성공적으로 구현하기 위해 반드시 필요하며, 권장된 모든 개선 사항에 대한 후속 조치가 이루어 지는 것이 중요하다. 테스팅 관점에서 일반적인 이점은 다음과 같다

 

• 테스트 효과성/효율성 향상(예: 프로세스 개선 권고 사항 구현을 통해)

• 테스트웨어 품질 향상(예: 테스트 프로세스를 함께 검토함으로써)

• 팀의 결속 및 학습 향상(예: 문제를 제기하고, 개선점을 제안할 기회를 제공함으로써)

• 테스트 베이시스 품질 개선(예: 요구사항의 범위나 품질에서 부족한 점을 발견하고, 수정함으로써)

• 개발과 테스팅 간의 협업 개선(예: 정기적으로 협업 과정을 검토하고 최적화함으로써)

 

2.2. 테스트 레벨과 테스트 유형

테스트 레벨은 함께 구성하고 관리하는 테스트 활동 집합이다.

각 테스트 레벨은 특정 개발 단계의 소 프트웨어와 관련해 수행하는 테스트 프로세스의 인스턴스(instance)이다.

단계에 따라 소프트웨어는 개별 컴포넌트부터 완성된 시스템에 이를 수 있으며, 경우에 따라서는 시스템의 시스템일 수도 있다. 테스트 레벨은 소프트웨어 개발수명주기(SDLC) 내의 다른 활동과 연관성을 가진다.

순차적 소프트웨어 개발수명주기(SDLC) 모델은 한 레벨의 완료 조건이 다음 레벨의 시작 조건에 포함되도록 테스트 레벨을 정의하는 경우가 많다. 또 이것과는 다른 반복적 모델도 있다. 개발 활동이 여러 테스트 레벨에 걸쳐 진 행되고, 시간이 지나면서 테스트 레벨이 서로 겹치기도 한다. 테스트 유형은 특정 품질 특성 관련 테스트 활동의 집합으로, 이런 테스트 활동은 대부분 모든 테스트 레벨에서 수행할 수 있다.

 

2.2.1. 테스트 레벨

FL-2.2.1 (K2)  테스트 레벨을 구별할 수 있다 -> 이해

이해지만 해당 용어들의 정의를 암기하지 않으면 안된다.

 

컴포넌트 테스팅(단위 테스팅) 컴포넌트를 개별적으로 테스트하는 데 중점

테스트 하네스 또는 단위 테스트 프레임워크와 같은 구체적인 지원 수단이 필요한 경우가 많다. 컴포넌트 테스팅은 일반적으로 개발자가 자신의 개발 환경에서 수행
컴포넌트 통합 테스팅
(단위 통합 테스팅)		 컴포넌트 간의 인터페이스와 상호 작용 을 테스트하는 데 중점

컴포넌트 통합 테스팅은 상향식, 하향식, 빅뱅 등 통합 전략 접 근법에 따라 크게 달라진다.
시스템 테스팅 전체 시스템 또는 제품의 전반적인 동작과 기능에 중점


엔드투엔드 (end-to-end) 동작에 대한 기능 테스팅과 품질 특성에 대한 비기능 테스팅을 포함하는 경우가 많다. 실제 환경을 대변하는 테스트 환경에서 완성된 시스템으로 테스트하는 것을 선호하는 비 기능 품질 특성도 있다(예: 사용성). 서브-시스템에 대한 시뮬레이션을 사용하기도 한다. 시스템 테스팅은 독립 테스트팀이 수행할 수 있으며, 시스템의 명세와 관련이 있다.
시스템 통합 테스팅 다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는 데 중점


시스템 통합 테스팅은 가급적 운영 환경과 유사한 적절한 테스트 환 경을 사용
인수 테스팅 밸리데이션과 배포할 준비, 즉 시스템이 사용자의 비즈니스에 필요한 사항을 충족하는지를 확인하는 데 중점


인수 테스팅은 실제 사용자가 수행하는 것이 이상적이다. 인수 테스팅의 주요 유형으로 사용자 인수 테스팅(UAT), 운영 인수 테스팅, 계약 및 규제 인수 테스팅, 알파 테스팅, 베타 테스팅 등이 있다.

 

테스트 레벨은 테스트 활동의 중복을 피하기 위해 다음과 같은 다양한 속성을 고려

 

• 테스트 대상

• 테스트 목적

• 테스트 베이시스

• 결함과 장애

• 접근법과 역할

 

2.2.2 테스트 유형

(K2)  테스트 유형을 구별할 수 있다 -> 이해

이해지만 곧 암기

 

기능 테스팅 컴포넌트 또는 시스템이 수행해야 하는 기능을 평가

테스트 대상이 ‘무엇을’ 해야 하는지를 의미
주요 목적은 기능 성숙도(완전성), 기능 정확성, 기능 타당성(적 합성)을 확인
비기능 테스팅 컴포넌트 또는 시스템의 기능 특성 이외의 속성을 평가
비기능 테스팅은 “시스템 이 얼마나 잘 동작하는지” 테스트

• 수행 효율성(Performance efficiency)
• 호환성(Compatibility)
• 유용성(Usability)
• 신뢰도(Reliability)
• 보안(Security)
• 유지 가능성(유지 관리성)(Maintainability)
• 이동성(Portability)


비기능 결함을 늦게 발견하면 프로젝트의 성공에 심각한 위협이 될 수 있다.
블랙박스 테스팅 명세를 기반으로 하며, 테스트 대상 외부에 있는 문서에서 테스트를 도출한다.
블랙박스 테스팅의 주요 목적은 명세와 비교해 시스템의 동작을 확인한다.
화이트박스 테스팅 구조 기반

시스템의 구현 또는 내부 구조(예: 코드, 아키텍처, 워크 로우, 데이터 플로우)에서 테스트를 도출한다. 화이트박스 테스팅의 주요 목적은 테스트를 통해 내부 구 조를 인수에 필요한 수준까지 충분히 커버하는 것이

 

위 네 가지 테스트 유형은 모든 테스트 레벨에 적용할 수 있지만, 레벨마다 관심의 대상은 다를 수 있다. 언급한 모든 테스트 유형을 위한 테스트 컨디션과 테스트 케이스를 도출하기 위해 다양 한 테스트 기법을 사용할 수 있다.

 

2.2.3. 확인 테스팅 및 리그레션 테스팅

(K2)  확인 테스팅을 리그레션 테스팅과 구별할 수 있다 -> 이해

 

확인 테스팅 원래 결함이 성공적으로 수정됐는지 확인


• 결함으로 인해 이전에 실패했던 모든 테스트 케이스를 실행한다.
• 결함을 수정하기 위해 변경한 사항을 확인하는 새로운 테스트를 추가한다.


결함을 수정하는 데 시간이나 비용이 부족한 경우, 결함으로 생긴 장애를 재현하기 위한 절차를 거쳐 장애가 발생하지 않는지 확인하는 것만으로 확인 테스팅이 끝날 수도 있다.
리그레션 테스팅 변경으로 인해 부정적인 영향이 없었는지 확인

이미 확인 테스팅이 끝 난 수정 사항도 여기서 말하는 변경에 포함

부정적인 영향은 변경이 이루어진 컴포넌트 자체, 같은 시스템의 다른 컴포넌트, 또는 연결된 다른 시스템에도 영향을 미칠 수 있다. 리그레션 테스팅은 테스트 대상 자체에만 국한되지 않고, 환경과도 관련이 있을 수 있다. 리그레션 테스팅의 범위를 최적화 하기 위해 영향도 분석을 먼저 수행하는 것이 좋다. 영향도 분석은 소프트웨어의 어느 부분이 영향을 받을 수 있는지 보여준다.

그레션 테스트 스위트는 반복적으로 실행되며, 반복 주기 또는 릴리스 때마다 리그레션 테스트 케이 스 수가 늘어나게 되므로, 리그레션 테스트는 자동화하기 매우 적합한 대상

테스트의 자동 화는 프로젝트 초기에 시작이 바람직

데브옵스(2.1.4 참조)와 같이 지속적 통합을 사용하는 경우, 자동 리그레션 테스트를 포함하는 것이 좋은 프랙티스이다. 상황에 따라 여러 테스트 레벨의 리그레션 테스 트가 포함될 수 있다.

 

어떤 테스트 레벨이라도 해당 레벨에서 결함을 수정하거나 변경을 적용한 경우, 테스트 대상에 대한 확 인 테스팅과 리그레션 테스팅이 필요하다.

 

 

2.3. 유지보수 테스팅

(K2)  유지보수 테스팅과 유발요인을 요약할 수 있다

 

유지보수에는 여러 범주가 있다. 문제를 수정하기 위한 유지보수도 있고, 환경 변화에 적응하거나, 성능 또는 유지보수성(자세한 내용은 ISO/IEC 14764 참조)을 개선하기 위한 것도 있기 때문에, 유지보수는 계 획된 릴리스/배포 또는 계획되지 않은 릴리스/배포(핫픽스) 모두와 연관돼 있다.

 

변경 전에 영향도 분석 을 수행해 시스템의 다른 영역에 미칠 잠재적 영향을 변경사항 결정에 참고할 수 있다. 운용 환경에서 시스템의 변경사항을 테스트하는 것에는 변경 구현의 성공을 검증하는 것과, 변경되지 않은 시스템 영 역(보통은 시스템 대부분)에서 발생할 수 있는 리그레션을 확인하는 작업이 모두 포함된다.

 

유지보수 테스팅의 범위는 일반적으로 다음에 따라 달라진다

 

• 변경의 리스크 수준

• 기존 시스템의 크기

• 변경사항의 크기

 

유지보수와 유지보수 테스팅의 계기는 다음과 같이 분류할 수 있다:

 

• 계획된 개선사항(즉, 릴리스 기반), 수정을 위한 변경, 핫픽스(hot-fixes)와 같은 수정사항

 

• 운영 환경의 업그레이드나 마이그레이션(예: 한 플랫폼에서 다른 플랫폼으로)하는 경우, 변경된 소프트웨어뿐만 아니라 새로운 환경 관련 테스트가 필요할 수 있으며, 다른 애플리케이션의 데 이터를 유지보수 중인 시스템으로 마이그레이션할 때, 데이터 변환 테스트가 필요할 수 있다. 

 

• 애플리케이션의 수명이 다하는 등의 단종. 시스템을 단종할 때 데이터 보존 기간이 길면 데이터 보관(archiving) 테스팅이 필요할 수 있다. 보관 기간 중 데이터가 필요한 경우를 대비해, 보관 이후 복원 및 복구 절차 테스팅이 필요할 수 있다.

저작자표시 비영리 변경금지 (새창열림)