테스트를 중지해야하는 경우 (소프트웨어 테스트의 종료 기준)

when stop testing

테스트의 종료 기준 :

'시작은 반쯤 완료되었습니다.'– 소프트웨어 테스트를 포함한 모든 곳에 적용됩니다.

종종 우리는 프로젝트 초반에 소프트웨어 테스터가 매우 열광하는 것을 봅니다. 우리는 테스트 문서 테스트 전략, 테스트 계획 또는 테스트 케이스와 같은 열정적이고 열정적으로.

그런 다음 BANG으로 소프트웨어를 테스트합니다! 이것은 프로젝트 초기에 발견 된 흥미로운 결함에 의해서만 증폭됩니다. 그것들을 해결하는 것은 우리의 성취에 더해집니다.

많은 결함을 찾고 첫 번째 실행을 완료하면 다음 단계로 이동합니다. 두 번째 달리기를 할 때 우리는 긴장을 풀고 일반적인 인간의 경향과 마찬가지로 같은 것을 테스트하는 데 지루 해짐 두 번째 실행에서.

SQL 시나리오 기반 질문 및 답변

많은 테스터가 단조로운 작업 나중에 실행하고 동일한 소프트웨어를 반복해서 테스트하는 데 관심을 잃기 시작합니다. 세 번째 실행에 도달하면 한 가지 질문이 우리를 괴롭히기 시작합니다. 바로 '소프트웨어 테스트를 중지해야하는 경우'입니다.

당신도 같은 생각을하고 '언제 테스트를 중단해야할까요?'라고 적어도 한 번은 물었을 것입니다. 나는 질문이 '테스트를 언제, 어디서, 어떻게 중지해야합니까?' :)

개념적으로 우리는 읽었으며 많은 테스터들은 '테스트를 중지 할시기'를 결정하는 특정 조건이나 방정식이있을 수 없다고 생각합니다. 이 질문에 대해 결론을 내리기 전에 고려해야 할 여러 요소가 있습니다.

오늘 기사에서는이 테스트가 충분하다고 말할 수있는 테스트주기의 시점에 도달했을 때 테스트 활동을 마무리하는 방법에 대한 제 생각을 공유하고 싶습니다. 일반적인 테스트주기에서 몇 가지 실제 사례를 통해이를 수행 할 것입니다.

학습 내용 :

• 충분한 테스트는 언제입니까?
• 모든 결함이 발견되면 중지 : 가능합니까?
• 테스트 중지 결정 : 종료 기준
• 완료 또는 종료 기준은 무엇입니까?
• 종료 기준에는 무엇이 있어야합니까?
• 다음과 같은 경우 테스트를 중지 할 수 있습니다.
• 결론:
• 추천 도서

충분한 테스트는 언제입니까?

이 정도의 테스트로 충분하다고 언제 말할 수 있습니까? 테스트를 완료 할 수 있습니까?

이러한 질문에 답하기 위해 테스트 활동을 처음부터 끝까지 분석해야합니다. 이 활동을 평신도의 용어로 정의 할 것입니다. 멋진 기술적 인 방식이 아닙니다.

새 프로젝트의 테스트를 시작한다고 가정 해 보겠습니다.

초기 활동 :

• 테스트 팀은 요구 사항을받습니다.
• 테스트 팀 시작 계획 그리고 디자인.
• 초기 테스트 문서가 준비되고 검토됩니다.

테스트 실행 # 1)

• 테스트 팀 테스트 실행 시작 개발 된 제품을 받으면
• 테스트 단계에서 소프트웨어를 중단하고 많은 결함을 찾기 위해 다양한 시나리오를 실행합니다. (또한 응용 프로그램이 새롭고 처음으로 평가를 받고 있기 때문에 여기서 결함률이 더 높습니다.)
• 결함은 개발자에 의해 수정되고 다시 테스트를 위해 테스트 팀으로 반환됩니다.
• 테스트 팀은 결함을 다시 테스트하고 회귀를 실행합니다.
• 심각도가 높은 결함의 대부분이 해결되고 소프트웨어가 안정적으로 보이면 개발 팀이 다음 버전을 출시합니다.

테스트 실행 # 2)

• 테스트 팀은 두 번째 테스트 실행을 시작하고 유사한 활동이 실행 1로 실행됩니다.
• 두 번째 테스트 실행 중에이 프로세스에서 더 적은 결함이 발견됩니다.
• 결함은 개발자에 의해 수정되고 다시 테스트를 위해 테스트 팀에 반환됩니다.
• 테스트 팀은 결함을 다시 테스트하고 수행합니다. 회귀 .

