메뉴

소프트웨어를 계속 사용할 수있는 결함을 어떻게 결정합니까?

how do you decide which defects are acceptable

문제를 제거하기 위해 도구를 사용해보십시오

Software Go-Live는 항상 모든 소프트웨어 제품에 대한 큰 이벤트입니다. 모든 것이 제대로 작동하고 있는지 확인하는 것이 중요합니다. 사용자에게 양질의 소프트웨어 출시 .

제품이 나쁘거나 미성숙하거나 불안정하거나 사용하기 어려우면 재정적으로 많은 손실을 입을 수 있으며 사용자가 브랜드 자체에 대한 신뢰를 잃을 수도 있습니다.

종종 종료 기준을 충족 할 때까지 테스트를 수행해야한다고 들었습니다. 또한 결함을 허용 가능한 수준으로 수정해야한다고 들었습니다.

이는 훌륭한 지침이지만 모호합니다.

소프트웨어 실행 기준

더 구체적으로 말하면 :

  • 소프트웨어가 가동되는 데 허용되는 결함 비율은 얼마입니까?
  • 소프트웨어가 사용할 수있는 공개 결함을 어떻게 결정합니까?
  • 뭐 결함의 종류 다른 사람보다 더 심각한가요?

추천 읽기 => 언제 테스트를 중지해야합니까?

이런 질문이 있으신가요? 그러면이 기사가 이에 대한 답변을 제공 할 것입니다. 읽어…

복잡한 소프트웨어는 결함이 없으며 작동하는 소프트웨어에 대한 결점을 닫는 것에 대한 닭과 달걀 이야기입니다.

결함을 더 많이 수정할수록 결함을 닫는 동안 새로운 결함이 주입 될 가능성이 높아집니다. 그래서,

  • 결함의 범위와 함께 살아갈 수있는 결함의 유형을 어떻게 결정합니까?
  • 가동을 위해 배포 할 소프트웨어의 기준을 어떻게 설정합니까?
  • UAT 코디네이터는 어떻게 가동 여부를 결정합니까?
  • 소프트웨어를 평가해야하는 매개 변수는 무엇입니까?
  • 우리가 대답하는 방법 – 소프트웨어가 사용하기에 적합하고 이해 관계자들에게 가치를 제공 할 것인가?

생산에 들어가는 것은 일반적으로 지불 마일스톤과 연결되기 때문에 고객과 공급 업체 모두에게 중요한 이정표입니다. 둘 다 대규모 혁신 프로젝트의 성공을 보장하는 데 동일한 책임이 있습니다.

내 경험에 따르면 고객은 돈에 대한 가치를 원하고 종료 기준 UAT가 함께 사용할 수 있습니다.

상기 종료 기준은 다음과 같은 애플리케이션의 모든 영역에서 허용 가능한 문제 범위를 다소 정의합니다.

  1. 기능의
  2. 성능 및 부하
  3. 유용성
  4. 보안
  5. 외부 시스템과 통합
  6. 보고서
  7. 데이터 마이그레이션

이러한 유형의 모든 결함에 대해 자세히 설명해야한다고 생각합니다. 그리고 이것이 바로 우리가 지금 할 일입니다.

C ++ 버블 정렬 예제

#1. 기능적 결함 :

고객이 제공 한 사양에 따라 소프트웨어가 생성 된 경우 요구 사항을 충족해야합니다. 모든 편차는 기능적 결함으로 기록됩니다.

기능적 결함 다음에 따라 분류됩니다 심각도와 우선 순위 .

다음은 중요한 고려 사항입니다.

  • 높은 심각도와 우선 순위 결함은 일반적으로 소프트웨어의 일상적인 사용에 영향을 미치는 결함입니다. 이러한 유형의 결함은 실행하기 전에 수정해야하는 결함입니다. 예외 없음.
  • 때때로 기능적 결함은 원래 제공된 요구 사항의 일부가 아니기 때문에 변경 요청으로 분류됩니다. Go-live 이후 비즈니스가 작동하는 데 필수적인 이러한 CR도 구현해야합니다.
  • 결함 분류 및 기능 결함의 우선 순위는 비즈니스 사용자 및 비즈니스 분석가와 협력하여 UAT 코디네이터가 수행합니다. 일반적으로 고객에게는 가동을 위해 개방 될 수있는 결함의 비율에 대한 종료 기준이 있습니다.

# 2. 성능 및 부하 결함 :

성능 결함 외부 사용자가 소프트웨어를 사용하는 경우 라이브 등을 고려하는 것이 중요합니다.

