애자일 테스팅: 방법론 및 생명주기

애자일 테스팅이란 무엇입니까?

애자일 테스트 애자일 테스트는 애자일 소프트웨어 개발의 규칙과 원칙을 따르는 테스트 방식입니다. 폭포수 모델과 달리 애자일 테스트는 프로젝트 시작부터 개발과 함께 지속적으로 진행됩니다. 코딩 단계 이후에만 실행되는 순차적인 테스트가 아니라, 모든 반복 작업에 통합되어 결함이 발견되는 즉시 팀에 피드백이 전달됩니다.

애자일 테스팅의 원칙

애자일 테스트의 핵심 원칙은 다음과 같습니다.

• 작동하는 소프트웨어는 발전의 주요 척도입니다.
• 최상의 결과는 자율적으로 조직되는 팀에서 나옵니다.
• 가치 있는 소프트웨어를 조기에 지속적으로 제공하는 것이 최우선 과제입니다.
• 개발자와 테스터는 프로젝트 전반에 걸쳐 매일 협업합니다.
• 민첩성은 지속적인 기술 개선과 훌륭한 디자인을 통해 향상됩니다.
• 지속적인 피드백을 통해 최종 제품이 비즈니스 기대치를 충족하도록 보장합니다.
• 구현 과정에서 테스트가 실행되므로 전체 개발 시간을 단축할 수 있습니다.
• 테스트 과정은 일관되고 지속 가능한 속도를 유지합니다.
• 팀은 효율성을 높이기 위해 정기적으로 잠시 멈춰서 되돌아보고 조정합니다.
• 최고의 아키텍처, 요구사항 및 디자인은 자율적으로 조직되는 팀에서 나옵니다.
• 대면 대화는 팀 내에서 가장 효과적이고 효율적인 의사소통 방식입니다.

이러한 원칙들을 종합적으로 적용하면 소프트웨어 생산성이 향상되고 아이디어에서 실제 작동하는 기능 구현까지의 시간이 단축됩니다.

민첩한 테스트 수명주기

애자일 테스트 라이프사이클은 아래 그림과 같이 5단계로 구성됩니다.

단계는 다음과 같습니다.

• 1단계: 영향 평가. 이해관계자와 사용자로부터 의견을 수집합니다. 이 단계는 테스트 엔지니어가 다음 개발 주기의 목표를 설정하는 데 도움이 되기 때문에 피드백 단계라고도 합니다.
• 2단계: 애자일 테스트 계획 수립. 모든 이해관계자들이 모여 테스트 일정, 범위 및 결과물을 계획합니다.
• 3단계: 출시 준비 완료. Rev구현된 기능을 검토하고, 어떤 기능을 바로 사용할 수 있는지, 어떤 기능을 개발 단계로 되돌려야 하는지 결정하십시오.
• 4단계: 일일 스크럼 회의. 아침 스탠드업 미팅에서 팀원들은 테스트 진행 상황을 공유하고 당일 목표를 설정합니다.
• 5단계: 민첩성 테스트 Rev에에. 목표 대비 진행 상황을 평가하고 전략을 조정하기 위해 이해관계자들과 매주 회의를 개최합니다.

민첩한 테스트 계획

An 애자일 테스트 계획 이 문서에서는 반복 과정에서 수행되는 테스트 유형, 필요한 데이터 및 인프라에 대해 설명합니다. 테스트 환경그리고 테스트 결과입니다. 워터폴 모델과 달리 애자일 테스트 계획은 릴리스마다 작성되고 갱신됩니다. 일반적인 계획에는 다음이 포함됩니다.

• 테스트 범위.
• 새로운 기능이 테스트 중입니다.
• 기능의 복잡성에 따라 테스트 수준 또는 유형을 결정합니다.
• 로드 및 성능 테스트.
• 인프라 관련 고려 사항.
• 위험 및 완화 계획.
• 자원 조달.
• 산출물 및 주요 일정.

민첩한 테스트 전략

애자일 테스트 수명주기는 네 가지 전략적 단계로 구성됩니다.

반복 0

첫 번째 단계에서는 초기 설정 작업을 수행합니다. 여기에는 테스트 대상자 선정, 테스트 도구 설치, 사용성 테스트 랩과 같은 리소스 예약 등이 포함됩니다. 0차 반복의 목표는 다음과 같습니다.

• 프로젝트에 대한 사업 타당성 분석을 실시하십시오.
• 경계 조건과 프로젝트 범위를 정의합니다.
• 설계상의 절충안을 도출하는 데 중요한 핵심 요구사항과 사용 사례를 간략하게 설명하십시오.
• 하나 이상의 후보 아키텍처를 간략하게 설명하십시오.
• 위험 요소를 파악하십시오.
• 비용을 추산하고 예비 프로젝트 계획을 준비하십시오.

