애자일 테스트 수행 방법론: 수명 주기, 기법, 전략

by | May 7, 2024

애자일에서는 개발과 테스트 수행이 동시에 진행된다. 그로 인해 개발 파이프라인이 간소화 된다. 이는 효율적이고 정확한 소프트웨어 출시를 보장하기 위한 것이다. 애자일 개발에서는 프로젝트를 스프린트로 세분화한다. 이와 비슷하게, 애자일 테스트 수행에서는, 대규모 기능 개발을 더 작고 관리하기 쉬운 스프린트 기반 프로젝트와 제품으로 세분화 한다.

애자일 테스트 수행의 원칙은 무엇인가?

애자일 프레임워크에서 테스트 수행을 할 때, 절차의 지침이 되는 몇 가지 원칙이 있다:

테스트 수행 조기 시작

전통적으로, 개발 후기 단계의 소프트웨어 버그는 백엔드와 깊이 얽혀 있다. 이 오래된 이슈는 워터폴 개발 사이클에서 유래했다. 그 방식에서는 테스트 수행은 오직 모든 개발이 완료 된 후 진행된다.

이 단계에서는, 버그를 찾고 디버깅하는 것이 무척 어려워진다. 따라서, 이 문제를 완화하기 위해 테스트 팀을 브레인스토밍 및 계획 단계 부터 참여시킨다. 애자일 소프트웨어 테스트 수행은 소프트웨어 개발 수명 주기(Software Development Life Cycle, SDLC) 전반에 걸쳐 원활하게 통합되고 수행되어야 한다.

즉, 개발자가 새 코드나 수정된 코드를 작성하고 푸쉬할 때마다 테스트 해야 한다는 의미다. 여러 번의 테스트를 거치지 않고서는, 프로젝트 마스터 Git에 새로운 코드를 통합할 수 없어야 한다.

수시로 전달

애자일 테스트 수행에서, 스프린트 주기는 프로젝트 요구 사항이나 팀의 선호도에 따라 달라진다. 보통은 몇 주 동안 이어진다. (한 프로젝트의 각 스프린트는 기간이 동일하다.)

주기와 상관없이, 테스터는 각 스프린트의 종료 시점에 테스트 리포트를 준비해야 한다.

자동화 수용

자동화는 애자일 테스트 수행의 성공에 필수적이다. 릴리스 기한을 준수하면서 매 스프린트에서 테스트를 실행하는 것은 강력한 자동화 도구가 없다면 현실적으로 불가능하다. 수작업 테스트 수행이 여전히 중요하기는 하다. 그러나 Mike Cohn의 ‘테스트 자동화 피라미드’와 같은 개념을 적용한, 효과적인 테스트 자동화 전략은 효율성을 보장하면서도 품질을 희생하지 않는다.

일관성 있는 협업

애자일 개발을 지속하기 위해서는 적절한 도구, 교육, 협력적인 업무 문화를 통한 팀간의 통일된 협업이 아주 중요하다. 일일 스탠드업 회의, 주간 이해관계자 회의, 그리고 즉각적인 커뮤니케이션 도구는 팀워크를 촉진한다. 개발자, 테스터, 비즈니스 분석가 등 모든 구성원이 소프트웨어 품질에 대한 책임을 공유하는 전체 팀 접근 방식을 강조한다. 그러면 고품질 결과물이 보장된다.

고객 참여

잠재적 고객을 애자일 테스트에 필수적으로 참여시켜야 한다. 최종 사용자로서 고객은 실제 상황에서의 소프트웨어 사용성에 대해 매우 유용한 인사이트를 제공한다. 온라인 플랫폼을 활용하여 테스트 수행 단계 전반에 걸쳐 고객과 지속적으로 소통하고, 계획, 검토, 회고 회의에 고객을 참여시켜야 한다. 개방적인 커뮤니케이션을 장려하고, 반복적인 개선을 위해 각 스프린트 후 소프트웨어를 공개하여 피드백을 받도록 한다.

품질 및 적응성을 우선시 하기

