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

by | Mar 15, 2024

애자일 QA(Quality Assurance, 품질 보증) 절차는 애자일 프레임워크 내에서 개발된 소프트웨어가 원하는 품질 기준의 충족을 보장하기 위한 일련의 관행과 방법론이다. 이는 협업, 유연성 그리고 지속적인 개선을 강조하는 애자일 개발 원칙에 맞아 떨어진다.

왜 애자일 QA로 전환해야 할까?

애자일은 소프트웨어 개발에서 가장 인기 있는 방법론 중 하나다. 애자일 프로젝트는 전통적인 프로젝트 관리 방법에 비해 더 높은 적응성, 고객 만족도, 효율성, 품질, 팀 협업 등과 같은 우수한 결과를 내는 경향이 있기 때문이다.

애자일 개발이 이미 시행되고 있다면, 기존 애자일 환경에서 제공하는 이점을 활용하여 절차를 더 효율적으로 만드는 것도 QA 팀에게 유익할 것이다. QA 팀이 기존의 애자일 개발 환경과 통합하면, 개발 주기 내에서 테스트를 조정하여, 반복적인 특성에서 이점을 얻을 수 있다. 이런 통합은 협업, 적응력을 발전시키고, 고객 요구 사항에 더 집중할 수 있게 해 준다. 그 결과, 궁극적으로 테스트 수행의 절차를 더 효율적이고 효과적으로 만든다.

그런데 애자일 QA는 기존의 전통적인 QA 방법론과 어떻게 다를까?

폭포수(waterfall) 방식을 사용하면, 테스트 수행은 일반적으로 개발 절차의 후반부에 진행된다. 이는 시간을 상당히 지체하고 나서야 팀이 테스트 수행을 시작하게 된다. 그 결과, 드디어 테스트가 수행되기 시작하고 난 후에, 어려운 선택을 마주치게 되는 경우가 많다. 즉, 출시일을 연기하고 철저한 테스트 수행을 보장하거나, 아니면 테스트 수행을 서둘러 마감일을 맞추는 대신 품질 위험을 무릅쓰거나 둘 중 하나를 선택해야 하는 상황에 처하곤 한다.

애자일 QA에서는, QA 팀이 소프트웨어 개발 수명 주기(Software Development Lifecycle, SDLC)의 초기부터 참여한다. 이는 전통적인개발 방식에서 떨어져 나온 것으로 지속적 테스트 수행 (continuous testing)이라고 부른다. 이렇게 QA 팀이 일찍부터 참여하게 되면, 이해관계자들의 피드백을 신속하게 받아들일 수 있다. 따라서 즉각적으로 맞춰갈 수 있다.

코딩에서 코드 리뷰가 필요한 것과 같이, 지속적인 테스트 수행은 제품의 지속적인 문제 식별에 있어 중요하다. 테스트 자동화는 피드백 절차를 더 신속하게 만드는 데에도 도움이 될 수 있다. 특히 회귀 테스트 수행이나 기능 테스트 수행과 같이 반복적이고 시간이 많이 소요되는 테스트를 실행하려는 경우에 유용하다.

애자일 QA의 원칙

다음은 애자일 QA에서 필수적인 몇 가지 원칙이다:

1. 조기 및 빈번한 테스트

“시프트 레프트” 접근방식은 QA를 개발 초기부터 참여시키고 QA 팀과 개발 팀 간의 상호 이해를 증진하여 제품의 더 높은 품질을 위한 공동의 추진력을 함양한다. 테스트 수행은 새로운 기능을 도입할 때에만 하는 것이 아니다. 모든 코드 개선, 수정, 그리고 UI 업데이트와 함께 지속적으로 진행해야 한다. 이 빈번한 테스트는 개발 주기 전반에 걸쳐 지속적인 품질 보증을 촉진한다.

2. 가능한 것은 자동화하되, 모든 것을 자동화하지는 않아야 한다.

