리스크 기반 테스트의 장단점 이해하기

by | Mar 26, 2024

“리스크는 자신이 무엇을 하는지 모르는 데에서 부터 온다.”

워렌 버핏(Warren Buffett)

소프트웨어 테스트 수행에도 동일한 원칙이 적용된다. 테스트를 하는 이유와 대상을 모를 때, 리스크가 우리를 기다린다. 소프트웨어 제품의 경우, 제품의 품질에 영향을 미치는 결함의 유출이 리스크가 된다. 이는 결국에는 비즈니스 손실, 영업 손실로 이어진다.

제품의 어떤 특징, 기능 또는 모듈의 결함이 미치는 영향을 알면 리스크를 파악할 수 있다. 그 다음에는 해당 테스트의 우선순위를 지정하여 생산 환경에서 결함의 리스크를 완화하거나 피할 수 있다. 이 모든 절차를 위험-기반 테스트 수행(Risk-Based Testing) 혹은 RBT라고 한다.

간단히 말해, RBT는 조기에 제품에서 리스크가 높은 영역의 테스트를 수행할때, 우선순위를 정하고, 최적화한다. 그리고 실제 사용자의 예상대로 작동하는지 확인한다. 이는 애자일 환경에서는 완전히 합리적이다. 짧은 스프린트 기간 안에 선택적으로 테스트 수행이 이루어진다. 때문에 소프트웨어가 치명적인 결함을 가진 상태로 출시되는 것을 피할 수 있다.

리스크 기반 테스트 수행이란 무엇인가?

리스크란 무엇인가? 소프트웨어 테스트 수행에서, 리스크는 생산 환경에서의 예기치 못한 보안, 기능, 규정 준수, 성능에 대한 장애(위협) 등으로 정의 할 수 있다.

리스크 기반 테스트 수행(RBT)을 활용하여, 팀은 이 리스크들을 식별하고 평가한다. 그런 다음, 테스트 수행 절차에 따라 가장 치명적인 리스크를 개발 주기 초기에 테스트 하여 생산 단계에서 결국 피해 갈 수 있게 한다.

RBT는 일반적으로 다음과 같은 상황에서 적용된다:

시나리오설명
복잡한 애플리케이션여러 컴포넌트가 있는 복잡한 소프트웨어의 테스트 수행에 대해 우선순위를 정한다. 이를 위해 복잡성으로 인해 실패하기 쉬운 영역에 집중한다.
짧은 테스트 일정RBT를 이용해 촉박한 일정의 프로젝트의 테스트 수행 작업을 최적화 한다. 그러면 제한된 시간 안에 중요한 기능을 중점적으로 테스트 할 수 있다.
하이-리스크 시스템RBT를 하이-리스크 시스템에 적용한다. 이로써 잠재적인 장애로 인한 막대한 재정적 손실이나 데이터 손실을 방지할 수 있다.
예산 제한RBT를 활용하여 제한된 예산 내에서 테스트 수행 절차를 최적화한다. 그러면 사용 가능한 자원으로 테스트 수행의 효과를 극대화 할 수 있다.
규정 준수 및 규정RBT를 활용하여 의료 및 금융과 같은 영역의 규정을 준수한다. 그러기 위해 그에 맞춰 테스트 활동에 집중한다.
결함에 대한 이력결함의 반복적 발생 이력이 있는 모듈에 RBT를 집중한다. 그리고 각 테스트 수행 주기에서 이 영역에 특별히 주의를 기울인다.

리스크-기반 테스트 수행 절차

다음 단계들은 리스크-기반 테스트 수행 절차를 위한 것이다:

1 단계: 리스크 식별

소프트웨어 어플리케이션의 사용성, 기능, 성능 등에 부정적인 영향을 미칠 가능성이 있는 잠재적 리스크를 식별한다. 요구 사항 문서, 결함 리포트, 사용자 스토리, 이해관계자 인터뷰, 사용자 리뷰 등의 과거 이력과 정보를 활용해 잠재적 리스크를 수집한다.

2 단계: 리스크 분석

1 단계에서 식별한 리스크를 분석하여 더 깊이 이해한다. 여기에는 이해관계자, 비즈니스 분석가, 테스터, 개발자, 기존 사용자와의 논의를 통해 리스크 발생 가능성과 그 영향을 평가하는 것을 포함된다. 이는 리스크를 종합적으로 평가하기 위한 두 단계 절차다.

리스크 분석(Risk Analysis) = 발생 가능성(Likelihood) X 영향(Impact)