모든 팀 구성원은 애자일 프로젝트의 각 단계에서 품질에 우선순위를 둬야한다. 현대 사용자의 기대에 부응하기 위해서는 유연한 사고방식이 필요하다. 소프트웨어 또는 고객 요구 사항의 갑작스러운 변화에 대해 개방적이어야 하기 때문이다. 이 유연성을 팀 전체로 확산시켜, 변화에 대해 협력적이고 효율적으로 대응할 수 있는 공동 준비 태세를 갖추도록 한다.

애자일 테스트 수행의 수명 주기

이 단계들은 반복적으로 실행된다는 점을 명심하자. 각각의 스프린트마다 팀은 이 모든 단계를 실행한 뒤, 다음 스프린트를 위해 다시 1단계부터 시작한다.

영향 평가

테스터는 사용자 스토리를 분석하고 이해관계자의 인사이트를 확보한다. 이를 통해 팀이 요구 사항에 부합하는지 확인한다. 이 작업이 완료되면, 테스터는 사용자 스토리를 관리 가능한 개별적 작업으로 분할할 수 있다.

테스트 계획

이해관계자들이 협력하여 테스트 일정, 테스트 계획, 실행 절차, 예상 결과를 작성한다.

애자일 테스트 계획은 테스트 접근 방식, 목표, 범위를 간략하게 나타낸다. 계획은 유연해야 한다. 팀이 요구 사항의 변화에 적응할 수 있어야 하기 때문이다. 또한 계획은 이 프로젝트의 테스트 자동화와 해당 애플리케이션을 포함해야 한다.

이 단계는 또 두 가지 중요한 단계로 나뉜다:

테스트 설계

팀은 테스트 케이스와 스크립트를 작성하고, 테스트를 설계해야 한다. 이때 요구 사항과 데이터를 기반으로 작업해야 한다. 팀은 개발자와 함께 일해야 한다. 애플리케이션 코드의 작동 방법과 예상되는 기능을 이해하기 위해서다.

테스트 개발

테스터는 수작업 테스트와 자동화 테스트를 만들고 실행한다. 애자일 테스트의 일부인 테스트 주도 개발(TDD, Test-driven Development) 그리고 행동 중심 개발(BDD, Behavior-driven Development)에서는 실제 코드가 개발 되기 전에 실행되도록 설계할 수 있다. 다른 테스트, 예를 들어 탐색적 테스트 수행이나 세션 기반 테스트 수행 같은 경우, 각 스프린트 중에 개발된 코드를 따른다.

일일 스크럼

스프린트 기간 중 매일, 팀 전체가 모여 예정된 작업, 진행 상황, 갈등 또는 혼란에 대해 짧게 논의하여 내용을 공유한다.

출시 준비

소프트웨어는 출시 준비가 되었는가? 이 단계에서는 테스트를 실행하고, 결과를 검토하고, 버그를 제거해야 한다. 이 단계에서는 소프트웨어를 이전 개발/테스트 수행의 단계로 돌려보내는 경우가 많다. 아직 출시 준비가 되지 않은 경우가 이에 속한다.

배포 및 모니터링

소프트웨어가 모든 수용 기준을 충족하면 프로덕션에 출시된다. 팀이나 회사에 따라 다르지만, 배포가 자동화 될 수도 있다. 출시 전에 마지막으로 사람의 확인이 필요한 경우도 있다.

테스트 가능한 승인 기준: 애자일 테스트 수행 환경에서 “준비/완료”의 정의는 무엇인가?

기능이 하나의 테스트를 통과하고 다음 개발 단계로 넘어갈 준비가 되어있는지 어떻게 판단할까? 개발 중인 소프트웨어가 실제로 일반 사용자들에게 공개할 수 있을 만큼 충분히 좋은지 어떻게 판단할까?

이럴 때에는 승인 기준을 사용하면 된다.

승인 기준은 소프트웨어 애플리케이션이 SDLC 단계를 통해 진행할 준비가 되었는지 결정하는 정의 조건의 역할을 한다. 특히 SDLC의 마지막 단계에서는 애플리케이션이 이 기준에 의해 공개 출시할 준비가 되었는지 결정된다.