자동화는 애자일 QA에 필수적이다. 그러나 비용은 여전히 발생하기 때문에 전략없이, 되는대로 자동화 해서는 안된다. 중요한 점은, 시간이 오래 걸리고, 지루한 테스트 수행 부분을 자동화 해야 한다는 것이다. 어쨌든 수작업 테스트 수행이 절차상에서 완전히 사라지게 만들라는 의미는 아니다. 수작업 테스트 수행은 에지 케이스를 놓치지 않기 위해 여전히 필요하다. 탐색 테스트처럼 인간의 사고 방식과 호기심이 필요한 테스트도 있기 때문이다.

그림: TestRail을 TestRail을 탐색적 테스트 수행(exploratory testing) 도구로 사용해 보자. 그러면, 여러분의 탐색적 테스트 케이스들에 대한 리포트 생성 절차를 관리, 정돈, 추적, 간소화 할 수 있다.

3. 지속적인 피드백과 개방적인 커뮤니케이션 제공

개방적인 커뮤니케이션 채널을 만들어 지속적으로 대화를 이끌어야 한다. 또 피드백과 다양한 의견을 공유하는 것을 가치있게 여기는 문화를 조성한다.

이해관계자와 함께 제품의 데모를 진행하여 지속적인 개선을 뒷받침 하도록 한다. 또, 이해관계자의 기대에 맞춰 제품이 발전할 수 있도록 피드백이 풍부한 환경을 조성한다.

테스트 수행 절차 내에서 투명성을 구축하여 팀이 솔직하고 건설적인 피드백을 제공하기에 편안한 환경을 만든다. 이런 피드백이 가치 있게 여겨지며, 팀이 의견을 공유하는 공간이 안심할 수 있다는 것을 강조한다. 비난 대신 교육을 강조하여 잘못을 지적하기보다 배움과 개선이 우선하는 문화를 장려한다.

4. 책임감과 공동으로 주인 의식을 가지는 문화를 장려한다.

프로젝트의 성공은 특정 개인에게만 의존해서는 안된다. 각 팀 구성원들이 프로젝트 전체에 대해 책임감을 가져야 한다. 이런 공동 책임감은 주인 의식과 헌신을 공유하게 한다. 그리하여 프로젝트 목표 달성을 위해 공동의 협력을 촉진한다.

5. 최종 사용자에게 집중하기

본질적으로 제품의 성공 여부는 고객에게 가치를 전달하는 데 달려있다. 여러분의 팀이 아니라 최종 사용자가 제품을 사용하게 된다는 것을 유념하라. 테스트 수행 접근 방식을 결정할 때, 사용자 경험과 제품의 사용 편의성을 우선해야 한다. 테스트 전략을 수립할 때 최종 사용자의 요구에 중점을 두어야 한다. 그러면 그들의 기대와 요구를 정확히 충족하는 제품을 만들 수 있다.

6. 변화에 대응하기

팀에게 자율권을 줘서 예상치 못한 변화에 유연하게 대응하고 적응할 수 있게한다. 민첩성을 수용하는 사고방식을 기른다. 그러면 팀이 프로젝트 중에 발생하는 변경 사항이나 문제에 신속하게 대응하고 효과적으로 처리할 수 있다.

7. 자기 구조화(self-organize)

팀에게 자율성을 부여해, 업무를 할당하고 진행 상황을 추적하여 스스로 관리할 수 있도록 한다. 팀은 이 자율성을 통해 주인 의식을 갖고 작업에 임하게 된다. 이로인해 팀이 값지면서, 최고 품질의 소프트웨어를 내놓기 위해 분투할 때 책임감과 효율성을 높일 수 있다.

애자일 QA 절차의 주요 단계

SDLC와 관련하여 애자일 QA 절차를 실행할 때 기억해야할 몇 가지 핵심 사항은 다음과 같다.

계획하기

개발 주기의 계획 단계에서 QA 팀의 조기 참여가 중요하다. 이 참여를 통해 기능에 잠재되어 있는 리스크에 대해 브레인스토밍할 수 있다. 그리고 어떤 테스트가 테스트 실행 주기에서 실행되어야 하는지 사전에 계획할 수있다.

