애자일 테스트 가이드 : 프로세스, 전략, 테스트 계획, 사분면, 수명주기

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

WaterFall 메소드와 달리 애자일 테스트는 개발과 테스트 사이의 지속적인 통합으로 프로젝트 시작시 시작할 수 있습니다. 애자일 테스팅은 순차적이지 않고 (코딩 단계 이후에만 실행된다는 의미에서) 연속적이지 않습니다.

애자일 팀은 품질 목표를 달성하기위한 하나의 팀으로 일합니다. 애자일 테스트 (Agile Testing)는 반복이라는 짧은 프레임을 가지고 있습니다 (예 : 1 ~ 4 주). 이 방법론은 단기간에 실행 가능한 제품에 대한 더 나은 예측을 제공하므로 릴리스 또는 전달 중심 접근 방식이라고도합니다.

애자일 테스트 계획

폭포 모델과 달리 애자일 모델에서는 테스트 계획이 모든 릴리스마다 작성되고 업데이트됩니다. 애자일 테스트 계획에는 테스트 데이터 요구 사항, 인프라, 테스트 환경 및 테스트 결과와 같은 반복 작업에서 수행되는 테스트 유형이 포함됩니다. 애자일의 일반적인 테스트 계획에는 다음이 포함됩니다.

1) 테스트 범위

2) 테스트중인 새로운 기능

3) 기능의 복잡성에 기반한 테스트의 수준 또는 유형

4) 로드 및 성능 테스트

5) 인프라 고려 사항

6) 완화 또는 위험 계획

7) Resourcing

8) 산출물 및 연혁

애자일 테스트 전략

4 단계를 통한 애자일 테스트 수명주기

(a) 반복 0

1 단계 또는 반복 0에서는 초기 설정 작업을 수행합니다. 여기에는 테스팅을위한 사람들의 식별, 테스트 도구의 설치, 리소스 (유용성 테스트 랩)의 스케줄링 등이 포함됩니다. 다음 단계는 반복에서 달성하도록 설정됩니다.

a) 프로젝트의 비즈니스 사례 수립

b) 경계 조건 및 프로젝트 범위 설정

c) 디자인 상충 관계를 유발할 주요 요구 사항과 사용 사례 개요

d) 하나 이상의 후보 아키텍처 개요

e) 위험 확인

f) 비용 산정 및 예비 프로젝트 준비

(b) Construction 반복

테스트의 두 번째 단계는 Construction Iterations이며 대부분의 테스트는이 단계에서 수행됩니다. 이 단계는 솔루션의 증분을 만들기위한 일련의 반복으로 관찰됩니다. 그렇게하기 위해 각 반복 에서 팀 은 XP, 스크럼, 애자일 모델링 및 애자일 데이터의 연습을 혼합합니다.

건설 반복에서 애자일 팀은 우선 요구 사항을 따르고 있습니다. 반복 할 때마다 작업 항목 스택에 남아있는 가장 기본적인 요구 사항을 수행하고 구현합니다.

건설 반복은 확인 테스트와 조사 테스트의 두 가지로 분류됩니다.  확인 테스트는 시스템이 현재까지 팀에 설명 된대로 이해 관계자의 의도를 충족시키고 팀이 수행하는지 확인하는 데 집중 합니다. 수사 시험은 확인 팀이 건너 뛰거나 무시한 문제를 발견하는 동안. 조사 테스트에서 테스터는 잠재적 인 문제를 결함 사례의 형태로 결정합니다. 조사 테스트는 통합 테스트,로드 / 스트레스 테스트 및 보안 테스트와 같은 일반적인 문제를 다룹니다. 

다시 한번 확인 테스트에는 개발자 테스트 와 애자일 테스트의 두 가지 측면이 있습니다 . 두 제품 모두 라이프 사이클 전반에 걸쳐 지속적인 회귀 테스트가 가능하도록 자동화되어 있습니다. 확인 테스트는 사양을 테스트하는 것과 동등한 방법입니다. 

애자일 수용 테스트는 개발 팀으로서 전통적인 기능 테스트와 전통적인 수용 테스트를 결합한 것이며 이해 관계자가 함께 수행합니다. 개발자 테스트는 전통적인 단위 테스트와 전통적인 서비스 통합 테스트가 혼합 된 것입니다. 개발자 테스트는 응용 프로그램 코드와 데이터베이스 스키마를 확인합니다.

(c) 게임 종료 또는 게임 종료 단계 해제

"Release, End Game"의 목표는 시스템을 프로덕션에 성공적으로 전개하는 것입니다. 이 단계에는 최종 사용자 교육, 사람 및 운영 담당자 지원 등의 활동이 포함됩니다. 또한 제품 출시 마케팅, 백업 및 복원, 시스템 완성 및 사용자 문서화가 포함됩니다.

최종 테스트 단계에는 전체 시스템 테스트 및 수락 테스트가 포함됩니다. 장애물이없는 최종 테스트 단계를 완료하면 건설 반복 과정에서 제품을보다 엄격하게 테스트해야합니다. 게임이 종료되는 동안 테스터는 결함에 대한 작업을 진행합니다.

(d) 생산

출시 단계가 지나면 제품이 제작 단계로 넘어갑니다.

애자일 테스트 쿼드런트

애자일 테스트 사분면은 4 개의 쿼드런트에서 전체 프로세스를 분리하고 애자일 테스트 수행 방법을 이해하는 데 도움이됩니다.

a) Agile Quadrant I - 내부 코드 품질이이 사분면의 주요 초점이며 기술 주도형이며 팀을 지원하기 위해 구현되는 테스트 사례로 구성됩니다.

1. 단위 테스트

2. 구성 요소 테스트