이 기준은 소프트웨어가 고객 또는 써드파티 시스템으로부터 승인을 받기 위해 보여 주어야 하는 특정 기능을 간략하게 설명한다. 이 기준은 각각의 소프트웨어 개발 프로젝트마다 달라진다. 일반적으로 사용자 스토리에서 도출 되며, 최종 사용자가 원하는 작동에 대해 기술한다.

여러분이 QA 책임자라고 가정해보자. 여러분과 여러분의 팀은 온라인 서점의 어떤 기능을 테스트해야 한다. 테스트 대상은 사용자가 ‘카테고리’를 사용하여 제품을 검색할 수 있는 기능이다.

개발자들은 사용자가 ‘카테고리’를 선택하고 키워드를 입력할 수 있는 검색창을 만들었다. 하지만 요구 사항 문서의 내용과 일치하지 않는다. 요구 사항 문서에는 카테고리 내에서 검색하기 전에 모든 카테고리를 볼 수 있어야 한다고 명시되어 있다. 이 경우, 사용자는 ‘카테고리’를 선택할 수는 있다. 하지만 단일 키워드를 입력하여 검색해야 하며, 사용 가능한 모든 카테고리를 볼 수 없다.

기능은 작동하지만, 요구 사항과 거기서 도출된 사용자 스토리를 충족하지 못한다. 따라서, 승인 기준을 충족하지 못한다.

이 맥락에서, 허용 기준은 “사용자가 ‘카테고리’에 액세스하여 단일 인터페이스에서 확인한 후 검색을 수행해야 한다.”라고 규정하고 있다. 이 기대치가 충족되지 않으므로, ‘카테고리’ 검색이 가능함에도 불고하고 승인 기준이 충족되지 않는다.

애자일 테스트 수행의 지속적인 전달 및 지속적인 배포

애자일 테스트 수행은 지속적인 통합 및 지속적인 배포(CI/CD)와 함께 진행된다.

지속적인 전달(Continuous Delivery)에서, 코드의 변경사항은 릴리스되기 전에 철저한 테스트를 거친다. 그런데 실제 릴리스에서는 사람, 즉 코드를 프로덕션에 릴리스할 수 있는 권한을 가진 사람의 승인이 필요하다.

지속적인 배포(Continuous Deployment)도 마찬가지다. 사람의 역할 부분을 제외하고는 매우 비슷하게 진행된다. 전체 절차는 자동화된다. 따라서 코드는 CI/CD 파이프라인 내에서 모든 테스트를 통해 검증된 다음 프로덕션에 자동으로 릴리스 된다.

애자일 테스트 수행 전략을 수립하는 방법

애자일 테스트 수행 사분면은 여러분의 팀이 테스트 수행 유형을 선택하는 데 도움이 된다. 프로젝트 결과물과 리소스의 상황에 따라 결정하면 된다. 출시, 테마, 반복 계획 수립 중 각 사분면에 무엇이 포함되는지 정하는 엄격한 규칙은 없다. 애자일 테스트 계획 수립을 위한 커다란 프레임 워크라고 생각하면 된다.

  • 1 사분면: 이 사분면에는 유닛 테스트와 컴포넌트 테스트가 포함된다. 이 테스트들은 코드의 빌드가 정확한지 확인하고, 기존 코드베이스에 통합 되도록 보장한다.
  • 2 사분면: 이 사분면에는 고객 중심 및 비즈니스 주도 품질을 확인하는 테스트가 포함된다. 이 테스트들은 애자일팀이 비즈니스 및 고객 가치의 맥락에서 더 좋은 결과의 확보를 돕는다.
  • 3 사분면: 이 사분면에서는, 테스트가 코드의 품질뿐만 아니라 사용자 경험의 품질도 검증한다. 일반적으로 이 테스트들은 숙련된 QA 전문가가 수작업으로 진행한다. 이 레벨의 테스트들은 직관, 시각적 사고, 주관적 분석, 고객 가치의 이해와 같은 인간의 특징적인 속성이 필요하다.
  • 4 사분면: 이 사분면은 비기능적 테스트를 실행하여 보안, 성능, 사용자 수용 수준을 확인한다. 이 테스트들을 통해 소프트웨어의 안정성, 데이터 개인 정보 보호 등을 포함해 전반적인 보안을 확인할 수 있다.