여기서 “리스크의 발생 가능성”은 리스크가 발생할 확률, “영향”은 리스크 발생 시 결과의 심각성을 이야기한다.

3 단계: 리스크 우선순위 지정

다음 단계는 분석에 기반해 리스크의 우선순위를 정하는 것이다. 리스크의 우선순위는 그 발생 가능성과 영향에 따라 높음, 중간, 낮음으로 분류한다. 우선순위가 높은 리스크는 발생 가능성이 높고, 비즈니스에 큰 영향을 미친다. 이런 리스크들에는 즉각적인 주목과 집중적인 테스트 노력이 필요하다.

4 단계: 테스트 계획과 설계

테스크 전략(test strategy)을 계획하고 설계한다. 일정 계획 수립, 위험 우선 순위를 기반으로 테스트 케이스들을 설계한다. 상세한 테스트 계획을 수립하는데, 여기에는 리소스들, 도구들, 일정, (성능, 기능, 보안 등의) 테스트 유형들이 명시되어야 한다.

5 단계: 테스트 실행

테스트 전략에 따라 테스트 케이스를 실행한다. 리스크가 높은 테스트 부터 시작하라. 테스트 진전 상황을 모니터링하고, 결함을 기록하고, 지속적으로 리스크를 재평가 한다.

6 단계: 리스크 재평가

프로젝트 범위나 외부 요소가 변경된 경우, 테스트 절차와 리스크를 동시에 재평가하고 우선순위를 다시 조정한다.

리스크 분석 정보를 업데이트하여 변경이 생길 때마다 변경 사항을 반영한다. 그런 다음, 이 업데이트된 정보를 활용해, RBT 도중에 우선순위가 높은 리스크를 반영한다. 그리고 관련 테스트 케이스를 실행한다.

7 단계: 리포팅과 피드백

상세한 결함(defect) 리포트를 준비한다. 또한 상세한 테스트 결과들, 위험 완화 상태(risk mitigation status), 해소되지 않고 남아 있는 모든 위험들에 대한 리포트들도 준비한다. 이 정보는 매우 중요하다. 왜냐하면, 이해관계자들이 출시 준비가 완료되었는지를 결정하고, 위험 평가를 더 해야 하는지 여부를 결정할 때 이 정보들을 바탕으로 판단할 수 있기 때문이다.

8 단계: 테스트 종료

테스트 주기의 끝에서 전반적인 리스크의 상태를 평가한다. 이해관계자들의 승인은 최종 프로덕션 릴리스를 승인하는 마지막 단계다. 소프트웨어의 잔여 리스크가 허용 가능 수준이면, 고객이 사용할 수 있도록 릴리스 된다.

실생활의 RBT 절차 예시

소프트웨어 개발의 맥락에서 시나리오를 고려해 보자:

1 단계: 리스크 식별

팀은 과거 데이터, 요구 사항 문서, 결함 리포트, 유저 스토리, 이해관계자 인터뷰 그리고 유저 리뷰를 활용하여 잠재적 리스크를 식별할 수 있다:

  • 사용성(Usability): 결제 시 브라우저 호환성 문제.
  • 기능성(Functionality): 결제 게이트웨이 통합 오류.
  • 성능(Performance): 거래 중 사용자 데이터에 대한 보안 취약성

2 단계: 리스크 분석

팀은 이 식별된 리스크의 가능성과 영향을, 이해관계자들, 개발자들, 테스터들과 논의하여 평가한다.

발생가능성(Likelihood) x 영향(Impact): 결제 게이트웨이 문제는 (복잡성으로 인해) 발생 가능성이 높고 (거래에 치명적인) 영향이 크다.

3 단계: 리스크 우선순위 지정

분석 결과를 토대로, 리스크를 높음, 중간, 낮음으로 분류한다. 결제 게이트웨이 통합은 우선순위가 높은 리스크로 나타나기 때문에 테스트 수행을 위해 우선순위가 부여 된다.

4 단계: 테스트 계획과 설계

팀은 여러 시나리오에서 결제 게이트웨이 테스트 수행을 강조하는 세부 테스트 계획을 전개한다. 이로써 안전한 거래와 브라우저 간 호환성을 보장한다.

5 단계: 테스트 실행

테스트 수행은 우선순위가 높은 결제 게이트웨이 통합 리스크부터 시작한다. 문제를 면밀히 모니터링하고 결함을 기록한다.