핵심은 문서화가 잘되어있고, 신뢰할 수 있으며, 애자일한 테스트 케이스를 만드는 것이다. 조기 협업을 통해 QA 팀이 효과적으로 계획하고, 문제를 예측하고, 리스크 완화 전략을 수립할 수 있다.

실행

개발자들과 테스터들이 서로 다른 팀으로 나뉘어 적대적으로 행동하면 안된다. 버그를 찾고 이를 해결하기 위해 협력해야 한다. 어떤 경우에는, 개발자들과 테스터들이 한 팀을 이루는 것이 애자일 QA 절차를 개선하는 데 도움이 된다. 양쪽이 서로의 지식을 공유함으로써 고품질 소프트웨어를 만들 수 있기 때문이다. 또한, 테스트 실행 주기가 완료된 후에는 발견된 버그를 신속하게 보고하고, 적절한 QA 지표를 사용하여 철저하게 분석하는 것이 중요하다.

지속적인 개선

프로젝트가 진행됨에 따라 QA 팀도 지속적인 변화에 적응할 수 있어야 한다. 이를 위해, QA 절차를 정기적으로 검토하고 각 스프린트를 되돌아보고 수정 조치를 할 수 있는 회고의 시간을 가지는 것이 도움이 된다. 회고를 진행할 때 고려해야 할 몇 가지 질문은 다음과 같다:

  1. 이번 스프린트에서 잘 된것은 무엇인가?
  2. 어떤 어려움을 겪었는가?
  3. 팀으로서의 협업이 얼마나 효과적이었는가?
  4. 스프린트의 목표를 달성했는가? 아니라면 그 이유는 무엇인가?
  5. 다음 스프린트를 위해 어떤 점을 개선할 수 있을까?
  6. 장애물이나 병목현상을 직면한 적이 있는가?
  7. 우리의 절차와 전략이 효과적으로 작동했는가?
  8. 우리가 한 팀으로서 서로를 더 잘 지원하려면 어떻게 해야 할까?

의사 소통과 협업

QA 팀, 개발 팀, 이해관계자들 간의 개방적인 의사 소통을 유지하는 것은 매우 중요하다. 그들의 피드백을 수용하고 값진 인사이트에대해 심사숙고하는 것은 필수적이다. 필요하다면, 최종 사용자의 문제를 해결하고 궁극적인 프로젝트 목표를 달성할 수 있도록 요구 사항에 맞게 조정할 준비가 되어 있어야 한다. 이런 융통성은 보다 사용자 중심적이고 효과적인 개발 절차를 촉진한다.

애자일 QA 방법론

테스트 팀이 필요에 따라 사용할 수 있는 몇 가지 애자일 QA 방법론이 있다. 그 중에서 가장 많이 사용되는 것은 다음과 같다:

  1. 테스트 중심 개발(TDD, Test-driven development): 여기서 코드는 유닛 테스트 케이스가 생성된 후에 작성한다. 최적화는 그 다음에 이루어진다.
  2. 수용 테스트 중심 개발(ATDD, Acceptance test-driven development): 프로젝트 요구 사항과 밀접하게 연계된 수용 테스트를 개발한다. 그 다음에 코드를 작성하는 절차를 따른다. TDD(Test-driven development)의 유닛 테스트 케이스는 테스트가 코드 기능에 더 중점을 둔다. 반면에 ATDD(Acceptance test-driven development)는 명료하게 수용 기준을 기반으로 테스트를 생성하는 데 우선 순위를 둔다. 이후 코드를 최적화하여 사전 정의된 기준을 충족시키는 것이 ATDD의 목표다.
  3. 행동 중심 개발(BDD, Behavior-driven development): 이 유형의 방법론에서는 시스템 동작이 매번 요구 사항을 충족하는지 확인하기 위해 테스트를 실행한다.

애자일 QA의 성공 여부 측정하기

양적 및 질적 QA 지표로 QA 절차의 효과를 평가할 수 있다. 조직은 특정 상황이나 전략에 따라 다양한 지표를 선택할 수 있다. 이 지표는 QA 실행의 성과와 성공을 평가하는 기준이 된다. 그래서 조직의 목표와 목적에 맞는 맞춤형 평가를 가능하게 한다.