그림: 이 애자일 테스트 수행 사분면은 Brian Marick’의 “Marick 테스트 매트릭스”를 기반으로 Janet Gregory와 Lisa Crispin이 개발했다

사분면을 활용하기 위해 다음과 같이 세 단계를 따른다:

  1. 진행 중인 작업이 비즈니스와 기술 중 무엇을 중심으로 하는지 결정한다.
  2. 그 테스트 수행이 개발을 가이드하기 위한 것인지, 아니면 제품을 평가하기 위한 것인지 결정한다. 이는 개발 주기나 스프린트 안에서 현재 속한 단계에 따라 결정된다.
  3. 어느 사분면에 해당되는지가 결정되었다면, 그 스프린트에서 작업해야 하는 테스트 수행의 유형을 알 수 있다

애자일 테스트 수행 사분면을 사용하는 시나리오의 예시: 모바일 뱅킹 앱 개발

1 사분면: 기술 중심 테스트(팀 지원)

테스트 유형: 유닛 테스트
목적: 개별 코드 컴포넌트의 기능을 확인한다.

시나리오: 개발 팀은 모바일 뱅킹앱의 새로운 기능인 계좌 잔액 실시간 업데이트 기능을 작업 중이다. 개발자는 유닛 테스트를 작성하여 잔액 계산 메서드의 정확성을 검중하려 한다. 입금, 출금, 이자 계산들이 올바르게 처리 되는지 확인하는 것이다. 이 테스트들은 새로운 코드가 푸쉬될 때 실행되도록 자동화되었다. 이로써 핵심기능의 무결성을 보장한다.

3 사분면: 비즈니스 중심 테스트(팀 지원)

테스트 유형: 사용자 승인 테스트 수행(User Acceptance Testing, UAT)
목적: 시스템이 비즈니스 요구 사항 및 사용자 기대에 부합하는지 검증한다.

시나리오: 앱의 새로운 기능을 공개하기 전, 제품 소유자는 최종 사용자(은행 고객)와 협력해서 사용자 승인 테스트 수행을 진행한다. 선정된 고객 그룹은 앱의 테스트 버전을 사용하여 잔액이 실시간으로 업데이트 되는지 확인한다. 고객들은 표시된 잔액의 정확도를 확인하기 위해 거래 내역과 비교한다. 이로써 올바른 금액을 반영하고 신속하게 업데이트 되는지 확인한다. UAT 의 피드백을 수집하여 정식 출시 이전에 기능을 개선한다.

1 사분면의 유닛 테스트와 3사분면의 사용자 승인 테스트(UAT)를 결합하여, 팀은 단단한 기술 기반을 확보한다. 동시에 기능의 유용성과 고객의 요구 사항이 일치하는지 검증한다. 이런 이중 접근 방식은 잔액 계산의 정확성을 확인하고 실제 유용성을 검증하여, 앱의 전반적인 품질을 향상시킨다.

애자일 테스트 수행 전략의 구성 요소

모두 문서화 되어있는 워터폴 테스트 수행 및 테스트 계획과는 달리, 애자일 테스트 수행에서는 결과물 전달에 집중한다. 그리고 애자일 테스트 전략에서는 변화하는 요구 사항에 대응하기 위한 유연성과 적응성에 중점을 둬야 한다. 모든 것에 다 맞는 만능의 접근 방식은 없다. 하지만 몇 가지 필수적인 요소는 있다. 다음을 참고하자:

애자일 테스트 수행의 문서화

애자일 테스트 수행에서 문서화의 핵심은 적당한 균형이다. 과도하지도, 필수적 세부 사항을 누락할 만큼 모자라지도 않게 조절해야 한다. 목적에 부합하기 위해 충분한 문서를 제공해야 한다. 애자일 테스트 계획의 항목과 구조는 그 계획이 사용되는 상황에 따라 달라질 수 있다. 애자일 테스트 수행의 방법론은 반복적이다. 때문에 QA는 모든 새로운 기능 및 스프린트마다 테스트 계획을 세우고 업데이트 해야 한다.