6 단계: 리스크 재평가

테스트 수행이 진행하면서 팀은 리스크를 재평가 한다. 예를 들어, 계속되는 테스트 중에, 팀은 초기에는 사용량이 많은 시간에 서버 과부화가 잠재적 위험이라고 예상했다. 그런데 테스트를 진행하다 보니, 서버가 부하를 효율적으로 처리한다는 점이 발견했다. 이로 인해 재평가를 실시했고, 서버 과부화에 대한 리스크 등급을 낮출 수 있었다.

동시에, 새로운 리스크가 발견되었다: 특정 기능은 사용자 부하가 많은 경우 성능 저하를 겪는다는 것이다. 이에 대해 추가 조사 및 완화를 위해 우선 순위를 지정하라는 메세지가 표시된다.

7 단계: 리포팅과 피드백

팀은 상세한 리포트를 생성해야 한다. 여기에는 결함(defect)들, 위험 완화(risk mitigation) 상태, 테스트 결과(test result)들이 포함되여야 한다. 이해관계자들은 이 정보를 사용하여 출시 준비 완료 여부를 결정할 수 있다.

8 단계: 테스트 종료

테스트 주기의 끝에서, 팀은 전반적인 리스크 상태를 평가한다. 이해관계자의 승인을 받으면, 소프트웨어는 고객의 사용을 위해 출시된다. 잔여 리스크는 허용 가능한 수준이어야 한다.

리스크 기반 테스트 수행(RBT)의 장점

다음은 RBT의 장점이다:

RBT의 장점설명
효율적인 리소스 사용RBT는 리스크가 높은 영역에 집중하여 인력, 테스트 도구, 수고를 최적화 한다. 전자상거래 스타트업은 ‘결제’와 ‘장바구니 담기’와 같은 중요한 모듈에 대한 테스트 수행에 집중해야 한다. 이로써 테스트 자원을 효율적으로 관리할 수 있다.
테스트 수행의 품질 향상주요 기능에 우선순위를 지정하면 전반적인 소프트웨어 품질이 향상된다. 진료 예약 앱은 RBT 활동을 환자 데이터 처리에 대한 테스트 수행에 집중하여, 안전하고 정확한 진료를 보장한다.
조기테스트, 빠른 실패리스크가 높은 결함을 조기에 감지해내면 이후 개발 단계에서 상당한 비용을 절약할 수 있다. 개인 뱅킹 앱은 이체 거래의 취약점을 조기에 발견하여 잠재적인 손실을 방지하고 고객에게 호감도를 유지할 수 있다.
정보에 입각한 비즈니스 결정RBT는 결함과 리스크가 높은 모듈의 준비 상태에 대해 명확한 인사이트를 제공한다. 그 결과 정보에 입각하여 출시를 결정 할 수 있다. 게임 앱은 출시 전에 RBT를 통해 플랫폼 간의 호환성을 테스트 하여, 여러 플랫폼에서 원활한 사용자 경험을 보장한다.
리스크 관리 강화구조화된 리스크 식별과 평가는 테스트 대상 애플리케이션(AUT, application under test)의 위험 관리를 개선시킨다. 온라인 철도 티켓 예약 웹사이트는 RBT를 통해 오버부킹 및 취소 오류와 관련된 리스크를 식별하고 완화 한다.
고객 중심비즈니스 요구와 고객의 기대에 맞춰 테스트 수행 활동을 조정하여 사용자 경험을 개선한다. 영화 스트리밍 앱은 RBT 활동을 사용자 구독 관리 테스트 수행에 집중한다. 이로써 수익과 사용자 만족도를 개선한다.
변화에 대한 적응력RBT는 애자일 환경에서 변화하는 요구 사항에 빠르게 적응하여 테스트 절차가 성공할 수 있게 한다. 온라인 학습 플랫폼은 RBT를 통해 SNS 공유와 같은 새로운 기능을 빠르게 테스트 하여 통합한다. 이로써 사용자 요구 사항에 부합할 수 있게 된다.
최적화된 테스트 커버리지리스크가 높은 영역에 초점을 맞춰, 제한된 리소스로 포괄적인 테스트 커버리지를 효율적으로 달성한다. 향상된 리스크 관리
비용 절감영향력이 큰 결함을 조기에 발견하면, 전반적인 소프트웨어 비용과 출시 후 문제를 감소시킬 수 있다. RBT를 이용해, 한 소프트웨어 회사는 CRM 시스템을 테스트한다. 이로써 출시 후 수정 사항을 크게 줄이고 고객 충성도를 높이며, 출시 후 패치 비용을 절감한다.
규정 준수규제 대상 산업은 규제 기준을 충족시키기 위해, 중요한 규정 준수의 영역에서 테스트 수행의 우선순위를 정한다. 연말 세일 기간 동안 전자 상거래 사이트는 RBT를 통해 테스트 커버리지를 최적화한다. 이를 위해 트래픽이 많은 상황에서 성능에 중요한 복잡한 영역을 테스트한다.