이것은 영원히 계속 될 수 있습니다. 소프트웨어의 모든 결함이 발견되고 소프트웨어에 버그가 없을 때까지 3, 4를 실행합니다.

이러한 활동에 대한 순서도를 그리려면 대략 다음과 같습니다.

위의 순서도에서 소프트웨어의 모든 결함이 발견 될 때까지 테스트를 계속할 수 있다는 결론을 내릴 수 있습니다.

그러나 문제는 – 소프트웨어의 모든 결함을 찾을 수 있습니까? 이 백만 달러짜리 질문에 대한 답을 찾아 보겠습니다. :).

모든 결함이 발견되면 중지 : 가능합니까?

대부분의 소프트웨어는 복잡하고 엄청난 테스트 범위를 가지고 있습니다. 소프트웨어의 모든 결함을 찾는 것은 불가능하지 않지만 영원히 걸릴 것입니다.

소프트웨어에서 많은 버그를 발견 한 후에도 아무도 실제로 소프트웨어에 결함이 없다고 보장 할 수 없습니다. 테스트를 완료하고 소프트웨어에서 모든 결함을 발견했으며 더 이상 버그가 없다고 자신있게 말할 수있는 상황은 없습니다.

또한 테스트의 목적은 소프트웨어의 모든 결함을 찾는 것이 아닙니다. 소프트웨어 테스트의 목적은 소프트웨어를 중단하거나 현재 동작과 예상 동작 사이의 편차를 찾아서 소프트웨어가 의도 한대로 작동하는지 증명하는 것입니다.

소프트웨어에는 무한한 결함이 있으므로 어떤 결함이 마지막 결함인지 알 수 없기 때문에 모든 결함이 발견 될 때까지 테스트하는 것은 비현실적입니다. 진실은 테스트를 끝내기 위해 소프트웨어의 모든 결함을 찾는 데 의존 할 수 없다는 것입니다.

솔직히 말해서 테스트는 끝이 없으며 테스트주기는 언제 어디서 중단할지 결정이 내려 질 때까지 계속됩니다. 이제 테스트를 중단하기로 결정하는 것이 훨씬 더 복잡해졌습니다. '모든 결함이 발견되면 중지'가 테스트를 중지하는 기준이 아니라면 어떤 기준으로 결정해야합니까?

테스트 중지 결정 : 종료 기준

이제 이해해 보겠습니다. 테스트 활동을 마칠 때 고려해야 할 가장 중요한 요소는 무엇입니까? 테스트 중단 결정은 주로 시간, 예산 및 테스트 범위.

가장 일반적인 접근 방식은 시간 / 예산이 소진되거나 모든 테스트 시나리오가 실행될 때 중지하는 것입니다. 그러나이 접근 방식을 사용하면 테스트 품질이 저하되고 소프트웨어에 대한 충분한 확신을 얻을 수 없습니다. 어떻게?

함께 보자예.

테스트 시나리오 :

소프트웨어 모듈을 테스트한다고 가정합니다. 이를 충당하기 위해 특정 예산이 할당되었습니다. 프로젝트 일정은 한 달입니다. 총 테스트 시나리오는 200 개입니다.이 모듈을 테스트하는 사람은 귀하뿐입니다.

시나리오 # 1)

1 주차 : 1 일째에 최고 / 심각도 1 결함을 발견하고 전체 테스트가 3 일 동안 차단됩니다. 따라서 심각도 1 결함이 해결 될 때까지 시나리오를 실행할 수 없습니다. 3 일을 잃으면 차단기가 해결되고 계속 실행됩니다.

주말에 20 개의 시나리오를 완료합니다. 우선 결함 .

2 주차 : 결함 발견에 더 중점을두고 소프트웨어 테스트를 시작합니다. 두 번째 주에 심각도 1, 심각도 2 및 심각도 3 결함을 몇 개 더 열면 한 주가 끝날 때 70 개의 시나리오를 다룰 수 있습니다.

웹 서비스를 수동으로 테스트하는 방법

3 주차 : 3의 시작까지^rd주에 우선 순위가 높은 모든 결함이 해결되므로 보류중인 시나리오의 실행과 함께 이제 테스트 버킷에있는 모든 결함을 다시 테스트해야합니다. 좋은 진행을 계속하면서 추가 결함이있는 120 개의 시나리오를 다룹니다.