다음은 애자일 QA의 성공 여부를 측정하는 데 사용할 수 있는 QA 지표를 표로 정리한 것이다:

QA 지표 공식측정 대상
테스트 노력 테스트 노력을 계산하는 공식은 노력을 정의하고 측정하는 방식에 따라 달라질 수 있다. 다음은 이를 표현하는 몇 가지 방법이다:
소요 시간: 테스트 노력= QA 팀이 테스트 작업에 소요한 총 시간
총 프로젝트 노력의 백분율: 테스트 노력=(테스트에 소요된 시간/ 총 프로젝트 시간)x100
테스트 케이스 커버리지 대 노력: 테스트 노력=(생성된 테스트 케이스의 수+실행된 테스트 케이스의 수)/생성 및 실행된 테스트에 사용된 노력
결함 밀도 대 노력: 테스트 노력= 발견된 결함의 수/테스트에 투자한 노력
자동화 비율: 테스트 노력=(수작업 테스트 수행에 소요된 시간-자동화된 테스트 수행)/테스트에 소요된 총 시간
테스트 효과(하나의 테스트에서 감지된 버그 수/테스트에서 발견된 총 버그 수+릴리스 이후 발견된 총 버그 수)x100
테스트 커버리지(실행된 테스트의 수/실행해야 하는 테스트의 수)x100
요구 사항 커버리지(테스트가 커버한 요구사항 수/총 요구사항 수)x100
결함 밀도결함 수/측정 단위
측정 대상 소프트웨어의 크기, 양, 범위를 정량화 하는데 사용되는 특정 매개변수 또는 지표를 나타낸다.
예를 들면: 소프트웨어의 코드 줄의 수, 소프트웨어용으로 설계된 개별 테스트 케이스의 수, 또는 소프트웨어의 개별 모듈 혹은 섹션의 수 등이 있다.
결함 분포버그 밀도가 가장 높은 컴포넌트를 식별한다.
결함 처리 시간버그 발견부터 해결까지 걸리는 시간
고객 만족도일련의 핵심 성과 지표로(KPI, Key Performance Indicator)로 측정
결함 누수제작 중 또는 UAT에서 발견된 버그/ 테스트에서 발견된 버그

이 목록이 완전하지는 않지만, 현재의 QA 절차가 조직에 효과적인지 확인하는 데 도움이 될 것이다.

애자일 QA 절차 구현을 위한 모범 사례

애자일 QA 절차를 구현할 때 참고해야 할 모범 사례는 다음과 같다:

  • 수작업으로 진행 시 지루하고, 많은 시간이 소요되며, 반복적인 테스트를 대상으로 자동화 구현한다.
  • 개발 팀과 QA 팀 간의 협업을 보장하기 위해 팀내에서 의사 소통의 장을 유지하고 신뢰와 투명성을 형성한다.
  • 피드백 제공 시 수용 기준을 표준으로 사용한다.
  • 반복적인 개발 및 지속적인 테스트 수행을 지원하기 위해 지속적 통합, 지속적 배포(CI/CD, Continuous Integration/Continuous Delivery) 파이프라인 및 기타 데브옵스(DevOps) 도구를 활용한다.
  • 제품에 가치를 더하기 위해 애자일 QA 지표를 활용한다.
  • 제품의 품질을 향상시키는 방법에 대한 피드백을 얻기 위해 이해관계자들과 제품의 데모를 수행한다.

TestRail과 같은 테스트 관리 도구는 애자일 QA에 다음과 같은 이점을 제공한다:

  • 테스트 케이스 관리: TestRail을 사용하면 테스트 케이스의 생성, 구성, 관리를 쉽게 할 수 있다. 애자일 팀의 경우, 이는 테스트 시나리오의 개요를 효율적으로 작성하는 것과 반복 전체에 걸친 포괄적인 커버리지를 보장하는 것을 의미한다.
  • 가시성과 협업: TestRail은 팀이 중앙 집중식 플랫폼을 제공하여, 테스트의 실행, 결과, 진행 상황에 대한 가시성을 보장한다. 이를 통해 교차 기능 애자일 팀간의 원활한 커뮤니케이션이 가능하다.

