7 principles software testing
소프트웨어 테스팅의 7 가지 원칙 : 결함 클러스터링, 파레토 원칙 및 살충제 역설에 대한 세부 정보 포함.
나는 모든 사람들이 ' 소프트웨어 테스팅의 7 가지 원칙 ”.
이러한 기본 테스트 원칙은 테스트 팀이 테스트 프로세스를 효과적인 프로세스로 만들기 위해 시간과 노력을 활용할 수 있도록 도와줍니다. 이 기사에서 우리는 두 가지 원칙에 대해 자세히 알아볼 것입니다. 결함 클러스터링, 파레토 원리 및 살충제 역설 .
학습 내용 :
소프트웨어 테스팅의 7 가지 원칙
이 두 가지 원칙을 자세히 살펴보기 전에 소프트웨어 테스팅의 7 가지 원칙을 간단히 이해해 보겠습니다.
탐험하자 !!
# 1) 테스트는 결함의 존재를 보여줍니다
모든 애플리케이션 또는 제품은 여러 팀에서 충분한 양의 테스트를 거친 후 프로덕션으로 출시되거나 시스템 통합 테스트, 사용자 승인 테스트 및 베타 테스트 등과 같은 여러 단계를 거칩니다.
그래서 테스트 팀에서 소프트웨어를 완전히 테스트했으며 소프트웨어에 결함이 없다는 것을 보거나들은 적이 있습니까? ? 그 대신 모든 테스트 팀은 소프트웨어가 모든 비즈니스 요구 사항을 충족하고 최종 사용자의 요구 사항에 따라 작동하는지 확인합니다.
소프트웨어 테스팅 업계에서는 아무도 결함 없음 테스트는 소프트웨어에 오류가 없거나 결함이 없음을 증명할 수 없기 때문에 매우 사실입니다.
그러나 테스트의 목적은 다양한 기술과 방법을 사용하여 점점 더 숨겨진 결함을 찾는 것입니다. 테스트를 통해 발견되지 않은 결함을 발견 할 수 있으며 결함이 발견되지 않았다고해서 소프트웨어에 결함이 없음을 의미하지는 않습니다.
예 1 :
은행 애플리케이션을 고려하면이 애플리케이션은 철저한 테스트를 거쳐 SIT, UAT 등과 같은 여러 단계의 테스트를 거치며 현재 시스템에서 결함이 식별되지 않습니다.
그러나 프로덕션 환경에서는 실제 고객이 은행 시스템에서 거의 사용하지 않는 기능을 시도하고 테스터가 해당 기능을 간과하여 날짜까지 결함이 발견되지 않았거나 개발자가 코드를 건드리지 않았을 가능성이 있습니다. .
예 2 :
텔레비전에서 비누, 치약, 손씻기 또는 소독제 스프레이 등에 대한 여러 광고를 보았습니다.
특정 손씻기를 사용하면 99 % 세균을 제거 할 수 있다고 텔레비전에 나오는 손씻기 광고를 생각해보십시오. 이것은 제품이 100 % 무균이 아님을 분명히 증명합니다. 따라서 테스트 개념에서 결함이없는 소프트웨어는 없다고 말할 수 있습니다.
# 2) 초기 테스트
테스터는 소프트웨어 개발 수명주기 (SDLC)의 초기 단계에 참여해야합니다. 따라서 요구 사항 분석 단계 동안의 결함 또는 문서 결함을 식별 할 수 있습니다. 이러한 결함을 수정하는 데 드는 비용은 테스트 후반 단계에서 발견되는 비용과 비교할 때 매우 적습니다.
테스트가 라이브 프로덕션으로 이동함에 따라 결함 수정 비용이 어떻게 증가하는지 보여주는 아래 이미지를 고려하십시오.
(영상 출처 )
위의 이미지는 요구 사항 분석 중에 발견 된 결함을 수정하는 데 필요한 비용이 더 적고 테스트 또는 유지 관리 단계로 이동함에 따라 계속 증가 함을 보여줍니다.
이제 질문은 테스트는 얼마나 일찍 시작해야합니까 ?
요구 사항이 확정되면 테스터는 테스트에 참여해야합니다. 요구 사항 문서, 사양 또는 기타 유형의 문서에 대해 테스트를 수행하여 요구 사항이 잘못 정의 된 경우 개발 단계에서 수정하지 않고 즉시 수정할 수 있도록해야합니다.
# 3) 철저한 테스트가 불가능합니다
실제 테스트 중에 입력 데이터의 유효하거나 잘못된 조합을 모두 사용하여 모든 기능을 테스트하는 것은 불가능합니다. 이 접근 방식 대신 다른 기술을 사용하는 우선 순위에 따라 몇 가지 조합의 테스트를 고려합니다.
철저한 테스트에는 무한한 노력이 필요하며 이러한 노력의 대부분은 효과가 없습니다. 또한 프로젝트 타임 라인은 너무 많은 조합의 테스트를 허용하지 않습니다. 따라서 등가 분할 및 경계 값 분석과 같은 다른 방법을 사용하여 입력 데이터를 테스트하는 것이 좋습니다.
예를 들어 ,알파벳, 특수 문자 및 0에서 1000 사이의 숫자 만 허용하는 입력 필드가 있다고 가정합니다. 테스트를 위해 얼마나 많은 조합이 나타날지 상상해보십시오. 각 입력 유형에 대해 모든 조합을 테스트하는 것은 불가능합니다.
테스트에 필요한 테스트 노력은 엄청날 것이며 프로젝트 일정과 비용에도 영향을 미칠 것입니다. 따라서 철저한 테스트가 사실상 불가능하다고 항상 말합니다.
# 4) 테스트는 상황에 따라 다릅니다.
은행, 보험, 의료, 여행, 광고 등과 같은 시장에서 사용할 수있는 여러 도메인이 있으며 각 도메인에는 여러 응용 프로그램이 있습니다. 또한 각 도메인에 대해 응용 프로그램에는 다른 요구 사항, 기능, 다른 테스트 목적, 위험, 기술 등이 있습니다.
다른 도메인은 다르게 테스트되므로 테스트는 순전히 도메인 또는 응용 프로그램의 컨텍스트를 기반으로합니다.
예를 들어 ,은행 애플리케이션 테스트는 전자 상거래 또는 광고 애플리케이션 테스트와 다릅니다. 각 유형의 응용 프로그램과 관련된 위험은 다르므로 동일한 방법, 기술 및 테스트 유형을 사용하여 모든 유형의 응용 프로그램을 테스트하는 것은 효과적이지 않습니다.
# 5) 결함 클러스터링
테스트 중에 발견 된 대부분의 결함이 적은 수의 모듈과 관련이있을 수 있습니다. 모듈이 복잡 할 수 있고, 이러한 모듈과 관련된 코딩이 복잡 할 수있는 등 여러 가지 이유가있을 수 있습니다.
이것이 문제의 80 %가 모듈의 20 %에서 발견되는 소프트웨어 테스트의 파레토 원리입니다. 이 기사의 뒷부분에서 결함 클러스터링과 파레토 원리에 대해 자세히 알아볼 것입니다.
# 6) 살충제 역설
Pesticide Paradox 원칙에 따르면 동일한 테스트 케이스 세트가 일정 기간 동안 반복해서 실행되면 이러한 테스트 세트는 시스템의 새로운 결함을 식별하기에 충분하지 않습니다.
이“농약 역설”을 극복하기 위해서는 일련의 테스트 케이스를 정기적으로 검토하고 수정해야합니다. 필요한 경우 새 테스트 케이스 세트를 추가 할 수 있으며 시스템에서 더 이상 결함을 찾을 수없는 경우 기존 테스트 케이스를 삭제할 수 있습니다.
# 7) 오류 없음
소프트웨어가 완전히 테스트되고 출시 전에 결함이 발견되지 않으면 소프트웨어에 99 % 결함이 없다고 말할 수 있습니다. 그러나이 소프트웨어가 잘못된 요구 사항에 대해 테스트되면 어떻게 될까요? 이러한 경우 최종 사용자의 요구에 맞지 않는 잘못된 요구 사항에 대해 테스트가 수행되므로 결함을 찾아 적시에 수정하는 것조차 도움이되지 않습니다.
예를 들어, 응용 프로그램이 전자 상거래 사이트 및 잘못 해석되고 테스트 된 '장바구니 또는 장바구니'기능에 대한 요구 사항과 관련되어 있다고 가정합니다. 여기서 더 많은 결함을 찾아도 애플리케이션을 다음 단계 나 프로덕션 환경으로 이동하는 데 도움이되지 않습니다.
이것이 소프트웨어 테스팅의 7 가지 원칙입니다.
이제 살펴 보겠습니다. 결함 클러스터링, 파레토 원리 및 살충제 역설 세부 묘사 .
결함 클러스터링
소프트웨어를 테스트하는 동안 테스터는 대부분 발견 된 대부분의 결함이 특정 기능과 관련이 있고 나머지 기능의 결함 수가 적은 상황에 직면합니다.
결함 클러스터링은 대부분의 결함을 포함하는 소수의 모듈을 의미합니다. 기본적으로 결함은 전체 애플리케이션에 균일하게 분산되지 않고 2 ~ 3 개의 기능에 집중되거나 집중됩니다.
때로는 애플리케이션의 복잡성으로 인해 코딩이 복잡하거나 까다로울 수 있으며 개발자가 실수를하여 특정 기능이나 모듈에만 영향을 미칠 수 있습니다.
결함 클러스터링은“ 파레토 원리 ”라고도합니다. 80-20 규칙 . 이는 발견 된 결함의 80 %가 애플리케이션 모듈의 20 % 때문이라는 것을 의미합니다. Pareto Principle의 개념은 처음에 이탈리아 경제학자에 의해 정의되었습니다. -빌 프로도 파레토 .
테스터가 100 개의 결함을 살펴보면 100 개의 결함에 대한 근본적인 의미가 있는지 명확하지 않습니다. 그러나 100 개의 결함이 특정 기준에 따라 분류되면 테스터는 많은 수의 결함이 매우 적은 특정 모듈에만 속한다는 것을 이해할 수 있습니다.
예를 들어 ,은행 애플리케이션 중 하나에 대해 테스트 된 아래 이미지를 살펴보면 대부분의 결함이 '초과 인출'기능과 관련이 있음을 보여줍니다. 계정 요약, 자금 이체, 상임 지침 등과 같은 나머지 기능에는 제한된 수의 결함이 있습니다.
(영상 출처 )
위 그림은 총 32 개의 결함 중 오버 드래프트 기능에 18 개의 결함이 있음을 나타내며 이는 결함의 60 %가 '오버 드래프트'모듈에서 발견되었음을 의미합니다.
따라서 테스터는 대부분 실행 중에이 영역에 집중하여 점점 더 많은 결함을 찾습니다. 테스터는 테스트 중에 다른 모듈에도 비슷한 초점을 두는 것이 좋습니다.
동일한 코드 또는 모듈이 초기 반복 동안보다 테스트 케이스 세트를 사용하여 반복해서 테스트되면 결함 수가 많지만 일부 반복 후에 결함 수가 크게 감소합니다. 결함 클러스터링은 회귀 테스트 중에 결함이 발생하기 쉬운 영역을 철저히 테스트해야 함을 나타냅니다.
농약 역설
모듈 중 하나에 더 많은 결함이있는 것으로 확인되면 테스터는 해당 모듈을 테스트하기 위해 추가 노력을 기울입니다.
몇 번의 테스트를 반복하면 코드의 품질이 향상되고 대부분의 결함이 개발 팀에서 수정되기 때문에 개발자가 테스터가 더 많은 결함을 발견 한 특정 모듈을 코딩하는 동안주의를 기울이기 때문에 결함 수가 감소하기 시작합니다.
따라서 한 지점에서 대부분의 결함이 발견되고 수정되어 해당 모듈에서 새로운 결함이 발견되지 않습니다.
그러나 때때로 하나의 특정 모듈 (여기서는 ' 당좌 대월 ”모듈), 개발자는 올바르게 코딩하기 위해 다른 모듈을 무시하거나 특정 모듈의 변경 사항이 계정 요약, 자금 이체 및 상임 지침과 같은 다른 기능에 부정적인 영향을 미칠 수 있습니다.
테스터가 동일한 테스트 케이스 세트를 사용하여 대부분의 결함이 발견 된 모듈 (Overdraft 모듈)을 실행하면 개발자가 해당 결함을 수정 한 후 해당 테스트 케이스가 새로운 결함을 찾는 데 그다지 효과적이지 않습니다. 오버 드래프트의 종단 간 흐름으로서 모듈은 철저하게 테스트되며 개발자는 해당 모듈에 대한 코드를 신중하게 작성했습니다.
이러한 테스트 케이스를 수정하고 업데이트해야합니다. 소프트웨어 또는 애플리케이션의 다른 영역에서 새롭고 더 많은 결함을 찾을 수 있도록 새 테스트 케이스를 추가하는 것도 좋은 생각입니다.
살충제 역설의 예방 방법
아래와 같이 Pesticide Paradox를 예방할 수있는 두 가지 옵션이 있습니다.
에) 결함이 발생하기 쉬운 이전 모듈을 제외하고 다른 영역 또는 모듈에 초점을 맞춘 새로운 테스트 케이스 세트를 작성합니다. 예: 소프트웨어의 'Overdraft').
비) 새 테스트 케이스를 준비하고 기존 테스트 케이스에 추가하십시오.
' 방법 A ”, 테스터는 이전 테스트에서 집중하지 않았거나 개발자가 코딩 중에 특별히주의하지 않은 다른 모듈에서 더 많은 결함을 찾을 수 있습니다.
위의 예에서 테스터는 새로운 테스트 케이스 세트를 사용하여 계정 요약, 자금 이체 또는 상임 지침 모듈에서 더 많은 결함을 찾을 수 있습니다.
그러나 테스터가 이전 모듈을 무시할 수 있습니다 ( 예: 'Overdraft')는 이전 반복에서 대부분의 결함이 발견되었으며 다른 모듈을 코딩 한 후이 모듈 (Overdraft)에 새로운 결함이 삽입되었을 수 있으므로 위험 할 수 있습니다.
' 방법 B ”, 나머지 모듈에서 새로운 잠재적 결함을 찾을 수 있도록 새로운 테스트 케이스가 준비됩니다.
여기 예제에서 새로 생성 된 테스트 케이스는 계정 요약, 자금 이체 및 상설 지침과 같은 모듈의 결함을 식별하는 데 도움이 될 수 있습니다. 그러나 테스터는 결함이 발생하기 쉬운 이전 모듈 ( 예: 이러한 새로운 테스트 케이스가 기존 테스트 케이스와 병합되기 때문에 'Overdraft').
기존 테스트 사례는 'Overdraft'모듈에 더 중점을 두었고 새 테스트 사례는 다른 모듈에 중점을 두었습니다. 따라서 모든 테스트 케이스 세트는 모듈에서 코드 변경이 발생하더라도 최소한 한 번 실행됩니다. 이렇게하면 적절한 회귀가 실행되고이 코드 변경으로 인해 결함을 식별 할 수 있습니다.
두 번째 접근 방식을 사용하면 총 테스트 사례 수가 크게 증가하여 실행에 더 많은 노력과 시간이 필요합니다. 이것은 분명히 프로젝트 일정에 영향을 미치며 가장 중요한 것은 프로젝트 예산에도 영향을 미칩니다.
따라서이 문제를 극복하기 위해 중복 테스트 케이스를 검토 한 다음 제거 할 수 있습니다. 새로운 테스트 케이스를 추가하고 기존 테스트 케이스를 수정 한 후 쓸모 없게되는 테스트 케이스가 많이 있습니다.
마지막 5 회 반복 (5 회 반복)에서 결함을 식별하고 그다지 중요하지 않은 테스트 케이스를 식별하려면 실패한 테스트 케이스를 확인해야합니다. 또한 몇 가지 테스트 사례에서 다루는 단일 흐름을 다른 종단 간 테스트 사례에서 다루고 단일 흐름을 가진 테스트 사례를 제거 할 수있는 경우 일 수도 있습니다.
그러면 총 테스트 케이스 수가 줄어 듭니다.
예를 들어 ,특정 모듈 하나를 다루기위한 50 개의 테스트 케이스가 있으며이 50 개의 테스트 케이스 중 20 개의 테스트 케이스가 지난 몇 번의 테스트 반복에서 새로운 결함을 감지하지 못한 것을 확인했습니다 (5 회 반복이라고 가정합시다). 따라서이 20 개의 테스트 케이스는 철저하게 검토해야하며 이러한 테스트 케이스가 얼마나 중요한지 확인해야하며 그에 따라 20 개의 테스트 케이스를 유지할지 제거할지 여부를 결정할 수 있습니다.
테스트 케이스를 제거하기 전에 해당 테스트 케이스에서 다루는 기능 흐름이 다른 테스트 케이스에서 다루는 지 확인하십시오. 이 프로세스는 모든 모듈에서 따라야 총 테스트 케이스 수가 크게 감소합니다. 이렇게하면 테스트 케이스의 총 수가 줄어들지 만 여전히 100 % 요구 사항 적용 범위가 유지됩니다.
이는 나머지 모든 테스트 사례가 모든 비즈니스 요구 사항을 포함하므로 품질에 대한 타협이 없음을 의미합니다.
결론
소프트웨어 테스트는 소프트웨어가 최종 사용자의 요구 사항에 따라 작동하는지 여부를 확인하기 때문에 SDLC의 필수 단계입니다.
테스트는 가능한 한 많은 결함을 식별합니다. 따라서 테스트를 효과적이고 효율적으로 수행하려면 모든 사람이 테스트의 기둥으로 알려진 소프트웨어 테스트의 7 가지 원칙을 분명히 알고 이해해야합니다.
대부분의 테스터는 실제 테스트 중에 이러한 원칙을 구현하고 경험했습니다.
유닉스에서 찾기 명령을 사용하는 방법
일반적으로 원칙이라는 용어는 따라야 할 규칙 또는 법률을 의미합니다. 따라서 소프트웨어 테스트 업계의 모든 사람은이 7 가지 원칙을 따라야하며, 누군가 이러한 원칙을 무시하면 프로젝트에 막대한 비용이들 수 있습니다.
행복한 독서 !!
추천 도서
- 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
- 소프트웨어 테스팅 QA 어시스턴트 작업
- 소프트웨어 테스팅 과정 : 어떤 소프트웨어 테스팅 기관에 가입해야합니까?
- 경력으로 소프트웨어 테스트 선택
- 소프트웨어 테스팅 기술 콘텐츠 작성자 프리랜서 작업
- 결함 기반 테스트 기술이란 무엇입니까?
- 몇 가지 흥미로운 소프트웨어 테스트 인터뷰 질문
- 소프트웨어 테스팅 과정 피드백 및 리뷰