이때까지 우선 순위가 높은 모든 결함이 이미 발견되어보고됩니다. 따라서 이제 심각도 3 결함 만 찾을 수 있습니다.

4 주차 : 4 주차까지 열린 결함 대부분과 나머지 80 개 시나리오를 다시 테스트해야합니다. 이를 통해 4 주차 말까지 모든 높음 및 중간 우선 순위 결함을 수정하고 다시 테스트하여 최대 180 개의 시나리오를 완료 할 수 있습니다.

이 정보를 표 형식으로 입력 :

여기서 멈춰야할까요?

지친 이유 완전히 테스트 시간 우선 순위가 높은 대부분의 결함을보고하고 수정했습니다. 이 시점에서 중지하면 소프트웨어에 대한 자신감이 생깁니 까? 실제로 아래 이유 때문이 아닙니다.

• 시나리오는 완전히 실행되지 않습니다.
• 한 번도 테스트되지 않은 흐름은 거의 없습니다.
• 다루는 모든 시나리오는 한 번만 실행됩니다.
• 소프트웨어에는 여전히 결함이 있습니다.
• 회귀는 다루지 않습니다.

시나리오 # 2)

1 주차 : 1 일에 심각도 1 결함을 발견하고 3 일 동안 전체 테스트가 차단됩니다. 따라서 심각도 1 결함이 해결 될 때까지 시나리오를 실행할 수 없습니다. 3 일을 잃은 후 차단기가 해결되고 실행을 계속합니다.

주말에 결함이 거의없는 20 개의 시나리오를 완료합니다. 이번주는 시나리오 1과 동일합니다.

2 주차 : 두 번째 주 동안 심각도 1, 심각도 2 및 심각도 3 결함을 거의 열지 않지만 1 주차의 백 로그를 처리하기 위해 더 많은 시나리오를 처리하는 데 중점을 둡니다. 주말에는 120 개의 시나리오를 처리 할 수 ​​있습니다.

3 주차 : 3의 시작까지^rd주에 모든 미결 결함이 해결되었으므로 보류중인 시나리오의 실행과 함께 이제 테스트 버킷에있는 모든 결함을 다시 테스트해야합니다. 여전히 좋은 진행을 계속하면서 완료된 시나리오는 추가 결함이있는 200 개가됩니다.

이제 심각도 2 및 심각도 3 결함 만보고 할 수 있습니다.

이 정보를 표 형식으로 입력 :

여기서 멈춰야할까요?

당신은 모든 테스트 시나리오를 완전히 다루었습니다. 몇 번의 주요 결함을 열었습니다. 이 시점에서 중지하면 소프트웨어에 대한 자신감이 생깁니 까?

실제로 아래 이유 때문이 아닙니다.

• 모든 시나리오는 한 번만 실행됩니다.
• 소프트웨어에는 여전히 많은 주요 결함이 있습니다.
• 회귀는 다루지 않습니다.

위의 두 시나리오에서 품질이 손상되었음을 알 수 있습니다. 가장 좋은 방법은 시나리오 1과 시나리오 2의 모든 요인이 다루어지고 품질도 손상되지 않는 지점을 찾는 것입니다. 이를 달성하기 위해 테스트 시작시 특정 기준을 정의해야합니다.

이러한 기준을 완료 또는 종료 기준이라고합니다. 우리 질문에 대한 답입니다. '테스트를 언제 중지해야합니까?'.

완료 또는 종료 기준은 무엇입니까?

종료 기준은 테스트주기가 끝날 때 평가되며 테스트 계획에 정의됩니다. 테스트를 완료하기 위해 충족해야하는 조건 또는 활동의 집합입니다.

종료 기준은 테스트가 충분한 정도와 테스트 활동이 완료된 것으로 선언 될 수있는시기를 정의합니다. 적용 범위 완료 기준은 테스트를위한 종료 기준을 정의하기 위해 결합됩니다.

종료 기준에는 무엇이 있어야합니까?

이상적으로 종료 또는 중지 기준은 다양한 요소를 결합하여 정의되므로 모든 프로젝트에서 고유합니다. 프로젝트 요구 사항에 따라 다르므로 테스트 계획 중에 정의해야합니다. 프로젝트 시작시. 여기에 정의 된 매개 변수는 가능한 한 많이 정량화되어야합니다.