건설 반복

애자일 테스트의 두 번째 단계는 구축 반복(Construction Iterations)으로, 대부분의 테스트가 이 단계에서 이루어집니다. 이 단계는 솔루션을 점진적으로 구축하는 일련의 반복 작업으로 구성됩니다. 각 반복 작업 내에서 팀은 XP, 스크럼, 애자일 모델링 및 애자일 데이터에서 가져온 다양한 방법론을 혼합하여 적용합니다.

팀은 우선순위 요구사항 방식을 따릅니다. 매 반복마다 백로그에서 가장 중요한 항목을 추출하여 구현합니다. 구축 반복은 상호 보완적인 두 가지 테스트 유형으로 나뉩니다.

• 확진 검사 이해관계자의 의도를 시스템이 충족하는지 검증합니다. 이 작업은 팀 자체에서 수행합니다.
• 조사 테스트 확인 테스트에서 놓쳤을 수 있는 문제를 찾아냅니다. 테스터는 잠재적인 문제를 결함 보고서로 제출합니다. 조사 테스트는 통합 테스트, 부하 및 스트레스 테스트, 보안 테스트를 포함합니다.

확증 검사에는 두 가지 추가적인 측면이 있습니다. 개발자 테스트 민첩한 수용 테스트 — 그리고 둘 다 자동화되어 있어 전체 개발 주기 동안 지속적인 회귀 테스트가 가능합니다. 확인 테스트는 애자일 개발 방식에서 명세에 대한 테스트와 같은 개념입니다.

애자일 인수 테스트는 개발팀과 이해관계자가 함께 수행하기 때문에 기존의 기능 테스트와 인수 테스트를 결합한 것입니다. 개발자 테스트는 기존의 단위 테스트와 서비스 통합 테스트를 결합하여 애플리케이션 코드와 데이터베이스 스키마를 모두 검증합니다.

릴리스, 최종 단계 또는 전환 단계

릴리스 단계의 목표는 시스템을 성공적으로 운영 환경에 배포하는 것입니다. 이 단계에는 최종 사용자, 지원 담당자 및 운영팀 교육, 제품 릴리스 마케팅, 백업 및 복구 훈련, 시스템 및 사용자 문서 최종 확정 등의 활동이 포함됩니다.

애자일 테스트의 마지막 단계는 전체 시스템 테스트와 인수 테스트로 구성됩니다. 문제없이 완료하려면 제품 개발 과정에서 철저한 테스트를 거쳐야 합니다. 최종 단계에서는 테스터들이 개발 초기 단계에서 제기된 결함들을 해결하는 데 집중합니다.

생산

출시 단계를 거치면 제품은 실제 운영 환경으로 이동하여 실시간 동작을 모니터링하고, 발생한 모든 문제는 다음 계획 주기에 반영됩니다.

애자일 테스트 사분면

애자일 테스팅 쿼드런트는 전체 프로세스를 네 가지 영역으로 나누어 팀이 애자일 테스팅이 어떻게 수행되는지 이해하는 데 도움을 줍니다.

애자일 사분면 I

제1사분면은 팀을 지원하는 기술 중심 테스트를 통해 내부 코드 품질에 중점을 둡니다.

• 단위 테스트.
• 구성 요소 테스트.

민첩한 사분면 II

2사분면에는 팀을 지원하고 요구사항에 초점을 맞춘 비즈니스 중심 테스트가 포함됩니다. 이 사분면에서 일반적으로 수행되는 작업은 다음과 같습니다.

• 가능한 시나리오 및 워크플로의 테스트 예시입니다.
• 프로토타입과 같은 사용자 경험 산출물을 테스트합니다.
• 쌍 테스트.

민첩한 사분면 III

제3사분면은 제1사분면과 제2사분면에 피드백을 제공합니다. 이곳의 테스트 케이스는 자동화의 기반이 되는 경우가 많으며, 여러 차례의 반복 검토를 통해 제품에 대한 신뢰도를 구축합니다. 일반적인 업무는 다음과 같습니다.

• 유용성 테스트.
• 탐색적 테스트.
• 고객과 함께 페어 테스트를 진행합니다.
• 협업 테스트.
• 사용자 수용 테스트.

애자일 사분면 IV

제4사분면은 성능, 보안, 안정성과 같은 비기능적 요구사항에 중점을 둡니다. 이 사분면은 애플리케이션이 기대되는 비기능적 품질을 제공하도록 보장합니다. 일반적인 작업에는 다음이 포함됩니다.