다음은 애자일 테스트 계획의 템플릿 중의 하나인 ‘한 장 계획서’의 예시다:

테스트 계획 제목
작성자: John Doe
1. 소개
– 개요 (간단히 작성할 것)
2. 테스트 수행 리소스
– 테스터의 이름과 역할
3. 테스트 수행의 범위
– 범위 내: 테스트 대상 모듈
– 범위 외: 테스트 대상이 아닌 모듈
4. 테스트 수행 접근 방식
– 테스트 수행의 접근 방식과 방법론
– 수행할 테스트 수행 유형(예: 기능, 성능, 보안, 사용성)
5. 테스트 일정
– 테스트 단계별 일정
6. 리스크와 이슈
– 테스트 수행 절차와 관련된 리스크
– 파악된 리스크 완화를 위한 전략

애자일 테스트 계획의 목적은 불필요한 정보를 최소화하고, 필요한 정보는 정확히 담아내는 것이다. 여기서 필요한 정보는 이해관계자와 테스터가 계획을 실행할 때 요구되는 정보다.

그림: TestRail과 같은 테스트 관리 플랫폼을 사용하면, 더 빠르고 더 쉽게 테스트 문서를 기록, 저장, 재사용할 수 있다.

스프린트 계획하기

애자일 개발에서 중요한 것은, 시간이 제한된 스프린트 내에서 팀의 작업을 계획하는 것이다. 시간이 제한된 스프린트로 인해 팀은 고유의 박자를 만들어 낸다. 그로인해 일관된 진행 상황, 적응성, 반복된 개발을 위해 구조화된 프레임워크가 보장된다. 동시에 협업적이고 반응이 빠른 환경이 조성된다. 기본적으로, 스프린트는 애자일 테스트 수행이 애자일 개발의 속도를 따라갈 수 있게 한다.

스프린트 계획하기위해서는 다음 항목을 고려해야 한다:

  • 사용자 스토리에 기반한 테스트 목표
  • 테스트의 범위와 일정
  • 테스트 유형, 기술, 방법, 데이터, 그리고 환경

애자일 테스트 수행에서의 테스트 자동화

테스트 자동화는 애자일 테스트 수행에 필수적이다. 자동화가 없으면, 애자일 테스트 수행 팀은 애자일 개발의 속도에 맞추는 것이 매우 거의 불가능하다. 자동화는 다음과 같은 핵심 역할을 한다:

  • 정적 회귀 테스트 완료 및 가속화
  • 코드 수정에 대한 더 빠른 피드백 보장
  • 지속적인 통합 및 전달 지원
  • 인적 테스트 수행 리소스에 대한 부담 감소
  • 더 효율적으로 테스트를 실행할 수 있도록 지원
  • 테스터들이 시간을 확보하여, 애플리케이션의 더 복잡하거나 더 위험한 영역에 대한 테스트 수행에 집중할 수 있도록 한다. 테스트 커버리지의 희생 없이 말이다.

가장 먼저 자동화 되어야 하는 테스트는 어떤 것일까?

효과적이고 확장 가능한 애자일 테스트 수행은 자동화에 달려있다. 자동화에는 전략적으로 접근하는 것이 중요하다. 가장 중요한 첫 번째 작업은 자동화할 테스트를 결정하는 것이다. 다음은 자동화해야 할 테스트의 우선순위를 정할 때 도움이 되는 질문들이다:

  • 반복되는 테스트인가?
  • 우선순위가 높은 테스트 또는 우선순위가 높은 기능인가?
  • 여러 데이터 세트들 또는 여러 경로들을 통해 테스트를 실행할 필요가 있는가?
  • 회귀 테스트(Regression Test)인가, 아니면 스모크 테스트(Smoke Test)인가?
  • 기존 기술 스택으로 자동화할 수 있는가?
  • 테스트 수행 중인 앱의 영역이 쉽게 변경되는 경향이 있는가?
  • 무작위 네거티브 테스트인가?
  • 이 테스트들은 병행해서 실행할 수 있는가, 아니면 순서에 따라 진행해야만 하는가?
  • 이 테스트를 위한 아키텍처는 얼마나 비싸고 / 복잡한가?