그림: 개별 테스트 실행부터 테스트 케이스 승인 절차 수립까지 모든 것을 손쉽게 관리할 수 있다. 팀의 집단 전문성을 활용하여 팀이 언제 무엇을 작업해야 하는지 알 수 있다.

  • 추적성: TestRail은 테스트 케이스를 사용자 스토리나 요구 사항에 연결하여 추적성을 보장한다. 이는 애자일 팀이 각 기능이나 요구 사항에 대한 테스트 커버리지를 이해하는 데 도움이 된다.

그림: 모든 테스트 수행 활동의 진행 상황을 한곳에서 모니터링 하여 규정 준수를 지속하고, 리스크를 더 신속하게 분류하라. 수작업 탐색적 테스트부터 자동 회귀 테스트에 이르기까지 모든 테스트를 포함한다.

  • 테스트 실행 및 보고: TestRail은 테스트 실행을 지원한다. 그리하여 팀이 효율적으로 테스트를 실행하고 보고할 수 있게 한다. 애자일 팀은 종합 적인 보고서를 생성하여, 테스트 결과 및 진행상황에 대한 인사이트를 얻을 수 있다.

그림: TestRail의 마일스톤(요약) 보고서를 통해 사용자는 프로젝트 기준을 부여한다. 그리고 마일스톤 활동에 대한 정확하고 공유 가능한 해석을 빠르게 시각화 할 수 있다.

  • 적응성: TestRail의 유연성은 애자일 팀이 변화하는 요구 사항에 쉽게 적응할 수 있도록 해준다. 소프트웨어의 신작이 발전함에 따라 테스트 케이스나 계획 변경할 수 있다.
  • 애자일 도구와 통합: TestRail은 Jira, Trello, Asana와 같은 다양한 애자일 프로젝트 관리 도구와 통합되어 워크플로우를 간소화 한다. 이 통합을 통해 테스트 관리와 애자일 개발 활동을 원활하게 동기화한다.

그림: Selenium, 유닛 테스트 수행 프레임 워크처럼 인기있는 도구 또는 Jenkins 처럼 지속적인 통합(CI, continuous intergration) 시스템 사용에 관계없이, TestRail은 거의 모든 도구와 통합될 수 있다.

요점

애자일 QA 절차는 조직내에서 QA 실행을 가속화 하고 강화하며 개선한다. 이는 신속한 피드백을 받기위해 신속하고 반복적인 배포를 추구하는 애자일 방법론에 잘 맞다. 각 반복에서 가치 있는 제품의 생산을 지속적으로 유지하는데 중점을 둔다.

모든 절차에는 각기 어려움이 따르기 마련이다. 하지만 애자일 QA의 경우에는 리스크 보다는 장점이 훨씬 크다. 잠재적인 이점을 고려하여 애자일 QA를 구현해 보자. 이는 제품이나 서비스의 품질을 향상시키고자 하는 조직에게 값진 단계들이 될 수 있다.

TestRail이 애자일 테스트 전략을 성공적으로 구현하도록 지원하는 방법에 대해 자세히 알아보려면 TestRail 아카데미를 확인해 보자. 애자일 테스트 수행, 테스트 수행의 기본, 테스트 자동화 등의 주제에 대한 내용들을 확인 할 수 있다!

애자일 QA 자주하는 질문

애자일 QA 역할들

애자일 QA에서, 개발 팀과 QA 팀은 분리되어 운영되지 않고 긴밀하게 협력한다. 통합된 팀내에서 구별되는 역할에 대한 분석은 다음을 참고한다:

QA 매니저

A 매니저는 단순히 리더로서 QA 팀의 관리만 하는 대신, 테스트의 지침, 기준, 방법론을 제공하는 주제별 전문가가 되어야 한다.

QA 리드

QA 팀의 다른 구성원들의 도움을 받아 사용할 테스트 관리 도구, 테스트 수행의 접근방식 및 전략, 그리고 테스트 수행 팀을 위해 생산적인 워크플로를 위한 최선의 방법 등을 결정해야 한다.

