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

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

소프트웨어 개발수명주기(SDLC) : 상위 수준에서 소프트웨어 개발 프로세스를 추상적으로 표현한 것

소프트웨어 개발수명주기 모델  : 개발 프로세스의 여러 단계와 활동 유형이 논리적, 시간상으로 서로 어떻게 연관되는지 정의한다.

 

SDLC  예 : 순차적 개발 모델(폭포수 모델, V-모델), 반복적 개발 모델(나선형 모델, 프로토타이밍), 점진적 개발 모델(통합 프로세스)등

 

소프트웨어 개발 프로세스 내 일부 활동을 구체적인 소프트웨어 개발 방법과 애자일 프랙티스로 설명하기도 한다.

인스 테스트 주도 개발(ATDD), 행위 주도 개발(BDD), 도메인 주도 설계(DDD), 익스트림 프로그래밍(XP), 기능 주도 개발(FDD), 칸반(kanban), 린(lean) IT, 스크럼(scrum), 테스트 주도 개발(TDD)등이 여기에 해당한다.

 

 

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

테스팅의 성공을 위해 소프트웨어 개발수명주기에 맞는 조정이 필요하다. 모델의 선택은 다음에 영향을 미친다.

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

- 테스트 문서 상세화 수준

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

- 테스트 자동화 범위

- 테스터의 역할과 책임

 

순차적 개발 모델 : 테스터는 초기 단계에서 요구사항 리뷰, 테스트 분석과 설계에 참여. 코드는 개발 후반에 생성되므로 소프트웨어 개발수명주기 초기에 수행하지 못할 수 있음

 

반복적 모델, 점진적 개발 모델 : 각 반복주기마다 동작하는 프토로타입이나 제품 증분이 만들어진다고 가정. 반복 주기마다 모든 테스트 레벨에서 정적 테스팅과 동적 테스팅을 수행할 수 있음, 증분을 자주 하기 위해서 빠른 피드백과 광범위한 리그레션 테스팅이 필요

 

애자일 소프트웨어 개발 : 프로젝트의 어느 시점에도 변화가 생길 수 있다고 가정. 애자일 프로젝트는 리그레션 테스팅을 수월하게 하는 가벼운 작업 산출물과 테스트 자동화를 선호. 수동 테스팅도 경험 기반 테스트 기법으로 진행하는 경향이 있음

 

 

소프트웨어 개발수명주기(SDLC)와 좋은 테스팅 프랙티스

선택한 SDLC 모델에 상관없이, 다음과 같은 좋은 테스팅 프랙티스가 있다.

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

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

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

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

 

 

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

테스트 주도 개발, 인스 테스트 주도 개발, 행위 주도 개발은 서로 유사한 개발 접근법으로 개발 방향 결정을 위한 수단으로 테스트를 정의한다. 각 접근법은 코드 작성 전에 테스트를 정의하므로, 조기 테스팅 원리와 시프트 레프트 접근법을 따르게 한다.

반복적 개발 모델을 지원하며, 다음과 같은 특징을 가진다.

 

테스트 주도 개발(TDD)

    - (광범위한 소프트웨어 설계 대신)테스트 케이스를 통해 코딩 주도

    - 테스트를 먼저 작성하고 이를 충족하도록 코드를 작성한 다음, 테스트와 코드를 리팩토링

 

인수 테스트 주도 개발(ATDD)

    - 시스템 설계 프로세스 중 인수 조건에서 테스트 도출

    - 테스트는 해당 테스트를 만족해야 할 애플리케이션 영역을 개발하기 전에 작성

 

행위 주도 개발(BDD)

    - 애플리케이션의 기대 동작을 이해관계자가 이해하기 쉽도록, 간단한 자연어로 작성해 테스트 케이스로 표현

      일반적으로 Given/When/Then 형태를 사용

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

 

위의 모든 접근법에서 테스트는 향후 구현/리팩토링 시 코드 품질 보장을 위해 자동화 테스트로 유지할 수 있다.

 

 

데브옵스(DevOps)와 테스팅

데브옵스(DevOps) : 소프트웨어 개발(Development)와 IT 운영(Operations)의 합성어로, 개발팀과 운영팀 사이의 장벽을 허물고 하나의 팀처럼 협력하여 소프트웨어를 더 빠르고 안정적으로 배포하기 위한 문화이자 철학이다.

 

데브옵스 : 개발과 운영이 협력해 공통된 목표를 달성하기 위한 시너지 창출을 목표로 하는 조직 차원의 접근법이다.

 

데브옵스는 개발(테스팅 포함)과 운영이 가진 생각의 차이를 줄입과 동시에 각자 하는 일의 가치를 서로 동등하게 보도록 하는 조직 문화의 변화가 필요하다. 데브옵스는 팀의 자율성, 빠른 피드백, 통합된 도구 체인, 지속적 통합(CI)과 지속적 배포(CD)와 같은 기술 프랙티스를 장려한다. 팀은 데브옵스 배포 파이프라인(pipeline)을 통해 높은 품질의 코드를 더 빠르게 빌드, 테스트, 릴리즈 할 수 있다.

 