어떤 테스트 또는 테스트 스위트를 자동화 해야 하는지 확신이 서지 않는가? 인터랙티브하고 커스터마이징이 가능한 우리의 점수 모델을 다운로드하자. 다음에 무엇을 자동화할 것인지 우선 순위를 정하는데 도움이 될 것이다.

스프린트 중 테스트를 자동화 해야 하는 때는 언제인가?

스프린트 중에 테스트를 자동화할 시기를 결정하기 위한 두가지 접근 방식이 있다:

  1. 개발 작업과 테스트 자동화 작업을 스프린트 안에서 동시에 실행하기.
  2. 교대 작업: 현재 스프린트 안에서 기능을 개발한 다음, 후속 스프린트에서 자동화 하기.

두 방식 모두 고유의 장점과 고려해야할 사항이 있다. 동시 방식은 기능이 개발되었을 때 테스트가 준비되어 있어, 신속하게 피드백을 받고 버그를 식별할 수 있다. 반면에, 교대 방식은 개발팀이 방해 없이 새로운 기능에 대해 작업할 수 있게 한다. 그러나 해당 기능에 대해 자동화된 테스트를 사용 가능한 시점이 지연될 수 있다.

이 두 가지 방식 사이에서의 선택은 팀의 에너지, 프로젝트 일정, 기능의 복잡성, 팀 내 기술 역량, 프로젝트의 특정 요구 사항 등 다양한 요인에 따라 결정된다. 프로젝트의 상황에 따라, 애자일 팀은 둘중 하나를 채택할 수도 있고, 두 방식을 결합해 사용할 수도 있다.

리스크 관리

정해진 일정 내에 신속하게 소프트웨어를 제공하려면, QA가 다른 테스트 보다 특정 테스트를 우선하여 진행해야 한다. 이에 따라 잠재적인 위험이 증가한다. 가능성이 높은 리스크가 있는 테스트는 QA 팀의 더 많은 주의, 시간, 노력이 필요하다. 게다가 어떤 테스트는 특정 기능에 더 필수적이다. 따라서 스프린트를 계획할 때에는 우선순위 수준을 고려해야 한다.

흔히 알려진 애자일 테스트 수행에 대한 오해를 해결하고, 팀의 기존 워크플로 내에 애자일 테스트 수행을 적용하는 방법에 대한 실용적 이해를 얻으려면 다음 비디오를 확인하자. 애자일 테스트 수행이 아닌 것.

테스트 케이스 관리 도구로 애자일 테스트 수행을 관리하는 방법

그림: 하나의 중앙 집중식 플랫폼에서 애자일 품질 보증 절차를 쉽게 조직해보자. TestRail을 사용하면 하나의 대시보드에서 테스트를 추적, 관리, 업데이트 할 수 있다.

올바른 테스트 수행 도구는 효율적인 애자일 개발과 테스트 수행 파이프라인을 만드는 데 중심점이 된다. 여러분의 필요에 가장 적합한 테스트 관리도구를 선택하라. 이 도구는 테스터, 개발자, 그리고 기타 이해관계자들이 테스트 케이스를 설계, 실행, 리포트할 수 있도록 교차 기능팀 간의 협력을 지원한다.

효과적인 도구는 테스트 자동화 프레임워크 및 Jira 같은 애자일 프로젝트 관리 플랫폼과 통합이 가능해야 한다. 그리고 모든 테스트 관련 정보를 위한 중앙 집중식 리포지토리 역할을 해야 한다. 또 추적 능력을 쉽게 만들어야 한다.

TestRail는 애자일 팀을 위해 특별히 설계되었다. 그리고 모든 규모의 QA 팀과 개발 팀이 애자일 테스트 수행 파이프라인을 다루고 관리하는 데 사용된다.