리스크 기반 테스트 수행(RBT)의 단점

다음은 RBT의 단점이다:

RBT의 단점설명 예시
테스트 커버리지 누락/부족 리스크RBT는 리스크가 높은 모듈에 초점이 맞춰져 있어 리스크가 낮은 영역의 테스트를 간과할 수도 있다. 이는 전반적인 애플리케이션의 이미지에 영향을 미칠 수 있다. 복잡한 애플리케이션에서 잘못된 리스크 평가를 하게 되면, 테스트 수행 절차 전반을 위태롭게 할 수 있다. 과거 데이터가 없으면 새로운 가상 현실 게임 앱에 대한 리스크 평가와 RBT 적용이 복잡해 진다.
사람의 판단에 과도하게 의존RBT는 특정 팀 구성원의 피드백에 의존하는 경우가 많다. 사람은 편견과 판단에 영향을 받을 수 있어 그 피드백은 절차의 효율성이 떨어트릴 수 있다. 개발자의 써드파티 통합에 대한 과거 경험이 부정적이라면, 그 위험을 과대 평가하게 만들 수도 있다. 객관적인 분석도 없이 말이다. 이런 편견은 팀이 리스크로 인식된 것을 완화하는 데 지나치게 집중하게 만들 수 있다. 그로 인해 테스트 수행 중에 다른 리스크를 무시해 버릴 가능성이 있다.
지속적인 재평가 필요RBT는 리스크를 지속적으로 평가하고 식별해야 한다. 따라서 노력과 리소스가 지속적으로 필요하다. 게임 앱의 경우, 빠르게 변화 하는 게임의 규칙, 컨텐츠, 기능 때문에 경쟁력을 유지하려면 지속적인 리스크 평가가 필요하다. 그에 따라 팀의 업무량이 증가한다.
새로운 애플리케이션에는 효과적이지 않음RBT는 탐색 또는 사용성 테스트 수행과 같은 특정 테스트 유형과 잘 맞지 않을 수 있다. 이 테스트 수행에는 수시로 사람의 개입이 필요하기 때문이다. RBT는 eBook 리더기 테스트 수행에는 적합하지 않다. 사용성과 직관성이 핵심이어서, 사람의 개입이 수시로 필요한 테스트 수행이지만, RBT는 사람의 개입이 부족하기 때문이다.
장기적인 리스크를 잘못 계산RBT는 바로 앞의 리스크에 지나치게 초점을 맞추는 경향이 있다. 이로 인해 장기적인 확장성 문제와 관련 리스크를 무시하게 될 수도 있다. 음악 및 동영상 스트리밍 앱의 팀은 계속 진행 중인 라이선스 리스크에만 집중하게 될 수도 있다. 그로 인해 음악 유통 채널 확장과 같은 장기적인 고려 사항 및 관련 리스크를 무시하게 될 수도 있다.
광범위한 지식과 전문성 필요RBT를 구현하려면 심도있는 지식, 기술적인 지식이 필요하다. 이는 작은 팀에서는 부족할 수 있고, 도입에도 어려움이 있을 수 있다. 웨어러블 피트니스 추적기를 개발하는 스타트업은 의료 및 IoT 분야에 대한 전문 지식이 부족하여 RBT를 통합하는데 어려움이 있을 수 있다.
만능 솔루션이 아님사용성과 직관성이 중요한 eBook 리더기의 테스트 수행에는, RBT가 적합하지 않을 수 있다. 이런 테스트의 유형에 필요한 사람의 즉각적인 개입이 부족하기 때문이다. 사용성과 직관성이 중요한 eBook 리더기의 테스트 수행에는, RBT가 적합하지 않을 수 있다. 이런 테스트의 유형에 필요한 사람의 즉각적인 개입이 부족하기 때문이다.
복잡한 협업 프로젝트를 처리할 수 없음여러 팀과 이해관계자가 관여하는 복잡한 프로젝트에서는 RBT를 위해 같은 리스크를 조율하는 것이 어려울 수 있다. 대규모 ERP 프로젝트 테스트 수행에서는 이해관계자들이 리스크에 대해 다양한 관점을 가지고 있을 수 있다. 이로 인해 RBT를 조율하기 어려울 수 있다.