주어진 사용자 수에 대해 소프트웨어가 느리면로드하는 데 많은 시간이 걸리므로 사용자는 소프트웨어 사용을 피할 것입니다. 소프트웨어가 매우 느려 비즈니스를 잃는 경우 사용자는 경쟁 업체 사이트로 이동하는 경향이 있습니다.

때로는 클라이언트가 직면하지 않는 응용 프로그램 부분도 성능에 영향을 미칠 수 있습니다.

예를 들면: 매일 마지막에 실행되는 배치 프로세스가 있고이 작업이 진행되는 동안 애플리케이션의 응답 시간이 오래 걸리는 경우 배치 성능도 고려해야 할 요소입니다.

  • 성능은 일반적으로 시스템에 특정 수의 동시 사용자가있는 동안 렌더링하고 사용자가 사용할 수있게되는 화면의 응답 시간으로 측정됩니다.
  • 성능 테스트는 다음과 같은 도구를 사용하여 수행됩니다. LoadRunner , WebLoad , Neoload 등
  • 주어진로드와 미래의 예측 된로드에서 소프트웨어의 성능은 일반적으로 계약서에 문서화되며 가동 전에 시연해야합니다.
  • 사용자가 덜 사용하는 화면 또는 응용 프로그램의 일부는 가동 후 평가로 연기됩니다.
  • 성능은 소프트웨어가 배포 된 하드웨어 및 네트워크 조건의 유형에 따라 달라집니다.
  • 성능 테스트는 성능 도구를 사용하여 지정된 하드웨어에서 UAT 중에 수행되며 해당 결함은 기능적 결함과 유사한 방식으로 추적됩니다. 또한 우선 순위가 지정되고 가동 종료 기준을 충족하는 데 합의에 도달합니다.
  • 일반적으로 UAT의 성능 및 부하 테스트는 비즈니스 사용자의 기능적 UAT가 완료되고 기능적 결함에 대한 허용 가능한 종료 기준에 도달 한 후에 수행됩니다.

#삼. 사용성 결함 :

생성 된 소프트웨어 최종 사용자가 쉽게 사용할 수 있어야합니다. 다른 단축키, 단축키, 최소 화면 탐색 수, 페이지 매김 등을 사용합니다. 소프트웨어는 스마트하고 직관적이어야합니다.

적절한 화면으로 이동하기 전에 페이지의 움직임이 너무 많으면 사용자는 일반적으로 소프트웨어 사용에 대한 관심이 적습니다.

  • 사용성 지침은 소프트웨어가 구축되기 전에 만들어집니다. 소프트웨어는 이러한 지침을 준수해야합니다.
  • 최종 사용자가 소프트웨어를 사용하기 전에 현명하게 극복해야하는 소프트웨어를 만드는 동안 도구 제한이있을 수도 있습니다.
  • 유용성이 높은 소프트웨어를 사용하면 최종 사용자는 일반 소프트웨어의 5 배까지 데이터를 입력 할 수 있습니다.
  • 소프트웨어의 모양과 느낌은 선명해야하고 법적 문제도 실행 전에 분류해야합니다.
  • 사용자에게 원활한 사용 경험을 보장하기 위해 사용성 컨설턴트가 여러 번 임명됩니다.
  • 소프트웨어 응용 프로그램과 함께 제공되어야하는 문서도 합법적으로 사용할 수 있으므로 엄격한 사용성 지침을 준수해야합니다.
  • UAT 테스터 / 외부 테스터가 기록한 사용성 결함도 기능 및 성능 결함으로 우선 순위가 지정되며 가동 종료 기준을 충족해야합니다.

# 4. 보안 결함 :

보안 소프트웨어 애플리케이션이 해킹되고 고객의 민감한 데이터가 금방 도난 당할 수 있으므로 소프트웨어의 문제는 뜨거운 문제입니다.

따라서 신뢰할 수있는 소프트웨어는 매우 유능한 해커라도 적절한 권한없이 애플리케이션에 침입하는 것을 허용해서는 안됩니다.

  • 보안 테스트는 소프트웨어에 대한 특정 입력을 사용하여 UAT에서 수행되어 해킹 불가능한지 확인합니다.
  • 보안 테스트는 소프트웨어가 취약한 지 확인하기 위해 소프트웨어를 해킹하려는 합법적 인 해커가 수행합니다.
  • 시스템이 작동하기 전에 모든 보안 결함을 닫아야합니다.
  • 보안은 또한 응용 프로그램의 다른 섹션을 사용하고 데이터를 만들고 승인하기 위해 다양한 사용자 (외부 및 내부)에 대한 로그인 및 역할 및 권한을 의미합니다.

# 5. 외부 소프트웨어 시스템과 통합 :

일반적으로 고객 사이트에 배포 할 소프트웨어 응용 프로그램은 이미 존재하는 기존 소프트웨어와 인터페이스해야합니다.