이를 위해 TestRail을 사용하면 다음과 같은 기능을 활용할 수 있다:

  • 테스터가 즉시 생산성을 높일 수 있는 빠르고 직관적인 UI
  • 프로젝트 대시보드와 이메일을 통해, 테스트 파이프라인 전반에 걸쳐 테스터에게 정보 제공.
  • 하나의 중앙 대시보드에서 모든 주요 애자일 테스트 수행 아티팩트를 관리할 수 있는 기능.
  • 모든 테스트 활동과 테스트 결과를 버전별로 안전하게 보관. 이로써 테스터는 언제나 파이프라인의 상세 이력을 확인 가능.
  • 다양한 프로젝트, 마일스톤, 테스트 계획 및 실행에 걸쳐 테스트 활동을 비교할 수 있는 프로젝트 간 리포트 기능.
  • Jira, Jenkins, Selenium 등과 같이 광범위하게 사용되는 도구와 통합.

오늘 애자일 테스트 수행에 관한 TestRail 아카데미의 무료 과정을 확인하자. 애자일 테스트 도입을 간소화 하는 방법을 알 수 있다.

애자일 테스트 수행에 대해 자주하는 질문

애자일 테스트 수행 대 지속적 테스트 수행

지속적 테스트 수행은 애자일 SDLC 내에서 아주 구체적인 과정이다. 기본적으로 CI/CD 파이프라인 내에서 자동화된 테스트를 설정한다. 개발자가 새로운 코드를 푸시할 때마다, 해당 코드는 일련의 자동화된 테스트를 거쳐야 소프트웨어의 더 큰 코드베이스에 적용된다.

지속적인 테스트 수행은 매우 성공적인 기술로 자리 잡았다. 비즈니스 리스크와 기술적 이상 현상을 줄이는데 큰 성공을 거두었기 때문이다.

지속적 테스트 수행은 개인, 팀, 시스템, 서비스 간의 협업을 요구한다. 이 일련의 테스트는 특히 애플리케이션의 규모와 기능을 더해가는 과정에서 버그의 유입을 방지하기 위한 안전망 역할을 한다.

시프트 레프트 테스트 수행 대 시프트 라이트 테스트 수행

먼저, 소프트웨어 개발 생명 주기 를 일직선이라고 생각해 보자. SDLC의 단계는 ‘왼쪽’에서 시작해서 ‘오른쪽’으로 이동한다.

시프트 레프트 테스트 수행

시프트 레프트 테스트 수행은 테스트 수행을 SDLC의 “왼쪽”으로 이동시키는 것을 말한다. 즉, 테스트 수행이 더 이른 단계에서 시작된다.

팀은 소프트웨어를 가능한 한 조기에 계획, 빌드, 테스트한다. 테스터는 브레인스토밍 대화에 참여하여 요구 사항을 이해한다. 그런 다음, 개발자가 해당 기능을 코딩할 때, 동시에 테스트 설계를 시작한다. 테스트는 실제 코딩 작성 전, 또는 코딩 작성과 동시에 만들어 진다.

여기에서 큰 장점은 팀이 개발중에 나타날 변경 사항을 예측 가능하다는 것이다. 따라서 코드가 모두 작성될 때까지 기다릴 필요가 없다. 즉시 테스트 수정이 가능하다.

시프트 레프트 테스트 수행은 API, 컨테이너 구성, 마이크로 서비스 간의 상호작용 확인을 우선으로 한다. 이 테스트는 높은 효율성 덕분에 점점 더 인기가 높아지고 있다.

시프트 라이트 테스트 수행

반면에, 시프트 라이트 테스트 수행은 실제 환경에서 소프트웨어의 품질과 성능을 테스트 하는 것이다.

일반적으로, “실제 환경”은 일종의 프로덕션 환경에서의 테스트 수행을 뜻한다. 가장 이상적인 실행 방법은 실제 브라우저와 장비에서 소프트웨어를 테스트 하는 것이다. 예를 들어, 소프트웨어가 실제로 스마트폰에서 잘 작동한다면, 출시 후에도 잘 작동할 것이다.

테스트가 SDLC의 “오른쪽”으로 이동할 때, 우선적으로 해야하는 것은, 소프트웨어가 실제 사용자 트래픽을 품질 저하 없이 처리 할 수 있는지 테스트 하는 것이다. 앱이 100명의 사용자를 대상으로 할 때와 마찬가지로 1000명의 사용자를 대상으로 서비스할 수 있는가?