테스팅 관점에서 데브옵스의 이점은 다음과 같다.

    - 코드 품질, 변경사항이 기존 코드에 악영향을 미치는지 여부에 대한 빠른 피드백을 제공한다.

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

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

    - 비기능 품질 특성(예 : 성능 효율성, 신뢰성)에 대한 가시성이 향상된다.

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

    - 자동 리그레션 테스트의 규모와 범위가 늘어나 리그레션 발생 리스크가 최소화된다.

 

** 지속적 통합(CI) : 개발자가 작업한 코드를 자주, 자동으로 통합하고 테스트

** 지속적 배포(CD) : CI를 통해 성공적으로 통합된 코드를 사용자에게 전달하는 과정을 자동화 하는 단계

 

데브옵스의 리스크 및 어려움은 다음과 같다

    - 데브옵스 배포 파이프라인을 정의하고 설정해야 한다.

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

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

 

데브옵스는 높은 수준의 테스팅 자동화를 동반하지만, 수동 테스팅 또한 여전히 필요하다.

 

 

시프트 레프트 접근법(Shift Left)

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

시프트 레프트 : 기본적으로 테스트를 더 일찍 수행해야 한다는 것을 의미(ex : 코드가 구현되거나 컴포넌트의 통합을 기다리지 않고), 그렇다고 개발수명주기 후반의 테스트를 무시해도 된다는 의미는 아니다.

 

다음과 같은 테스팅에서 시프트 레프트를 달성하기 좋다.

- 테스터 관점에서 명세를 리뷰한다. 명세 리뷰 활동을 통해 모호성, 불완전성, 불일치 등 잠재적 결함을 발견하는 경우가 많다.

- 코드를 작성하기 전에 TC를 작성하고, 코드 구현 중 코드를 테스트 하네스에서 실행한다.

- 빠른 피드백을 제공하고, 코드 저장소에 소스 코드를 저장할 때 자동 컴포넌트 테스트를 함께 제출하도록 하는 CI/CD를 적용한다.

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

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

 

시프트 레프트 접근법은 프로세스 초기에 훈련, 공수, 비용이 추가로 들지만, 프로세스 후반의 공수와 비용의 절감을 기대할 수 있다.

시프트 레프트 접근법을 위해서는 이해관계자들이 개념을 이해하고 받아들이는 것이 중요하다.

 

 

회고 및 프로세스 개선

회고 : 프로젝트나 반복 주기가 끝날 때, 릴리즈 마일스톤에서 또는 필요 시 진행할 수 있다. 회고의 시기와 구성은 사용중인 소프트웨어 개발수명주기 모델에 따라 달라진다. 이 회의에서 참가자는 다음에 대해 논의한다.

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

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

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

 

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

 

테스팅 관점에서 회고의 이점은 다음과 같다

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

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

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

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

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

 

 

 

 

테스트 레벨과 테스트 유형

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

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

단계에 따라 소프트웨어는 개별 컴포넌트부터 완성된 시스템에 이를 수 있으며, 경우에 따라서는 시스템의 시스템일수도 있다.

 

테스트 레벨 : 소프트웨어 개발수명주기 내의 다른 활동과 연관성을 가진다.

ex) 순차적 소프트웨어개발수명주기 모델 : 한 레벨의 완료 조건이 다음 레벨의 시작 조건에 포함되도록 테스트 레벨을 정의

ex) 반복적 모델 : 개발활동이 여러 테스트 레벨에 걸쳐 진행되고, 시간이 지나면서 테스트 레벨이 겹치기도 한다.

 

테스트 유형 : 특정 품질 특성 관련된 테스트 활동의 집합으로, 테스트 활동은 대부분 테스트 레벨에서 수행할 수 있다.

 

 

테스트 레벨

테스트 레벨은 총 다섯가지 레벨이 있다.

- 컴포넌트 테스팅(단위 테스팅) : 컴포넌트를 개별적으로 테스트, 테스트 하네스, 단위테스트 프레임워크 등을 사용, 개발자가 자신의 개발환경에서 수행

- 컴포넌트 통합 테스팅(단위 통합 테스팅) : 컴포넌트 간의 인터페이스와 상호 작용을 테스트하는데 중점을 둔다. 컴포넌트 통합                                                                      테스팅은 상향식, 하향식, 빅뱅 등 통합 전략에 따라 크게 달라진다.

- 시스템 테스팅 : 전체 시스템 또는 제품의 전반적인 동작과 기능에 중점을 둔다. 엔드투엔드 동작과 비기능 테스트가 많다.                                        서브-시스템에 대한 시뮬레이션을 사용하기도 한다.

                          시스템 테스팅은 독립된 테스트팀이 수행할 수 있고, 명세와 관련 있다.