개발자

테스트 수행에서 개발자의 참여는 다양한 이유로 애자일 QA에 매우 중요하다.

  • 빠른 버그 식별: 개발자들은 코드를 깊이 있게 이해하여 문제를 빠르게 발견한다.
  • 향상된 커뮤니케이션: 팀 간의 간극을 좁히고 요구 사항을 명확히 한다.
  • 즉각적인 수정: 개발자는 착오를 즉시 해결한다.
  • 공동 품질 책임: 개발자가 제품 품질에 대한 책임을 진다.
  • 최적화된 테스트 수행: 개발자들은 목표를 정확하게 설정하고 효율적인 테스트에 집중한다.
  • 빠른 피드백 루프: 개발 주기에서 문제를 조기에 발견한다.
  • 향상된 테스트 자동화: 개발자의 참여로 자동화 테스트 수행 관행이 개선된다. 개발 팀은 화이트 박스 테스트 수행을 위한 자동화 코드를 작성하여 유닛 및 통합 테스트를 수행할 수 있다.

자동화 테스터

이 테스터는 회귀 테스트, 종단종(end to end) 테스트, 시각적 테스트 등과 같은 자동화 테스트를 위해 코딩 스크립트를 작성한다.

수작업 테스터

한 명의 팀 구성원이 자동 테스트와 수작업 테스트(예: QA 엔지니어)를 모두 수행할 수도 있다. 하지만 수작업 테스트 수행은 자동화 테스트 수행보다 더 실제적인 접근 방식이 필요하다.

자동화 테스트 수행에는 코드 작성이 필요하다. 하지만 수작업 테스트에는 사람의 사고 과정과 호기심만 있으면 된다. 탐색적 테스트 수행과 승인 테스트 수행과 같은 시나리오에 사용할 수 있다.

제품 소유자

제품 소유자는 이해관계자를 대표하여 팀에게 요구 사항을 전달한다. 이들은 기능의 우선순위를 정하고, 제품의 백로그를 관리한다. 그리고 개발이 완료된 소프트웨어가 비즈니스 요구사항을 충족시키는지 확인한다.

제품 소유자는 사용자 승인 테스트(UAT)의 결과를 안내, 검증, 수락하는 데 중요한 역할을 한다. 이를 통해 개발된 제품이 비즈니스 목표를 달성하고 이해관계자의 기대를 충족하는지 확인한다.

애자일 QA에서의 일반적인 과제

애자일 QA에서는 일반적으로 다음과 같이 여러 가지 해결해야할 과제가 발생할 수 있다:

변화에 대한 거부감

애자일에 익숙하지 않은 팀들은 이 방법들이 요구하는 유연성으로 인해 변화에 저항감을 가질 수 있다. 애자일 사고방식을 조기에 도입하면 유익하다. 특정 절차를 엄격하게 준수하기 보다 가치있는 제품을 제공한다는 최종 목표를 강조하기 때문이다. 이런 사고방식의 전환은 전이를 쉽게 만들고, 가치 창출이라는 최종 목표에 우선순위를 둘 수 있게 한다.

예산의 리스크

자원 할당의 리스크는 새로운 기능에 적응하고 우선순위에 변화가 일어날 때 발생할 수 있다. 유연한 예산 책정 방식을 채택해 프로젝트에 미치는 영향을 최소화 한다.

일정 리스크

애자일에서는 테스트 실행 주기가 짧다. 그래서 자세한 테스트 계획을 수립하고 테스트를 철저히 수행할 시간이 적다. 일정은 갑작스럽게 변경될 수도 있다. 그러므로 팀은 효과적으로 리스크를 관리하고 빠르게 적응할 준비가 되어 있어야 한다.

범위 증가 가능성