예를 들면: 인쇄 시스템과 함께 사용 중이거나 청구 응용 프로그램이나 데이터 화면 시스템과 같은 외부 시스템 일 수 있습니다. 배포되는 소프트웨어 응용 프로그램은 이러한 외부 시스템과 원활하게 통합되어야합니다. 이러한 시스템에 대한 모든 입력 및 출력은 동시에 작동해야합니다. 오늘날의 기술에는 모바일 앱과 애플리케이션이 있어야하는 다양한 소프트웨어 플랫폼이 포함됩니다. 호환 가능 .

외부 시스템 인터페이스 확인은 시스템 및 UAT 단계에서 광범위하게 수행되어야합니다. 실행하기 전에 충족해야하는 종료 기준에 대한 필수 항목이어야합니다.

# 6. 보고서 :

소프트웨어 애플리케이션의 보고서는 애플리케이션 내부의 데이터가 집계되고 있음을 보여주는 중요한 방법입니다.

예를 들어, 모든 청구 관련 데이터는 대변 및 차변 잔액을 집계해야합니다.

  • 소프트웨어의 모든 데이터는 조정되어야합니다. 소프트웨어 내 데이터의 이러한 조정은 보고서를 통해 표시되며 의도 한대로 작동해야합니다.
  • 이전 시스템에서 새 시스템으로의 데이터 마이그레이션이 현재 릴리스의 주요 의도 인 경우 특히 그렇습니다.

# 7. 데이터 마이그레이션:

기존 시스템이 새 시스템으로 교체되는 경우 기존 시스템의 데이터가 새 시스템으로 이동됩니다 (새 시스템을 사용하여 마감 날짜에 도달 한 후). 마이그레이션 된 데이터가 지원되어야합니다. 요구 사항 수집 중에 정의 된대로 새 시스템에 의해.

새 시스템에서는 모든 이전 데이터를 사용할 수 없습니다. 그러나 이전 데이터의 스냅 샷은 새 시스템에서 사용할 수 있습니다. 이 데이터는 동의 한대로 사용할 수 있어야합니다.

노트 : 위 목록은 완전하지 않습니다. 응용 프로그램 유형에 따라 유효성을 검사해야하는 항목이 더 많거나 위의 모든 사항이 적용되지 않을 수 있습니다. 따라서 포괄적 인 종료 기준을 개발하려면 소프트웨어, 비즈니스 목적, 사용자 기대치 및 아키텍처 또는 하드웨어 종속성에 대한 철저한 이해가 필수적입니다.

실행을위한 종료 기준의 예 :

이것은 단지 예입니다. 프로젝트마다 다를 수 있습니다.

  • 우선 순위 1 결함의 100 %가 종결 됨 (심각도 중요 및 우선 순위 1)
  • 우선 순위 2 결함의 90 %는 종료되며 (심각도 높음 및 우선 순위 2) 나머지 결함 10 %에 대해 논리적 해결 방법을 사용할 수 있습니다. 그리고 나머지 10 % 결함을 종결하기위한 계획을 사용할 수 있습니다.
  • 프로덕션 배포 및 온 전성 체크리스트가 준비되었습니다.
  • 생산 지원 팀이 구성되어 티켓을 마감 할 준비가되었습니다.
  • 우선 순위 3 개 결함의 70 %가 마감되고 나머지 30 %의 낮은 결함을 마감하기위한 계획이 수립되어 있습니다.

참고할 몇 가지 사항 :

  • 모든 심각도 및 우선 순위 정의는 프로그램 시작시 고객과 공급 업체 간의 비즈니스 회의에서 결정됩니다.
  • 모든 UAT 결함이 기록되고 다른 모든 결함이 닫히면 UAT 코디네이터와 비즈니스 스폰서가 만나 보류중인 결함과 열린 결함을 조사합니다. Day-1 go-live에 필요한 모든 결함이 종료되면 비즈니스 스폰서는 go-live에 대한 준비 상태를 확인하고 소프트웨어를 프로덕션으로 가져옵니다.

결론적으로

이 기사가 프로덕션의 잠재적 인 실패로부터 소프트웨어를 보호하는 견고한 종료 기준을 만드는 데 필요한 몇 가지 중요한 고려 사항에 대한 통찰력을 제공하기를 바랍니다.

저자 정보 : 이것은 Krishnan Venkatraman의 게스트 기사입니다. 그는 소프트웨어 테스트 분야에서 거의 18 년의 경험을 가지고 있습니다. 그는 크고 복잡한 소프트웨어 테스트 프로젝트를 많이 수행했습니다.

아래에 질문 / 의견을 게시하십시오.

추천 도서

^