- 시스템 통합 테스팅 : 다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는데 중점을 둔다.

                                 가급적 운영 환경과 유사한 적절한 테스트 환경을 사용한다.

- 인수 테스팅 : 밸리데이션과 배포할 준비, 시스템이 사용자의 비즈니스에 필요한 사항을 충족하는지를 확인하는 데 중점을 둔다.

                       인수 테스팅은 실제 사용자가 수행하는 것이 이상적이다.

                       유형으로는 사용자 인수 테스트, 운영 인수 테스트, 계약 인수 테스팅과 규제 인수 테스팅, 알파, 베타 테스팅이 있다.

 

 

테스트 유형

테스트 유형에는 네가지 테스트 유형이 있다.

기능 테스팅 : 컴포넌트, 시스템이 수행해야 하는 기능을 평가한다. 테스트 대상이 '무엇을' 해야 하는지 의미한다.

                     기능 테스팅의 주요 목적은 기능 성숙도(완전성), 기능 정확성, 기능 타당성을 확인하는 것이다.

비기능 테스팅 : 컴포넌트 또는 시스템의 기능 특성 이외의 속성을 평가한다. 비기능 테스팅은 "시스템이 얼마나 잘 동작하는지"

                        를 테스트 한다. 비기능 품질 특성은 다음과 같다.

                        품질 특성 : 수행 효율성, 호환성, 유용성(상호작용 능력), 신뢰도, 보안, 유지가능성, 이동성(유연성), 안전성

블랙박스 테스팅 : 명세를 기반으로 하며, 테스트 대상의 내부 구조와 관련 없는 문서로부터 테스트를 도출한다.

                           블랙박스 테스팅의 주요 목적은 명세와 시스템의 동작을 확인하는 것이다.

화이트박스 테스팅 : 구조 기반이며, 시스템의 구현 또는 내부 구조에서 테스트를 도출한다.

                              테스트를 통해 내부 구조를 인수에 필요한 수준까지 충분히 커버하는 것이다.

 

네가지 테스팅 유형은 모든 테스트 레벨에서 사용할 수 있지만, 레벨마다 관심의 대상은 다를 수 있다.

언급한 테스트 유형 모두 테스트 컨디션과 테스트 케이스를 도출하기 위해 다양한 테스트 기법을 사용할 수 있다.

 

 

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

컴포넌트나 시스템을 변경하는 이유는 새로운 기능을 추가해 개선하거나 결함을 제거해 수정하기 위함이다. 이때는 테스팅에 확인 테스팅과 리그레션 테스팅을 추가할 필요가 있다.

 

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

                    리스크에 따라 다음과 같은 여러가지 방법으로 수정된 소프트웨어 버전을 테스트할 수 있다.

                    - 해당 결함으로 이전에 실패했던 모든 테스트 케이스를 실행

                    - 해당 결함을 수정하기 위해 변경한 사항을 확인하는 새로운 테스트를 추가

리그레션 테스팅 : 변경으로 인해 부정적인 영향이 없었는지 확인하는 것. 이미 테스팅이 끝난 수정 사항도 여기서 말하는 변경에 포함된다. 테스트 대상 자체에만 국한되지 않고, 환경과도 관련 있을 수 있다. 리그레션 테스팅의 범위를 파악하기 위해 영향도 분석을 수행하는 것이 좋음

 

리그레션 테스트 : 리그레션 테스트 스위트는 반복적으로 실행되며, 반복 주기 또는 릴리즈때마다 리그레션 테스트 케이스 수가

                           늘어나므로 리그레션 테스트는 자동화하기 매우 적합한 대상이 된다. 이런 테스트의 자동화는 프로젝트 초기에

                           시작해야 한다. 데브옵스와 같이 지속적 통합 사용 시 자동으로 포함하는 것이 좋은 프랙티스이다.

 

 

 

 

유지보수 테스팅

유지보수의 범주 : 문제 수정을 위한 유지보수, 환경 변화, 성능, 유지보수성 개선

유지보수는 계획된 릴리스/배포 또는 계획되지 않은 릴리스/배포 모두와 연관돼 있다. 변경 전에도 영향도 분석을 수행해 시스템의 다른 영역에 미칠 잠재적 영향을 변경사항 결정에 참고할 수 있다.

 

유지보수 테스팅의 범위

    - 변경의 리스크 수준

    - 기존 시스템의 크기

    - 변경사항의 크기

 

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

    - 계획된 개선사항(릴리즈 기반), 수정을 위한 변경, 핫픽스와 같은 수정사항 때문인 경우

    - 운영 환경의 업그레이드나 마이그레이션으로 인한 경우

    - 애플리케이션의 수명이 다하는 등의 단종으로 인한 경우