모든 고객의 요구를 충족하는 제품을 만들고 싶을 수도 있다. 하지만 그렇게 하면주 사용자에게 필요하지 않은 제품이 될 리스크가 있다. 프로젝트에 무엇이 포함되는지, 무엇이 포함되지 않는지 범위를 명확히 정의하는 것이 중요하다. 범위 증가를 방지하기 위해서다. 이렇게 명확하게 정의하면 제품이 불필요한 추가 요소 없이 사용자의 요구 사항에 가깝게 맞춰질 수 있다.

문서화 부족

애자일 방법론은 상세한 문서화 보다 제품의 기능적인 면을 우선시 한다. 그 때문에 팀내에 문서가 부족해질 수 있다. 이 문서 부족은 범위 증가 및 기타 문제의 리스크를 높일 수 있다. 그렇기 때문에 문서화를 완전히 간과해서는 안된다. 제품의 이해와 유지 관리를 위해 필수적인 주요 세부 사항에 집중해야한다. 실질적인 가치를 더하는 문서 작성에 중점을 두어야 한다.

애자일 QA의 이점

다음은 애자일 QA 절차를 구현할 때 얻을 수 있는 몇 가지 이점에 대한 목록이다:

  • 신속한 버그 탐지: 애자일 팀은 초기에 빈번한 테스트 수행을 위해 자주 반복적인 릴리스를 중요시한다. 애자일 QA는 이 릴리스를 가능한 한 빨리, 자주 테스트 하는 것을 목표로 하여 이 접근 방식에 부합한다. 이 전략을 통해 개발 팀은 발견된 버그를 신속하게 해결하고, 수정 사항을 지체 없이 릴리스할 수 있다.
  • 빠른 피드백 루프: 종속성을 위한 기다림이 필요없다. 애자일 QA는 소프트웨어 개발 절차가 완료될 때까지 기다릴 필요가 없다. 기다리게 만드는 장애물을 제거하기 때문이다. 결과물이 테스트 가능한 상태가 되면, QA 팀은 즉각적으로 테스트를 수행한다.
  • 고도의 협업: QA 팀은 절차에 초기부터 참여하여, 문제를 식별해낼 뿐만 아니라 제품이나 절차를 개선하기 위한 인사이트를 제공한다. 이 적극적인 참여를 통해 개선을 위한 값진 아이디어를 제안할 수 있게된다.
  • 유연성: 조직내에서 우선 순위가 변경되면, 애자일 QA 팀은 중심을 전환한다. 그로인해 새로운 문제에 재빨리 적응할 수 있다
    최적화된 리소스: 병목 현상이나 장애물이 발생할 가능성이 있는 경우, 애자일 QA 팀은 리소스를 다시 할당할 수도 있고, 우선 순위를 다시 정할 수도 있다.
  • 중앙 집중식 소프트웨어 테스트 수행 도구 및 절차: 소프트웨어 테스트 수행 절차와 도구를 중앙 집중화하는 것은 엄격함을 의미하는것이 아니다. 즉각적으로 테스트 수행을 구현하기 위해 표준과 도구를 마련한다는 의미다. 기존 프레임워크가 이미 마련되어 있다면, 그 테스트 절차를 필요에 따라 조정하거나 발전시키는데 방해가 되지 않는다.
  • 비용 절감: QA 팀이 초기에 참여하게 되면, 잠재적으로 많은 비용을 발생시킬 수 있는 버그를 초기에 발견하고 수정할 수 있다.

(원문: Hannah Son | February 15th, 2024 | Agile QA Process: Principles, Steps, and Best Practices)

다른 기고들

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

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

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

애자일에서는 개발과 테스트 수행이 동시에 진행된다. 그로 인해 개발 파이프라인이 간소화 된다. 이는 효율적이고 정확한 소프트웨어 출시를 보장하기 위한 것이다. 애자일 개발에서는 프로젝트를 스프린트로 세분화한다. 이와 비슷하게, 애자일 테스트 수행에서는, 대규모 기능 개발을 더 작고 관리하기 쉬운 스프린트 기반 프로젝트와 제품으로 세분화 한다. 애자일 테스트 수행의 원칙은 무엇인가? 애자일 프레임워크에서 테스트 수행을 할 때, 절차의 지침이 되는 몇 가지 원칙이 있다: 테스트...

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

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