• 스트레스 테스트 및 성능 테스트와 같은 비기능 테스트.
• 인증 및 침입 시도에 대한 보안 테스트.
• 인프라 테스트.
• 데이터 마이그레이션 테스트.
• 확장성 테스트.
• 부하 테스트.

애자일 소프트웨어 개발에서 QA가 직면하는 과제

애자일 개발 방식은 실질적인 이점을 제공하지만, QA 팀에게는 새로운 과제도 안겨줍니다.

• 문서화에 대한 우선순위가 낮아지면서 오류 발생 위험이 높아지고, 그 부담이 QA 팀으로 옮겨간다.
• 새로운 기능이 빠르게 추가되면서 테스터들은 최신 기능을 요구사항 및 비즈니스 의도에 부합하는지 검증할 시간이 부족해지고 있습니다.
• 테스터는 종종 준 개발자 역할을 수행합니다.
• 테스트 실행 주기가 매우 단축되었습니다.
• 시험 계획을 세울 시간이 제한적입니다.
• 회귀 테스트 예산이 빠듯해지고 있습니다.
• 테스터는 품질 관리자에서 품질 파트너로 변화합니다.
• 요구사항이 자주 변경되는 것은 애자일 개발 방식의 본질적인 특징이며, 이는 QA 담당자에게 가장 큰 과제 중 하나입니다.

애자일 프로세스에서 자동화의 위험성

애자일 개발에서 자동화는 필수적이지만, 팀이 적극적으로 관리해야 할 위험도 수반합니다.

• 자동화된 UI 테스트는 높은 신뢰도를 제공하지만 속도가 느리고 불안정하며 유지 관리 비용이 많이 듭니다. 생산성 향상은 테스터가 좋은 테스트를 설계하는 방법을 알 때만 나타납니다.
• 신뢰할 수 없는 검사는 심각한 문제입니다. 취약한 검사법과 위양성 오류를 해결하는 것이 최우선 과제로 남아 있어야 합니다.
• CI를 통하지 않고 수동으로 실행되는 자동화 테스트는 조용히 오류가 발생하여 오래된 결과를 생성할 위험이 있습니다.
• 자동화는 탐색적 수동 테스트를 대체하지 않습니다. 기대하는 품질을 위해서는 다양한 유형과 수준의 테스트가 필요합니다.
• 캡처 및 재생 도구는 UI 중심의 스크립트 사용을 조장하는데, 이는 취약하고 유지 관리가 어렵습니다. 버전 관리 시스템 외부에 저장된 테스트는 불필요한 복잡성을 더합니다.
• 시간을 절약하기 위해 계획이 부실하게 추진된 자동화는 종종 완전히 실패한다.
• 자동화 과정에서 테스트 설정 및 해제 절차를 간과하기 쉽지만, 수동 테스트에서는 이러한 절차가 자연스럽게 처리됩니다.
• "하루 테스트 케이스 수"와 같은 생산성 지표는 팀이 불필요한 테스트를 실행하도록 오도할 수 있습니다.
• 자동화 팀은 효과적인 컨설턴트, 즉 접근하기 쉽고 협조적이며 문제 해결 능력이 뛰어난 팀이어야 합니다. 그렇지 않으면 사업은 실패할 것입니다.
• 지속적인 유지보수가 많이 필요한 솔루션은 제공하는 가치보다 비용이 더 많이 들 수 있습니다.
• 자동화된 테스트는 효과적인 해결책을 제시하는 데 필요한 전문성이 부족할 수 있습니다.
• 성공적인 자동화는 해결해야 할 중요한 문제가 고갈되면 가치가 떨어지는 작업으로 방향을 틀 수 있습니다.

효과적인 애자일 테스팅을 위한 최고의 사례

다음과 같은 방법들을 통해 애자일 테스트를 빠르고 안정적이며 팀에 유용하게 활용할 수 있습니다.

• Shift 왼쪽: 테스트는 반복 작업이 끝날 때가 아니라 요구사항 도출 단계에서 시작해야 합니다.
• 개발자와 협업하세요: 결함이 코딩에 포함되는 것이 아니라 설계 단계에서부터 제거되도록 승인 기준을 함께 검토하십시오.
• 레이어 자동화: 단위 테스트, 서비스 테스트, UI 테스트로 구성된 건전한 피라미드 구조를 구축하세요.
• 테스트의 독립성을 유지하십시오: 각 테스트를 분리하여 실패 시 단일 근본 원인을 파악합니다.
• Track 불안정한 테스트: 신뢰도 하락을 방지하기 위해 불안정한 테스트는 즉시 격리하고 수정해야 합니다.
• AI 기반 분석을 활용하세요: 병합 후 도구가 영향을 받는 테스트를 표시하고, 실패를 그룹화하고, 안정적인 로케이터를 제안하도록 합니다.

자주 묻는 질문