다음은 기능 또는 시스템 테스트의 경우 종료 기준을 정의 할 때 고려해야 할 몇 가지 지침입니다. 프로젝트 요구 사항에 따라 테스트를 중지 할 위치를 결정하는 동안 아래 요소를 거의 또는 모두 결합 할 수 있습니다.

다음과 같은 경우 테스트를 중지 할 수 있습니다.

요구 사항 :

• 100 % 요구 사항 범위가 달성됩니다.

결함 :

• 정의 / 원하는 결함 수에 도달했습니다.
• 모든 Show Stopper 결함 또는 차단기가 수정되었으며 알려진 Critical / Severity 1 결함이 Open 상태에 없습니다.
• 모든 높은 우선 순위 결함이 식별되고 수정됩니다.
• 결함률이 정의 된 허용 률보다 낮습니다.
• 중간 우선 순위 결함이 거의 없으며 해결 방법이 있습니다.
• 소프트웨어 사용에 영향을주지 않는 우선 순위가 낮은 개방형 결함이 거의 없습니다.
• 우선 순위가 높은 모든 결함은 다시 테스트되고 닫히고 해당 회귀 시나리오가 성공적으로 실행됩니다.

테스트 범위 :

• 테스트 범위는 95 % 달성되어야합니다.
• 테스트 케이스 합격률은 95 % 여야합니다. 이것은 공식으로 계산할 수 있습니다.
  • (통과 한 총 TC 수 / 총 TC 수) * 100.
• 모든 중요한 테스트 사례가 통과되었습니다.
• 5 % 테스트 케이스는 실패 할 수 있지만 실패한 테스트 케이스는 우선 순위가 낮습니다.
• 완전한 기능 범위가 달성됩니다.
• 모든 주요 기능 / 비즈니스 흐름은 다양한 입력으로 성공적으로 실행되고 잘 작동합니다.

마감일 :

• 프로젝트 마감일 또는 테스트 완료 마감일에 도달했습니다.

테스트 문서 :

• 모든 테스트 문서 / 결과물 (예 – 테스트 요약 보고서 )는 준비, 검토 및 게시됩니다.

예산:

• 전체 테스트 예산이 소진되었습니다.

“Go / No Go”회의 :

• ' Go / No Go ' 모임 이해 관계자와 함께 수행되었으며 프로젝트가 프로덕션으로 이동해야하는지 여부를 결정합니다.

결론:

마지막에는 아주 간단하게 만들어 보겠습니다.

간단한 예 또는 아니오로 질문에 답하십시오.

대부분의 답을 예라고하면이 시점에서 테스트를 중지 할 수 있습니다. 대부분의 답변이 아니요 인 경우 테스트에서 누락 된 항목을 확인해야하며 이는 탈출하는 생산 결함을 찾는 데 도움이 될 수 있습니다. :)

• 모든 테스트 케이스가 한 번 이상 실행됩니까?
• 테스트 케이스 통과율이 정의 된대로입니까?
• 완전한 테스트 범위가 달성 되었습니까?
• 모든 기능 / 비즈니스 흐름이 한 번 이상 실행됩니까?
• 결정된 결함 수에 도달 했습니까?
• 모든 주요 높은 우선 순위 결함이 수정되고 종결됩니까?
• 모든 결함이 다시 테스트되고 종결 되었습니까?
• 모든 미결 결함에 대해 회귀가 수행 되었습니까?
• 테스트 예산이 소진 되었습니까?
• 테스트 종료 시간에 도달 했습니까?
• 모든 테스트 결과물이 검토되고 게시됩니까?

저자 정보 : 이것은 Renuka K의 게스트 기사입니다. 그녀는 소프트웨어 테스트 경험이 11 년 이상입니다.

이 기사가 도움이 되었기를 바랍니다. 나는 또한 주제에 대한 당신의 생각 / 의견을 듣고 싶습니다.

행복한 테스트!

추천 도서

• 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
• 소프트웨어 테스팅 QA 어시스턴트 작업
• 소프트웨어 테스팅 과정 강의 계획서 – 온라인 과정 세부 교육 계획
• 소프트웨어 테스팅 과정 : 어떤 소프트웨어 테스팅 기관에 가입해야합니까?
• 경력으로 소프트웨어 테스트 선택
• 소프트웨어 테스팅 기술 콘텐츠 작성자 프리랜서 작업
• 몇 가지 흥미로운 소프트웨어 테스트 인터뷰 질문
• 소프트웨어 테스팅 과정 피드백 및 리뷰