b) Agile Quadrant II - Agile 사분면 II - 비즈니스를 주도하고 팀을 지원하기 위해 구현되는 테스트 케이스를 포함 합니다. 이 사분면은 요구 사항에 중점을 둡니다. 이 단계에서 수행되는 테스트의 종류는 다음과 같습니다.

1. 가능한 시나리오 및 워크 플로의 예제 테스트

2. 프로토 타입과 같은 사용자 경험 테스트

3. 페어 테스트

c) Agile Quadrant III -이 사분면은 사분면 1과 2에 피드백을 제공합니다. 테스트 케이스는 자동화 테스팅을 수행하기위한 기초로 사용될 수 있습니다. 이 사분면에서는 제품에 대한 신뢰를 얻는 반복 검토가 수행됩니다. 이 사분면에서 수행되는 테스트의 종류는

1. 사용성 테스트

2. 탐색 적 테스트

3. 고객과의 쌍 테스트

4. 협업 테스트

5. 사용자 수용 테스트

d) Agile Quadrant IV - 이 사분면 은 성능, 보안, 안정성 등과 같은 비 기능적 요구 사항에 중점을 둡니다.이 사분면의 도움으로 응용 프로그램이 비 기능적 품질과 기대치를 제공합니다.

1. 스트레스 및 성능 테스트와 같은 비 기능 테스트

2. 인증 및 해킹 과 관련된 보안 테스트

3. 인프라 테스팅

4. 데이터 마이그레이션 테스트

5. 확장 성 테스트

6. 부하 테스트

애자일 소프트웨어 개발로 인한 QA 과제

a) 문서의 우선 순위가 낮아짐에 따라 오류가 발생할 가능성이 더 높아짐에 따라 궁극적으로는 품질 보증팀에 더 많은 압력을가합니다.

b) 새로운 기능이 신속하게 도입되어 테스트 팀이 최신 기능이 요구 사항에 맞는지 여부를 식별 할 수있는 시간을 줄이고 진정한 비즈니스 슈트를 해결합니다.

c) 테스터는 종종 준 개발자 역할을해야한다.

d) 시험 실행주기가 매우 압축되어있다.

e) 테스트 계획을 준비하는 시간이 매우 적다.

f) 회귀 테스트의 경우, 최소한의 타이밍

g) 품질의 문지기 역할에서 품질의 동반자 역할로의 역할 변화

h) 요구 사항 변경 및 업데이트는 애자일 방법에 내재되어있어 QA에서 가장 큰 과제가됩니다.

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

• 자동화 된 UI는 높은 수준의 자신감을 제공하지만 실행 속도가 느리며 유지하기가 어려우며 구축에 많은 비용이 소요됩니다. 테스터가 테스트 방법을 알고 있지 않으면 자동화를 통해 테스트 생산성이 크게 향상되지 않을 수도 있습니다.
• 신뢰할 수없는 테스트는 자동화 된 테스트의 주요 관심사입니다. 취약한 테스트를 수정하고 취성 테스트와 관련된 문제를 해결하는 것은 오 탐률을 피하기 위해 최우선 적으로 고려해야합니다.
• 자동화 된 테스트가 CI (Continuous Integration)가 아닌 수동으로 시작되면 정기적으로 실행되지 않아 테스트가 실패 할 위험이 있습니다
• 자동화 된 테스트는 탐색적인 수동 테스트를 대체하지 않습니다. 제품의 예상 품질을 얻으려면 테스트 유형과 레벨이 혼합되어 있어야합니다
• 많은 상업적으로 사용 가능한 자동화 도구는 수동 테스트 케이스 캡처 및 재생 자동화와 같은 간단한 기능을 제공합니다. 이러한 도구는 UI를 통한 테스트를 장려하고 본질적으로 부서지기 쉽고 테스트를 유지하기 어렵게 만듭니다. 또한 테스트 케이스를 버전 제어 시스템 외부에 저장하면 불필요한 복잡성이 발생합니다.
• 시간을 절약하기 위해 여러 번 자동화 테스트 계획이 잘못 계획되거나 계획되지 않아 테스트가 실패합니다
• 수동 테스트 수행, 테스트 설정 및 제거 절차 수행이 원활하게 이루어지면서 테스트 자동화 및 테스트 절차는 일반적으로 빠져 있습니다.
• 하루에 생성되거나 실행되는 테스트 케이스의 수와 같은 생산성 메트릭은 오해의 소지가 있으며 쓸모없는 테스트 실행에 많은 투자를 할 수 있습니다
• 애자일 자동화 팀의 구성원은 접근하기 쉽고 협조적이며 수완이 풍부한 효과적인 컨설턴트 여야합니다. 그렇지 않으면이 시스템이 빨리 실패합니다
• 자동화는 제공된 값에 비해 너무 많은 지속적인 유지 관리가 필요한 테스트 솔루션을 제안하고 제공 할 수 있습니다.
• 자동화 된 테스트는 효과적인 솔루션을 구상하고 제공 할 전문 지식이 부족할 수 있습니다.
• 자동 테스트는 너무 성공적이어서 해결해야 할 중요한 문제가 없어져서 중요하지 않은 문제가 발생합니다.

결론

애자일 테스트에는 소프트웨어 개발 수명주기에서 가능한 한 빨리 테스트가 포함됩니다. 사용 가능 해지 자마자 높은 고객 개입과 테스트 코드가 필요합니다. 코드는 시스템 테스트를 수행 할 정도로 안정적이어야합니다. 광범위한 회귀 테스트를 통해 버그를 수정하고 테스트 할 수 있습니다. 주로 팀 간의 의사 소통을 통해 애자일 테스트가 성공적으로 이루어집니다 !!!