애자일에서 위험-기반 테스트 수행(Risk-Based Testing)을 구현하기 위한 모범 사례

애자일환경에서 일하기 위해서는 역동적이고 협력적이며 유연한 접근법이 필요하다. 이를 위해서 반복적이고 신속하며 지속적인 개발과 테스트 수행을 RBT와 통합해야 한다.

애자일의 기본에 RBT 접목

스프린트 계획, 일일 스탠드업 미팅, 회고 등과 같은 애자일의 이벤트에서 리스크 평가를 정기적으로 수행한다. 이는 스프린트 목표와 테스트 수행 노력을 맞추는데 도움이 된다.

리스크를 공동으로 식별하고 평가하기

리스크 평가와 식별에 다기능 팀의 모든 구성원을 참여시켜라. 이런 다양한 관점을 효율적으로 활용하여 광범위한 테스트 전략을 정의 한다.

빈번한 리스크 재평가

모든 스프린트 종료 후 리스크를 재평가 한다. 그리고 범위, 환경, 새로운 기능, 사용자 피드백 등에 기반하여 테스트 수행 목표도 다시 평가한다. 이는 다음 스프린트에서 가장 관련성이 높은 위험에 집중하는 데 도움이 된다.

리스크에 기반해 테스트 수행 우선순위 지정

스프린트를 계획할 때는, 리스크가 큰 기능들에 집중하는 것이 우선이다. 매우 중요한 이슈들을 일찍 해결하면, 그 소프트웨어는 출시할 수 있는 상태를 유지하면서 각 스프린트를 마칠 수 있다.

그림: TestRail는 팀이 리스크 수준에 기반해 테스트의 우선순위를 지정하고 분류할 수 있게 해준다. 이로써 더 좋은 계획을 할 수 있고, 중요한 영역에 리소스를 할당할 수 있어, RBT 원칙에 맞게 조정 가능하다.

애자일 대시보드에서 리스크 지표 사용하기

프로젝트 관련 지표들을 시각화 하고 표시할 때는 RBT 지표들을 사용한다. 이 지표들은 리스크 종결 및 상태를 추적하는 데 도움이 된다. 그렇게 하면 모든 이해관계자들이 리스크의 최신 상태를 더 잘 파악할 수 있게 된다.

자동화하고 자동화하기

자동화를 사용하여 테스트 수행 절차 전반의 속도를 올리고 품질을 유지하도록 한다.

애자일 테스트 수행을 지원하는 테스트 자동화 도구를 사용하라. 그렇게 하면 RBT 절차의 속도가 높아지고, 솔루션의 비용이 최적화 되며, 품질이 향상된다. 테스트 자동화를 위해 testRigor와 같이 지능적인 생성형 인공지능 기반 도구를 사용하라.

사용자 스토리와 리스크 통합

리스크 관리를 비즈니스 요구사항에 맞춰 조정하기 위해, 사용자 스토리 및 승인 기준을 리스크와 통합한다.

리스크를 CI/CD의 본보기로 사용하기

애플리케이션에서 리스크가 높은 영역을 지속적으로 테스트하기 위해 리스크를 CI/CD 파이프라인의 지침으로 삼도록한다. 이는 모든 스프린트에서 소프트웨어 품질과 우선순위가 높은 리스크 커버리지를 유지하는 데 도움이 된다.

테스트 케이스 관리 도구 사용

TestRail과 같은 테스트 관리 도구의 기능을 활용하여, 팀은 애자일한 방식으로 RBT 구현의 절차를 간소화 할 수 있다. 그로 인해 개발 생명 주기 전반에 걸쳐, 리스크의 식별, 우선순위 지정, 주요 영역에 대한 포괄적인 테스트 수행을 개선할 수 있다.

그림: TestRail의 테스트 실행 기능은 팀이 테스트 실행을 추적하고 관리할 수 있게 한다. 이로써 리스크가 높은 테스트가 효과적으로 진행되고 모니터링 되는 것을 보장한다.

애자일에서 RBT 성공 여부를 지표로 측정하는 방법

애자일 환경에서 RBT의 성공 여부를 측정하려면 특정 지표를 활용해야 한다. 다음은 몇가지의 고려해야할 지표들이다:

지표공식
식별된 리스크의 수심각도 및 현재 상태에 따라 식별된 리스크의 수
스프린트에서 계획된 테스트의 수 vs 스프린트에서 실행된 테스트의 수계획된 테스트 케이스 / 실행된 테스트 케이스
스프린트에서 통과한 테스트의 수 vs 스프린트에서 실패한 테스트의 수통과한 테스트 케이스 / 실패한 테스트 케이스
테스트 활동 편차(계획된 테스트 활동- 실제 테스트 활동) / 계획된 테스트 활동 *100
테스트 일정 편차(계획된 테스트 일정 – 실제 테스트 일정) / 계획된 테스트 일정 *100
RBT를 위한 스프린트 번 다운 차트스프린트 중 시간에 따른 테스트 진행 상황 표시
리스크 식별 비율식별된 리스크의 수 / 잠재적인 총 리스크의 수 *100
리스크 완화 비율완화한 리스크의 수 / 식별된 리스크의 수 *100
리스크 커버리지리스크를 커버하는 테스트 케이스의 수 / 총 식별된 리스크의 수 *100
결함 감지 효율성리스크 높은 영역에서 감지된 결함의 수 / 총 감지된 결함 수 *100
결함 누출 비율생산/UAT에서 발견된 결함 수 / 총 발견된 결함 수 *100
테스트 커버리지 리포트총 계획한 테스트 케이스 대비 실행된 테스트 케이스의 비율
리스크 기반 테스트 리포트RBT 활동, 커버리지, 완화 노력을 자세히 설명하는 종합 리포트
품질 비용(CoQ, Cost of Quality)예방 비용 + 평가 비용 + 실패 비용


지표의 선택은 개발중인 소프트웨어의 프로젝트 목표, 테스트 수행 목적, 특성에 맞추어야 한다는 점을 기억하자. 이 지표들을 정기적으로 재검토하고 개선하도록 한다. 이는 애자일 프레임워크 내에서 RBT 절차를 지속적으로 개선하는 데 도움이 된다.

요점

리스크 기반 테스트 수행(RBT)은 빠르고, 애자일하고, 빠듯한 일정의 DevOps 환경에 반드시 필요하다. 역동적인 환경에서는 고품질의 제품과 완전한 고객 만족을 요구한다. 모든 팀 구성원들이 리스크 식별과 완화에 책임감을 가지는 리스크 인식 문화를 받아들이자. 이로 인해 선제적인 리스크 관리를 장려하고 더욱 탄탄한 제품을 생산할 수 있다.

TestRail과 같은 테스트 관리 도구가 여러분의 테스트 수행 전략을 최적화하여 비할 데 없는 효율성과 효과를 제공하는 방법을 알아보자!

(원문: Pragya Yadav | January 8th, 2024 | Understanding the Pros and Cons of Risk-Based Testing )

다른 기고들

소프트웨어 개발사 ELEKS는 어떻게 가시성과 생산성을 높였을까: Jira와 TestRail을 통합한 사례 연구

게스트의 글입니다. (작성자: Ostap Elyashevskyy) QA 절차를 처음부터 구축하거나 기존 QA 절차를 개선하는 경우, 올바른 테스트 관리 도구 선택은 매우 중요하다. 그것은 여러분이 버그를 찾고, 테스트 케이스를 관리하는 것을 도와준다. 또한 궁극적으로는, 소프트웨어 개발 절차를 잘 다듬을 수 있도록 돕는다. 이 글에서 나는 ELEKS의 우리 팀에게 효과적인 테스트 관리 솔루션을 찾은 경험을 공유하고자 한다. 그리고 그 과정에서 평가한 다른 몇 가지 대안들...

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

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

테스트 관리를 위한 Jira: 선택, 과제, 그리고 솔루션

여러분의 팀이 소프트웨어 개발 관리를 위해 Jira를 사용하고 있다면, 테스트 수행 및 QA 절차를 Jira와 통합하는 것은 필수적이다. 일반적으로 두 가지 기본 선택권이 있다: Jira를 직접 활용하여 테스트 수행 작업을 모니터링한다. (주로 개발 이슈와 관련된 하위 작업 또는 사용자 정의 이슈 유형을 통해) Jira 기반 테스트 관리 애드-온을 사용한다. (무료일 수도, 유료일 수 있다.) 테스트 관리를 위해 Jira 사용하기 Jira는 애초에 소프트웨어 테스트 수행을...