시프트 라이트 테스트 수행은 성능, 안정성, 복원력에 우선순위를 둔다. 개발 기간동안에 일반적으로 나타나지 않는 버그, 런타임 문제, 이상 현상을 찾는데 중점을 둔다.

테스트 피라미드 모델

테스트 피라미드는 테스트 수행의 여러 계층에 대한 시각적 은유를 만들어 낸다. 이로써 애자일 테스트 수행 체계를 단순화 한다. 또한 테스트 피라미드는 QA들이 얼마나 많은 테스트 수행이 각 수준 별로 필요한지 결정하는데 도움이 된다.

테스트 피라미드는 일반적으로 세 가지 계층으로 구성된다:

  • 유닛 테스트 — 제일 아래
  • 서비스 테스트—중간
  • 사용자 인터페이스(UI) 테스트—제일 위

관례적인 세가지 계층 테스트 피라미드는 현대 SDLC에는 지나치게 단순하게 보일지도 모른다. 하지만 테스트 계층화의 기본 개념은 여전히 효과적이다. 이 피라미드를 사용해 테스트를 설계할 때 실행 가능한 다음의 팁을 기억하자:

  • 테스트 스크립트를 다양한 수준으로 세분화하여 작성하기
  • 테스트는 SDLC의 “상위 수준”으로 이동함에 따라, 그 수는 감소하고, 각 테스트의 커버리지는 증가해야 함
  • 작고 빠른 유닛 테스트 작성
  • 애플리케이션의 엔드 투 엔드(end-to-end) 테스트 수행을 위해 높은 수준 테스트 유지
  • 피라미드를 특정 프로젝트 요구 사항에 맞게 조정(예: 서비스 테스트 수행 계층을 프로젝트 요구 사항에 가장 적합한 다른 테스트로 대체)

(원문: Hannah Son | December 27th, 2023 | Agile Testing Methodology: Life Cycle, Techniques, & Strategy)

다른 기고들

애자일 테스트 수행에서의 수락 기준들 (Acceptance Criteria in Agile Testing)

애자일이라는 직조물(tapestry)에서, 수락 기준은 황금색 실과 같다. 이것은 사용자 스토리를 최종 형태로 연결한다. 이 기준은 테스터가 테스트 수행 전략을 수립하는데 도움이 된다. 그리고 기능 및 품질 보증을 검증하는 데에도 중요한 임계 값 역할을 한다. 수락 기준은 제공된 제품이 고객의 기대에 부합할 것이라고 약속한다. 고객에게 필요한 사항을 정확히 정의하여, 발생 가능한 오해를 줄이고, 더욱 명료하게 한다. 이렇게 고객의 기대치에 맞춰 조율하는 것은 고객 만족으로...

애자일에서의 회귀 테스트 수행(Regression Testing)

요구 사항의 빈번한 변경과 애자일 특유의 빠른 개발 속도는 회귀 테스트 수행의 중대한 필요성을 강조한다. 그러나 회귀 테스트를 제대로 수행하지 않으면, 애자일팀에 어려움을 가져올 수 있다. 애자일에서 회귀테스트 수행의 역할은 무엇인가? 애자일 환경에서, 회귀 테스트 수행은 기존 소프트웨어의 기능을 새로운 코드의 변화나 추가로 인한 부정적인 영향으로부터 보호한다. 회귀 테스트 수행에서, 테스터는 업데이트된 코드 베이스(변경 사항이 병합된 후의 코드 베이스)가 바라는 기능과...

애자일 QA 절차: 원칙, 단계, 모범 사례

애자일 QA(Quality Assurance, 품질 보증) 절차는 애자일 프레임워크 내에서 개발된 소프트웨어가 원하는 품질 기준의 충족을 보장하기 위한 일련의 관행과 방법론이다. 이는 협업, 유연성 그리고 지속적인 개선을 강조하는 애자일 개발 원칙에 맞아 떨어진다. 왜 애자일 QA로 전환해야 할까? 애자일은 소프트웨어 개발에서 가장 인기 있는 방법론 중 하나다. 애자일 프로젝트는 전통적인 프로젝트 관리 방법에 비해 더 높은 적응성, 고객 만족도, 효율성, 품질, 팀 협업 등과...