8 key performance indicators
이 기사에서는 Panaya Test Dynamix 엔드 투 엔드 테스트 솔루션의 도움을 받아 품질 릴리스에 대한 8 가지 핵심 성과 지표를 설명합니다.
소프트웨어 품질 관리자가 기록적인 속도로 고품질 소프트웨어를 제공해야하는 압력에 직면하고 있다는 것은 비밀이 아닙니다.
우리 모두가 자주 묻는 질문은 소프트웨어 품질 측면에서“우리의 성공을 어떻게 측정합니까?”입니다.
시장 출시 속도는 훨씬 더 간단한 계산이지만 고품질 소프트웨어를 제공하는 데있어 우리의 성과를 측정하는 것은 프로젝트 방법론 (폭포, 하이브리드, 애자일), 소프트웨어의 복잡성, 기술 수준과 같은 다양한 요인에 따라 달라집니다. 관련 부채, 인터페이스 수 등이 있습니다.
요컨대, 허용 가능한 수준으로 작용하는 변수의 수 심각도가 높은 결함 과소 평가해서는 안됩니다. 따라서이 시장에서 살아 남기 위해서는 우리의 의견과 측정 막대 모두에서 지속적으로 진화해야합니다.
이것이 바로 품질 스코어 카드에 추가하고 추적을 시작하여 릴리스 위험을 완화하고 품질을 개선하며 성공을 즉시 측정해야하는 상위 8 개 KPI 목록을 개발 한 이유입니다.
학습 내용 :
품질 릴리스에 대한 핵심 성과 지표
# 1) 결함 감지 효율성 (DDE, AKA 결함 감지 백분율)
이것은 당신의 척도입니다 전반적인 회귀 테스트 유효성. 고객이 출시 전후에 발견 한 결함의 비율로 계산됩니다.
출시 후 발견 된 결함은 일반적으로 다음과 같이 알려져 있습니다. '사건' 헬프 데스크 시스템에 기록되지만 테스트 단계에서 발견 된 결함 ( 예 : , 단위, 시스템, 회귀 또는 UAT)는 릴리스 전에 식별되고 다음과 같은 도구로 문서화됩니다. Panaya 테스트 Dynamix .
이 KPI를 올바르게 계산하려면 프로덕션 환경으로 릴리스하기 전에 항상 각 결함이 식별 된 소프트웨어 버전을 분류해야합니다.
DDE에 자주 사용되는 공식 :
소프트웨어 버전 릴리스에서 확인 된 결함 수 /
소프트웨어 릴리스의 결함 수 + 최종 사용자가 식별 한 이스케이프 된 결함 (예 :., 사건)
다음은 간단한 그림입니다.
지난 월별 SAP 서비스 팩에서 회귀 테스트주기 동안 95 개의 결함이 발견되었고 릴리스 후에 25 개의 결함이 기록되었다고 가정합니다. DDE는 95를 (95 + 25) = 79 %로 나눈 값으로 계산됩니다.
DDE는 생산에 출시 된 다음 날 100 %에서 시작하는 선 차트로 모니터링해야합니다. 또한 내부 최종 사용자와 고객이 최신 SAP 서비스 팩을 예로 들어 작업을 시작하면 필연적으로 몇 가지 사건을 기록하게됩니다.
버그 보고서 예제 작성 방법
서비스 팩이 생산 환경에 도달 한 후 첫 주 2 일 이내에 '급식 광란'이 발생하는 것이 제 경험입니다. 이때 사건이 기록 될 때 100 %에서 약 95 %로 빠르게 감소하는 것을 알 수 있습니다. 회사가 월별 서비스 팩 릴리스주기를 사용하는 경우 각 서비스 팩에서 30 일 동안 DDE를 측정합니다.
반면에 회사가 연간 4 개의 주요 릴리스 주기만 실행하는 경우 90 일 동안 측정하여 해당 기간 동안 어떻게 감소하는지 확인합니다.
'좋은 DDE'로 간주되는 것은 무엇입니까?
모든 조직과 사람이 시간이 지남에 따라 진화하는 혈압 수치와 매우 비슷합니다.
의료계에서는 '최적'혈압 판독 값을 120/80으로 정의하지만 나이가 들어감에 따라 수축기 혈압이 상승하는 것은 당연합니다. DDE를 통해 업계 실무자와 사고 리더는 대부분의 업계에서 90 %가 칭찬 할 만하다고 말합니다.
그러나 조직이 다음과 같은 변경 영향 시뮬레이션 도구를 사용하여 왼쪽으로 이동하여 지속적으로 95 % 이상의 DDE를 달성하는 것을 보았습니다 Panaya의 영향 분석 .
# 2) SWD (시스템 전체 결함)
동일한 개체와 관련된 여러 결함을 경험 한 적이 있습니까? 물론 그럴 것입니다. 많은 테스트 관리자가 직면하는 일반적인 현상입니다.
갑자기 UAT주기에서보고 된 버그 수가 크게 증가하는 것을 볼 수 있습니다. 다행스럽게도 15 분마다 결함을 모니터링하고 중복을 수동으로 '연결'하거나 모든 단일 설명을 읽고 근본 원인을 직접 파악하는 유형에 속합니다. 불안한.
그렇다면 '불량 인플레이션'이라는 불가피한 드라마를 관리 할 수있는 옵션은 무엇입니까?
그날 밤에 이어지는 드라마는 HQ 경영진과 '왜 오늘 갑자기 갑작스런 결함이 증가하는 걸까?' (일시 중지…. 응답하기 전에 심호흡)…“저는 기능 리드와 협력하여 수동 근본 원인 분석을 수행하는 중입니다.
그러나 우리는 많은 문제가 일반적인 문제와 관련이 있다고 생각하지만 아직 확인되지 않았습니다.”, 익숙한가요?
제 제안은 Panaya가 호출하는 것을 추적하기 시작하는 것입니다. '시스템 전체 결함' . 이것을 수동으로 추적하는 데는 오랜 시간이 걸립니다. 저도 여러 번 시도했습니다. 또한 결함을 서로 연결하고 주석을 추가 할 수있는 기능 만 남은 기존 ALM 도구를 사용하는 동안에도 힘든 일입니다.
와, 정말 도움이되었습니다! (비꼬는 느낌?). 하지만 지금 도구를 선택할 수없는 경우 시스템 전체 결함을 제대로 추적하여 명확하게 '설명'할 수있는 시간을 할애해야합니까? 버그 추세선이 테스트주기가 끝날 때가 아니라 아래로 이동하는 이유
기회가 생기면 Panaya Test Dynamix를 확인하십시오. 엔진 자체에 SWD가 내장되어있어 즉시 SWD를 자동으로 계산합니다.
거미줄 – 이 플랫폼의 'Risk Cockpit'내에있는 이는 모든 품질, 테스트 및 릴리스 관리자가 추적해야하는 가장 중요한 KPI를 반올림하는 6 개의 추가 핵심 성과 지표를 강력하면서도 간단하게 표현한 것입니다.
# 3) 요구 사항 완료
QA 관리자는 각 요구 사항에 롤업 된 코드 또는 전송 수준 가시성을 통해서만 실현 될 수있는 더 깊은 수준의 위험을 이해합니다. 이를 위해서는 올바른 도구 세트가 필요합니다.
Panaya 도구는 단위 테스트에 대한 지능적인 제안과 운송 활동을 기반으로 한 위험 분석을 원하는 SAP 조직의 요구에 응답합니다.
이 수준의 추적은 Panaya Release Dynamix (RDx) .
# 4) 개발 완료
우리는 고객이 왕이며 모든 조직의 디지털 전환 전략을 주도하는 시대에 살고 있습니다. 오늘날 우리는 소프트웨어 품질 보증 및 제공에 대한 우리의 사고 나 조직적 접근 방식에 갇혀있을 수 없습니다.
과거의 기존 ALM 모델은 오늘날의 지속적 배포 모델에 맞게 설계되지 않았습니다. 이러한 오래된 사고 방식에 맞서기 위해 QA 및 테스트 관리자는 애플리케이션 개발 작업에 자신을 포함시켜야합니다. 즉, 사용자 스토리 전달에 대한 펄스가 있어야합니다.
사용자 스토리가 완료 상태에 도달 할 때까지 '앉아서 기다리는'것만으로는 충분하지 않습니다. 오히려 우리는 사용자 스토리의 진화를 따르고, 매일 스크럼 회의에 참석하고, 테스트중인 애플리케이션에 중요한 변경이 이루어지면서 발생하는 위험에 대해 공개적으로 이야기해야합니다.
# 5) 테스트 계획 범위
시스템, 통합, 회귀 및 UAT 적용 범위 만 추적하는 것이 아니기 때문에 추적하기 가장 좋아하는 KPI 중 하나입니다.
왼쪽으로 이동한다는 진정한 정신으로 유닛 테스트 커버리지 추적의 중요성에 대해 조언하기 시작했습니다. 미친 것 같죠? 특히 단위 테스트 만 쉽게 실행할 수있는 올바른 도구가 있지만 실제 결과 (증거)를 더 쉽게 캡처 할 수있는 경우에는 그렇지 않습니다.
Panaya Test Dynamix의 기본 제공 테스트 기록 및 재생 기능을 사용하면 단위 테스트 참여가 급증 할 것입니다. 종단 간 적용 범위를 보여주는 요구 사항 추적 성 매트릭스를 자랑스럽게 표시 할 수있을뿐만 아니라 단위에서 회귀 테스트까지 실제 결과를 감사 부서에 쉽게 보여줄 수 있습니다.
# 6) 변경 위험 분석
테스트중인 애플리케이션을 변경하면 위험이 내재되어 있지만 올바른 테스트를 수행하고 있는지 항상 알 수있는 것은 아닙니다.
많은 조직은 '변경 위험'이 자신에게 의미하는 바를 자체적으로 정의합니다. Panaya의 Release Dynamix (RDx)의 'Risk Cockpit'내에서 프로젝트 또는 다음 릴리스에 대한 영향 분석을 통해 변경 사항을 추적 할 수 있습니다.
RDx는 각 요구 사항에 대한 위험을 체계적으로 계산하고 제공 수명 주기로 이동함에 따라 변경되는 방식을 파악합니다.
# 7) 테스트 실행 위험
모든 조직에서 작성된 테스트, 통과 된 테스트, 자동화 된 테스트 및 실행 된 테스트와 같은 KPI를 추적하는 것은 너무 일반적이지만 각 테스트 내에서 실행 된 실제 단계를 추적하는 것은 어떻습니까?
당신은 많은 인기있는 ALM 플랫폼 테스트 '단계'실행 진행 상황을 추적하는 즉시 사용 가능한보고 기능을 제공하지 않습니까? 여러 가지 '핸드 오프'가 UAT주기 , 테스트 수준뿐만 아니라 비즈니스 프로세스 수준에서도 테스트 실행 위험 및 상태를 추적하는 것이 좋습니다.
Panaya Test Dynamix는 바로 사용할 수 있습니다.
# 8) 결함 실행
추적 결함은 본질적으로 부정적인 의미도 가지고 있습니다.
활성 결함, 일일 수정 된 결함, 거부 된 결함 및 심각한 결함을 추적하는 것 외에도 범위가 지정된 요구 사항과 관련된 결함의 해결 방법을 모니터링하는 것이 좋습니다.
많은 조직이 요구 사항 중심의 결함 해결 관점을 취하지 않습니다.
왜이 솔루션이 테스트 용입니까?
Release Dynamix 및 Panaya Test Dynamix 모두에 구축 된 종단 간 추적 기능을 통해 조직은 요구 사항 수준에서 처음부터 끝까지 결함 해결의 워크 플로를 추적 할 수 있습니다.
이는 특히 프로젝트 또는 릴리스주기에 대한 조감도를 원하는 릴리스, 품질 및 테스트 관리자에게 유용합니다.
Panaya는 기술 IT 및 비즈니스 사용자를위한 테스트 프로세스를 가속화하여 전체 테스트 노력을 30-50 % 줄입니다.
안드로이드 폰용 무료 mp3 다운로더 앱
- 관리자 : 테스트 및 결함 및 병목 현상 방지를위한 실시간 경고.
- 비즈니스 사용자 : 테스트 증거 및 결함에 대한 자동 문서화.
- 기능 분석가 : 반복적 인 테스트 활동의 자동화.
- 전문 테스터 : 비즈니스 지식 캡처를 원활하게 개선합니다.
- 결함 해결사 : 테스터와 앞뒤로 줄입니다.
이 솔루션에 대해 알아야 할 기타 사항
# 1) Panaya Test Dynamix는 SaaS 솔루션입니다. 즉, 온 프레미스 자동화 도구를 모니터링 할뿐만 아니라 원활한 통합, 빈번하고 간편한 업그레이드를 얻을 수 있습니다.
# 2) 기본 제공 협업 도구 내장 된 알림 및 통신 도구를 사용하여 테스트주기를 간소화합니다.
다음 사용자에게 테스트 단계를 자동으로 전달하여 유휴 시간을 제거하고 워크로드 병목 현상을 완화하며 최적의 워크 플로우를 보장합니다.
# 3) 스마트 결함 관리 사용자는 결함, 해결 방법 및 영향을받는 비즈니스 프로세스를 중앙에서 모니터링 할 수 있습니다.
결함이 발견되면 영향을받는 다른 모든 테스트를 자동으로 식별하고 주요 결함이 해결 될 때까지 테스터에게 알림을 차단하거나 보냅니다. 해결 된 결함은 결함 백 로그를 제거하여 자동으로 닫힙니다.
# 4) UAT 및 SIT에 대한 비즈니스 프로세스 중심 접근 방식으로 부서 간 및 지리적으로 분산 된 주제 전문가는 실제 비즈니스 프로세스 (패키지 된 애플리케이션)를 기반으로 UAT주기를 검증합니다.
# 5) 테스트 자동화 커넥터 전체적인 추적 및 모니터링 기능을 통해 최소한의 시간과 노력으로 효과적인 회귀주기를 위해 Panaya Test Dynamix와 기존 자동화 도구의 완전한 통합을 제공합니다.
# 6) 테스트 증거 자동화 Excel 및 Word에서 전통적으로 관리되던 수동 테스트를 자동화합니다.
테스트 증거 및 테스트 재현 단계 기록을 포함하여 모든 테스트 실행을 손쉽게 문서화하여 시간을 절약하고 개발자와 테스터 사이의 앞뒤를 줄입니다. 문서는 감사 준비 , 모든 내부 및 외부 품질 표준을 준수합니다.
# 7) 자율 테스트SM SAP 용 제로 터치 테스트 케이스 생성 및 유지 관리가 가능하므로 더 이상 비즈니스 지식 캡처 및 수동으로 엔지니어링 된 스크립트를 만들고 유지 관리하는 프로세스와 관련된 고통을 처리 할 필요가 없습니다.
기계 학습은 군중 분석을 기반으로 검증 및 제안을 제공하는 동안 스크립트를 사용자 정의 할 수 있습니다.
# 8) 자동화 된 비즈니스 지식 캡처 – Omega 기계 학습 알고리즘 (SAP)을 사용하여 프로덕션에서 원활하게 캡처 된 비즈니스 사용자 활동을 기반으로 실제 테스트 케이스를 자동으로 생성합니다.
결론
소프트웨어 품질 관리자 및 모든 관련 이해 관계자는 Panaya를 사용하여 범위 또는 품질을 손상시키지 않고 노력을 30-50 % 줄이면서 더 많은 혁신을 추진하기 위해 테스트 KPI를 충족 할 수 있습니다.
모든 이해 관계자가 동일한 테스트 방법을 채택하여 대규모 UAT를 포함한 모든 테스트주기에 대한 실시간 가시성을 확보하므로 테스트 프로세스를 표준화하고 성공을 측정합니다.
자세한 내용은 다음을 탐색 할 수 있습니다. Panaya 테스트 Dynamix .
아래 의견에 귀하의 생각 / 질문을 알려주십시오.
추천 도서
- 품질 속성은 무엇입니까?
- MongoDB 성능 : 잠금 성능, 페이지 오류 및 데이터베이스 프로파일 링
- 품질 보증과 품질 관리의 차이점 (QA vs QC)
- 가짜 품질의 신 대 진정한 인간-소프트웨어 품질에 대한 책임은 누구입니까?
- Georgia Tech, RadView WebLOAD에서 성능 테스트 표준화
- HTTP vs HTTPS : 기능과 성능의 심층 비교
- 성능 테스트 계획과 성능 테스트 전략의 차이점
- 수동 성능 테스트를 수행하는 방법?